Đặt vấn đề

Có một nghịch lý khá buồn cười trong thời đại AI.

Chúng ta có những mô hình đủ thông minh để viết code, đọc tài liệu, nhìn hình, phân tích hợp đồng, nói chuyện như người, thậm chí tranh luận về triết học.

Rồi cuối cùng, một trong những ứng dụng AI thành công lại là:

Viết vài dòng mô tả cho một tấm ảnh.

Nghe hơi… phí model.

Giống như mua một con robot Transformer hàng trăm tỷ tham số, nối nó vào một trung tâm dữ liệu đầy GPU nóng rực, rồi giao nhiệm vụ:

“Con viết giúp chú câu này: cô dâu chú rể đang nắm tay nhau giữa cánh đồng.”

Xong.

Nhưng chính cái việc nhỏ xíu đó lại giúp Pixieset đạt một con số rất đáng suy nghĩ: sau khoảng 16 tháng, 35% nhóm người dùng phù hợp vẫn sử dụng tính năng AI này. Từ ý tưởng tới production mất khoảng bốn tháng; riêng tuần đầu tiên, hệ thống đã tạo alt text cho hơn 750.000 bức ảnh. (Amazon Web Services, Inc.)

Câu chuyện đáng học không phải:

Amazon Bedrock mạnh như thế nào?

Mà là một câu khác khó hơn nhiều:

Trong hàng trăm thứ AI có thể làm, tại sao Pixieset lại chọn đúng một việc nhỏ như vậy?

Và đây có lẽ là bài toán lớn nhất của rất nhiều sản phẩm AI hiện nay.

Không phải thiếu model.

Không phải thiếu GPU.

Không phải thiếu API.

Mà là không biết nên để AI làm cái gì.

Nhiếp ảnh gia không thiếu khả năng viết một câu

Pixieset là nền tảng dành cho nhiếp ảnh gia, cung cấp những thứ như website, gallery ảnh, cửa hàng, quản lý studio và các công cụ liên quan đến công việc nhiếp ảnh. Theo AWS, hệ thống của Pixieset đang lưu trữ hơn 8 tỷ bức ảnh và phục vụ hàng triệu nhiếp ảnh gia. (Amazon Web Services, Inc.)

Giả sử mình là một photographer.

Cuối tuần vừa rồi mình chụp một đám cưới.

Mang về 2.000 tấm.

Sau vài ngày ngồi trước màn hình:

• chọn ảnh,
• chỉnh màu,
• crop,
• retouch,
• export,
• upload,
• sắp album,
• làm portfolio.

Cuối cùng có 300 tấm được đưa lên website.

Tưởng xong rồi.

Không.

Website hỏi:

1Alt text:
2__________________________

À.

Còn món này nữa.

Alt text về cơ bản là đoạn văn bản mô tả nội dung hoặc mục đích của một hình ảnh. Nó hữu ích cho accessibility, đặc biệt với screen reader, đồng thời giúp công cụ tìm kiếm hiểu thêm nội dung của ảnh. W3C cũng lưu ý rằng với ảnh mang thông tin, text alternative cần truyền đạt thông tin thiết yếu của hình; Google Search khuyến nghị sử dụng alt text có tính mô tả và phù hợp với ngữ cảnh. (W3C; Google Search Central)

Ví dụ:

1<img
2  src="wedding.jpg"
3  alt="Cô dâu và chú rể nắm tay nhau giữa cánh đồng dưới ánh hoàng hôn"
4/>

Một tấm thì rất dễ.

300 tấm thì bắt đầu thấy cuộc đời hơi dài.

3.000 tấm thì chúng ta bắt đầu tự hỏi:

Hay thôi SEO cũng được.

Vấn đề không phải photographer không biết viết.

Họ biết.

Vấn đề là giá trị của việc đó quá thấp so với mức độ nhàm chán của nó.

Đây là một loại công việc rất nguy hiểm trong software:

Necessary but undesirable work.

Công việc cần thiết nhưng chẳng ai muốn làm.

Và đây chính là khe cửa mà Pixieset đưa AI chui vào.

Pixieset đã không hỏi “AI có thể làm gì?”

Đây là phần mình thấy hay nhất trong toàn bộ case study.

Khi generative AI xuất hiện, một công ty về photography có vô số thứ để làm.

Có thể tạo ảnh bằng AI.

Có thể retouch bằng AI.

Có thể thay background.

Có thể sửa mặt.

Có thể sinh thêm người.

Có thể biến trời mưa thành trời nắng.

Có thể thay áo chú rể, thay váy cô dâu, thay luôn chú rể nếu cần.

Về mặt demo thì tuyệt đẹp.

Nhưng có một vấn đề.

Đó chính là nghề của photographer.

Người ta trở thành photographer vì thích chọn góc máy, ánh sáng, bố cục, màu sắc và khoảnh khắc.

Nếu phần mềm nhảy vào nói:

“Đưa đây AI chụp dùm cho.”

thì về mặt kỹ thuật có thể rất ấn tượng.

Nhưng về mặt tâm lý sản phẩm, nó giống một cái máy tự động bước vào bếp của Gordon Ramsay rồi bảo:

Anh ra ngoài đi, để em nấu.

Không chắc Gordon vui.

Pixieset tiếp cận theo hướng ngược lại.

Theo AWS, câu hỏi của họ không phải:

What can this technology do?

mà gần với:

Người dùng của chúng ta đang mất thời gian vào những công việc nào không thuộc phần sáng tạo mà họ thực sự yêu thích?

Cách đặt vấn đề đó đưa họ tới metadata và alt text thay vì tạo ảnh. (Amazon Web Services, Inc.)

Đây là một khác biệt tưởng nhỏ nhưng rất lớn.

 1Cách nghĩ phổ biến:
 2
 3Có AI
 4   ↓
 5AI làm được gì?
 6   ↓
 7Tìm chỗ nhét AI vào sản phẩm
 8
 9
10Cách Pixieset làm:
11
12Người dùng đang đau ở đâu?
13   ↓
14Việc nào lặp lại + nhàm chán + tốn thời gian?
15   ↓
16AI có giải quyết được không?
17   ↓
18Có → dùng AI

AI lúc này không còn là điểm xuất phát.

Nỗi đau mới là điểm xuất phát.

Một cái xẻng không nên tranh nghề với người đào vàng

Có một cách khác để nhìn bài toán này.

Một photographer có thể xem khả năng chụp ảnh của mình là craft — nghề, kỹ năng, thậm chí là một phần bản sắc cá nhân.

Còn nhập alt text là chore — việc vặt.

Hai thứ nhìn trên Jira đều là task.

Nhưng trong đầu con người, chúng hoàn toàn khác nhau.

 1Photography
 2    ↓
 3Craft
 4    ↓
 5"Tôi muốn tự làm."
 6
 7
 8Alt text
 9    ↓
10Chore
11    ↓
12"Ai làm giùm tôi cũng được."

AI đụng vào craft, con người có xu hướng phòng thủ.

AI đụng vào chore, con người có xu hướng thở phào.

AWS mô tả nguyên tắc của Pixieset khá rõ: họ cố gắng tự động hóa những việc kéo photographer ra khỏi nhiếp ảnh, thay vì xâm nhập vào phần công việc sáng tạo mà photographer tự hào. (Amazon Web Services, Inc.)

Và mình nghĩ đây là một nguyên tắc thiết kế AI rất đáng nhớ:

AI feature tốt không nhất thiết phải làm việc khó nhất. Nó nên làm công việc mà con người ít muốn làm nhất.

Hai thứ đó không giống nhau.

Từ một bức ảnh tới Amazon Bedrock

Về mặt kiến trúc, giải pháp của Pixieset lại khá bình thường.

Và chính cái “bình thường” này mới thú vị.

Pixieset vốn đã sử dụng kiến trúc event-driven với các thành phần như Amazon EC2, AWS Lambda và Amazon SQS. Khi photographer upload ảnh, một event kích hoạt worker pipeline.

Để thêm AI alt text, họ không xây một “AI platform” khổng lồ riêng.

Pipeline về cơ bản trở thành:

 1Photographer
 2      │
 3      │ upload image
 4      ▼
 5 Existing Pixieset pipeline
 6      │
 7      ├── event
 8      │
 9      ▼
10 Worker / Lambda
11      │
12      │ image
13      ▼
14 Amazon Bedrock
15      │
16      │ multimodal inference
17      ▼
18 Generated alt text
19      │
20      ▼
21 Store with photo
22      │
23      ▼
24 Website Builder
25      │
26      ▼
27 Photographer reviews

Một bước inference được gắn thêm vào dòng xử lý vốn đã tồn tại. AWS cho biết integration này không yêu cầu Pixieset tự provision GPU hay tự host model; Bedrock cung cấp API để gọi foundation model. Hệ thống từ đó tăng lên khoảng 750.000 inference trong tuần đầu tiên mà Pixieset không phải provision server phục vụ model riêng. (Amazon Web Services, Inc.)

Điểm cần chú ý ở đây là:

AI không trở thành kiến trúc.

AI chỉ là một node trong kiến trúc.

Đây là khác biệt khá quan trọng.

Nhiều hệ thống hiện nay được thiết kế kiểu:

 1                 AI
 2              /  |  \
 3             /   |   \
 4            /    |    \
 5         AI     AI     AI
 6          \      |      /
 7           \     |     /
 8             Agent
 9               |
10            Database

Nhìn rất tương lai.

Nhưng đôi khi sản phẩm chỉ cần:

1old_pipeline()
2    ↓
3one_ai_call()
4    ↓
5continue_old_pipeline()

Xong thuật toán, quá dễ.

Nhưng production không đơn giản là gọi API

Nếu chỉ nhìn diagram trên thì có cảm giác:

1caption = ai.generate(image)

xong.

Thực tế, AI feature có một đặc tính hơi khó chịu.

Người dùng thường dễ tha thứ cho một nút thông thường bị lỗi.

Nhưng họ ít tha thứ hơn khi AI liên tục:

1Something went wrong.
2Please try again.

Bởi AI vốn đã bắt đầu với một khoản nợ niềm tin.

Nếu lần đầu dùng đã lỗi, người dùng rất dễ kết luận:

Biết ngay mà, AI làm ăn được gì.

Pixieset vì vậy sử dụng Cross-Region inference của Amazon Bedrock. Bedrock có khả năng phân phối inference request sang các Region phù hợp trong inference profile, qua đó tăng khả năng sử dụng compute và throughput thay vì buộc ứng dụng tự viết toàn bộ routing logic. (AWS Documentation)

Ngoài ra, theo case study của AWS, nếu model đầu tiên thất bại, Pixieset còn retry bằng một model thứ hai có chất lượng tương đương. AWS cho biết feature này chưa ghi nhận downtime kể từ khi launch. (Amazon Web Services, Inc.)

Ý tưởng có thể hình dung đơn giản như sau:

1def generate_alt_text(image):
2    try:
3        return primary_model(image)
4    except Exception:
5        return fallback_model(image)

Production thật tất nhiên còn timeout, retry policy, rate limiting, observability và nhiều thứ khác.

Nhưng ý chính là:

1AI model
2    │
3    X
4   lỗi
5    │
6    ▼
7Fallback model

Model có thể không ổn định.

Product không được phép không ổn định theo nó.

Đừng cưới model

Pixieset ban đầu launch feature vào đầu năm 2025 với Claude 3.5 Sonnet thông qua Amazon Bedrock, lựa chọn model dựa trên khả năng hiểu ảnh, tốc độ inference và chi phí. (Amazon Web Services, Inc.)

Nhưng một quyết định kiến trúc khác cũng đáng chú ý:

Họ không để toàn bộ sản phẩm kết hôn với một model.

Có thể hình dung:

1Application
2     │
3     ▼
4Amazon Bedrock
5     │
6 ┌───┼───────────────┐
7 ▼   ▼               ▼
8Model A          Model B
9                     ...

Khi model mới xuất hiện, đội ngũ có thể benchmark rồi chuyển model mà không phải viết lại toàn bộ pipeline phía trên. AWS mô tả Bedrock cung cấp interface chung cho nhiều model provider, giúp Pixieset thử model mới với chi phí thay đổi kiến trúc thấp hơn. (Amazon Web Services, Inc.)

Điều này đặc biệt quan trọng trong thời đại model thay đổi tính bằng tháng.

Nếu application code của mình dính cứng vào:

1special_prompt_for_model_xyz_v17_final_final_2()

thì sáu tháng sau rất có thể chúng ta đang sở hữu một di tích khảo cổ.

Lớp AI nên thay được.

Business logic không nên chết theo model.

Nhưng kiến trúc hay nhất lại nằm trong giao diện

Có một chi tiết cực kỳ đáng tiền trong thiết kế của Pixieset.

Họ không bật auto-generate cho toàn bộ website ngay từ lần đầu.

Ban đầu, photographer thấy AI suggestion cho từng bức ảnh.

Người dùng có thể:

 1AI generates caption
 2        │
 3        ▼
 4 ┌──────────────┐
 5 │ Photographer │
 6 └───────┬──────┘
 7         │
 8    ┌────┼─────┐
 9    ▼    ▼     ▼
10 Accept Edit Reject

AI đưa ra lời đề nghị.

Con người quyết định.

Dùng vài lần.

Thấy:

Ồ, con này làm cũng được.

Rồi vài lần nữa.

Thấy 95 tấm nó viết ổn, sửa vài chữ là xong.

Niềm tin bắt đầu được hình thành bằng trải nghiệm chứ không phải bằng banner:

OUR AI IS SAFE AND AMAZING.

Sau đó người dùng mới có thể bật auto-apply cho toàn portfolio, và nội dung vẫn có thể chỉnh sửa. AWS xem cách triển khai từng bước này là một nguyên nhân quan trọng giúp người dùng tự xây dựng niềm tin vào hệ thống. (Amazon Web Services, Inc.)

Đây chính là:

Progressive automation

Không phải:

1Manual → FULL AUTO

mà:

 1Manual
 2   ↓
 3AI Suggest
 4   ↓
 5AI + Human Review
 6   ↓
 7AI Mostly Trusted
 8   ↓
 9Auto Apply
10   ↓
11Human Can Override

Con người không giao tay lái vì một slide PowerPoint bảo rằng model có accuracy 97%.

Con người giao tay lái sau khi ngồi cạnh nó một lúc và thấy:

Thằng này lái được.

Trust không phải checkbox

Đây là chỗ AI product khác software truyền thống khá nhiều.

Giả sử mình xây calculator.

Người dùng nhập:

1123 + 456

ra:

1579

Sau vài lần, họ gần như mặc định calculator đúng.

Nhưng generative AI là probabilistic system.

Hôm nay:

1Ảnh: cô dâu chú rể trên bãi biển.
2
3AI:
4"A bride and groom walking along a beach."

Rất đẹp.

Ngày mai AI có thể nhìn một cái cột phía sau rồi tưởng thành người thứ ba.

Vì vậy trust cần tích lũy.

Có thể nghĩ một cách hơi thô:

Không phải công thức khoa học gì cả.

Nhưng nó cho thấy một điều.

Mất quyền kiểm soát cũng làm giảm trust.

Cho nên hệ thống:

1AI làm → user kiểm tra

thường dễ được chấp nhận hơn:

1AI làm hết → cầu trời

đặc biệt trong giai đoạn đầu.

35% adoption thực ra nói lên điều gì?

Con số 35% nghe không hoành tráng như:

199% USERS LOVE OUR AI

nhưng mình lại thích nó hơn.

AWS cho biết khoảng 16 tháng sau, 35% nhóm người dùng phù hợp của Pixieset vẫn sử dụng feature; đồng thời 35% người dùng cuối cùng đã chọn bật full automation theo cách họ tự xây dựng niềm tin qua trải nghiệm. (Amazon Web Services, Inc.)

Điều đáng chú ý không chỉ nằm ở con số.

Mà là đường đi:

 1AI suggestion
 2      ↓
 3User thử
 4      ↓
 5User kiểm tra
 6      ↓
 7AI đúng nhiều lần
 8      ↓
 9User tin
10      ↓
11User tự bật automation

Không ai ép họ.

Không cần biến toàn bộ UI thành một cái nút khổng lồ:

1✨ GENERATE WITH AI ✨

Feature tự chứng minh giá trị.

Đây là một kiểu adoption rất khỏe.

Must-have và moat là hai chuyện khác nhau

AWS rút ra thêm một bài học khá thực dụng.

Không phải AI feature nào cũng đáng xây thành một hệ thống nghiên cứu ba năm.

Pixieset xem AI alt text như một must-have, chứ không phải một moat dài hạn.

Hai khái niệm này nên tách ra.

Must-have

Là thứ khách hàng dần kỳ vọng sản phẩm phải có.

Ví dụ sau này hầu hết website builder đều có thể:

1image → alt text

Nếu đối thủ nào cũng làm được thì feature này khó trở thành lợi thế cạnh tranh bền vững.

Do đó:

ship nhanh, đủ tốt, tích hợp đẹp.

Moat

Là thứ càng chạy lâu càng khó sao chép.

Ví dụ:

110 năm dữ liệu hành vi riêng
2        +
3feedback loop
4        +
5workflow đặc thù
6        +
7distribution
8        ↓
9competitive advantage

Nếu nhầm hai thứ này, engineering team rất dễ dành một năm fine-tune một model mà sáu tháng sau API bên ngoài đã làm tương đương.

Pixieset chọn tốc độ.

Kết quả là từ concept tới production khoảng bốn tháng. (Amazon Web Services, Inc.)

Không train foundation model.

Không mua một núi GPU.

Không thành lập “Pixieset AGI Research Laboratory”.

Chỉ giải quyết vấn đề.

Đôi khi API call đắt nhất là API call không ai dùng

Có một thứ chúng ta rất thích đo khi xây AI:

1tokens/s
2latency
3TTFT
4GPU utilization
5accuracy
6benchmark
7cost / 1M tokens

Tất cả đều cần.

Nhưng có một metric còn quan trọng hơn:

1Có ai dùng không?

Một inference request giá 0,001 USD nhưng chẳng ai cần vẫn là tiền vứt đi.

Một model accuracy cao hơn 3% nhưng feature nằm ở tab thứ bảy mà không ai mở thì cũng chẳng cứu được gì.

Có thể viết vui thành:

$$ AI\ Product\ Value \approx Problem\ Value \times Adoption \times Quality $$

Nếu:

$$ Problem\ Value = 0 $$

thì:

$$ AI\ Product\ Value = 0 $$

cho dù Quality có bay lên trời.

Đây là lý do bài toán của Pixieset thú vị hơn chuyện chọn Claude hay một model khác.

Model chỉ giải bài toán sau khi product team chọn đúng bài toán.

Một bức ảnh thật ra kéo theo cả một dây chuyền vật lý

Nhìn bên ngoài, người photographer chỉ bấm:

1Generate

Một cái click.

Rất nhẹ.

Nhưng không có gì là hoàn toàn ảo.

Tấm ảnh được mã hóa thành hàng triệu byte dữ liệu, chạy qua mạng, đi vào hạ tầng cloud; một worker thức dậy, message được đưa qua queue, dữ liệu được gửi tới hệ thống inference, những con chip ngoài một trung tâm dữ liệu nào đó bắt đầu dịch chuyển hàng tỷ phép tính, tensor chạy qua các tầng neural network, bộ nhớ đọc rồi ghi, chip nóng lên, hệ thống làm mát mang nhiệt ra khỏi silicon; vài giây sau một chuỗi token quay trở lại:

1Bride and groom walking through a field...

Rồi photographer bấm Accept.

Cả một nhà máy vật lý vừa chuyển động chỉ để giải quyết một việc mà trước đây một con người phải ngồi gõ bằng bàn phím.

Nghe hơi điên.

Nhưng đây lại chính là bản chất của automation từ thời máy hơi nước đến LLM.

Ta tiêu tốn máy móc vào những thứ máy móc làm tốt để con người giữ thời gian cho thứ con người muốn làm.

Photographer quay trở lại với photograph.

Bài học lớn hơn: đừng tự động hóa con người, hãy tự động hóa ma sát

Nếu phải rút case Pixieset thành một diagram duy nhất, mình sẽ viết thế này:

 1                    USER WORKFLOW
 2                         │
 3        ┌────────────────┼─────────────────┐
 4        ▼                ▼                 ▼
 5     Craft            Chore            Friction
 6      │                 │                 │
 7      │                 └────────┬────────┘
 8      │                          │
 9      │                          ▼
10      │                         AI
11      │                          │
12      └────────── Human ◄────────┘

Đừng bắt đầu bằng:

“Chúng ta có model multimodal mới, làm gì với nó đây?”

Hãy bắt đầu bằng cách ngồi cạnh người dùng.

Nhìn họ làm việc.

Có thể một ngày họ click cùng một nút 300 lần.

Có thể họ copy dữ liệu từ Excel sang ERP.

Có thể họ đọc 50 email để tìm ba cái cần trả lời.

Có thể họ phải đặt tên 500 sản phẩm.

Có thể họ phải viết description cho 2.000 ảnh.

Có thể họ phải kiểm tra 100 dòng dữ liệu chỉ để tìm ba dòng bất thường.

Ở đâu đó trong workflow luôn tồn tại những đoạn như vậy.

Những đoạn nhỏ.

Những đoạn xấu xí.

Không xuất hiện trong keynote.

Không ai muốn khoe trên LinkedIn.

Nhưng con người đang mất hàng nghìn giờ cuộc đời vào đó.

Đó thường là nơi AI nên xuất hiện đầu tiên.

Một checklist nhỏ khi nghĩ về AI feature

Trước khi code, mình nghĩ có thể hỏi sáu câu:

1. Người dùng có thực sự phải làm việc này không?

Không phải:

“AI có làm được không?”

Mà:

“Nếu chúng ta không giải quyết, người dùng vẫn phải làm nó chứ?”

Nếu câu trả lời là không, có thể chúng ta đang phát minh ra nhu cầu.

2. Họ có ghét việc đó không?

Một task:

• lặp lại,
• nhàm chán,
• tốn thời gian,
• ít sáng tạo,

là ứng viên cực đẹp cho AI.

3. AI có đang đụng vào thứ người dùng tự hào không?

Nếu có, phải rất cẩn thận.

Đừng tự động hóa phần công việc tạo nên bản sắc của họ chỉ vì model làm được.

4. Người dùng có thể kiểm tra kết quả không?

Pixieset cho:

1Accept
2Edit
3Reject

Đơn giản nhưng cực kỳ quan trọng.

5. Có thể tăng automation dần không?

Từ:

1Suggest one

sang:

1Generate all

thường dễ chấp nhận hơn việc bắt đầu bằng full auto.

6. Đây là moat hay must-have?

Nếu chỉ là must-have:

Đừng xây NASA để đi mua bánh mì.

Dùng API.

Ship.

Đo adoption.

Xong rồi mới tính tiếp.

Tổng kết

Case Pixieset nhìn qua chỉ là một feature:

1Image → Multimodal LLM → Alt text

Không có RAG phức tạp.

Không có multi-agent.

Không có một đoàn agent tự tranh luận với nhau.

Không có vector database.

Không có graph.

Không có AGI.

Nhưng từ ý tưởng tới production chỉ khoảng bốn tháng, tuần đầu tạo hơn 750.000 alt text và sau khoảng 16 tháng, feature vẫn đạt mức sử dụng khoảng 35% trong nhóm người dùng phù hợp. (Amazon Web Services, Inc.)

Phần kỹ thuật tất nhiên quan trọng: event-driven architecture, Amazon Bedrock, multimodal model, cross-Region inference, fallback model và khả năng thay model mà không phải đập lại application.

Nhưng bài học lớn nhất lại xảy ra trước khi một dòng code được viết.

Pixieset không hỏi:

AI có thể thay photographer ở đâu?

Họ hỏi:

Có việc gì photographer đang phải làm mà thật ra chẳng photographer nào muốn dành đời mình để làm?

Và họ tìm thấy alt text.

Một ô text bé tí.

Đằng sau nó là model, cloud, hàng tỷ phép tính và cả một hạ tầng vật lý khổng lồ.

Nhưng phía trước nó chỉ có một con người vừa được trả lại vài giờ để tiếp tục làm nghề của mình.

Có lẽ AI product tốt nhất không phải thứ khiến người dùng phải thốt lên:

“Trời ơi AI thông minh quá.”

Mà là thứ vài tháng sau họ chẳng còn nghĩ về AI nữa.

Họ chỉ biết một việc phiền phức nào đó đã biến mất khỏi cuộc đời.

Và thế là đủ.

Tham khảo

• AWS — How Pixieset achieved 35% AI feature adoption by solving the right problem with Amazon Bedrock https://aws.amazon.com/blogs/machine-learning/how-pixieset-achieved-35-ai-feature-adoption-by-solving-the-right-problem-with-amazon-bedrock/

• Pixieset — AI-generated alt text and page descriptions for Pixieset Website https://blog.pixieset.com/blog/ai-alt-text-website/

• Pixieset Help Center — Generating SEO Content for your Website https://help.pixieset.com/hc/en-us/articles/32291043718285-Generating-SEO-Content-for-your-Website

• Google Search Central — Image SEO Best Practices https://developers.google.com/search/docs/appearance/google-images

• W3C Web Accessibility Initiative — Images Tutorial https://www.w3.org/WAI/tutorials/images/

• AWS Documentation — Cross-Region inference in Amazon Bedrock https://docs.aws.amazon.com/bedrock/latest/userguide/cross-region-inference.html