Ngân hàng đề — AWS Certified Generative AI Developer Pro

Đáp án

C — Cấu hình Amazon OpenSearch Service với Neural Search plugin; triển khai plugin để bật truy xuất lai ngữ nghĩa và từ khoá trên các index theo chủ đề; cấu hình tăng tốc bằng ANN, tinh chỉnh shard và tối ưu mapping để giảm độ trễ dưới tải đồng thời.

Vì sao đúng

Đề liệt kê năm khả năng cụ thể, và chúng cùng chỉ về một hướng: đội muốn kiểm soát chi tiết, không muốn dịch vụ lo hộ. | Khả năng đề yêu cầu | Cơ chế | |---|---| | Phân đoạn nội dung theo chủ đề | index riêng theo chủ đề | | Kết hợp ngữ nghĩa với độ chính xác từ khoá | hybrid search của Neural Search | | Tăng tốc bằng ANN | HNSW hoặc IVF | | Tinh chỉnh mapping, shard, replica | chỉ OpenSearch Service cho phép | | Chịu đỉnh tải sự kiện lớn | replica + shard tính toán trước |

Hai vế cuối là điểm quyết định, và cũng là lý do câu này chọn OpenSearch chứ không chọn Knowledge Bases như #6406:

Đề nói rõ đội PHẢI tinh chỉnh index mapping, số shard và chiến lược replica. Đó là những thứ dịch vụ được quản lý không phơi ra.

Hybrid search giải quyết đúng nhu cầu của nền tảng tin tức:

{"query": {"hybrid": {"queries": [
  {"match": {"noi_dung": "tên riêng, mã chứng khoán, thuật ngữ chính xác"}},
  {"neural": {"embedding": {"query_text": "...", "k": 50}}}
]}}}

Với tin tức, thành phần đầu rất quan trọng: embedding hay bỏ sót tên riêng vì chúng ít xuất hiện trong dữ liệu huấn luyện — mà tên riêng lại là thứ nhà phân tích tìm nhiều nhất.

Và index theo chủ đề cho hai lợi ích: truy vấn chỉ quét index liên quan (nhanh hơn), và shard tinh chỉnh riêng cho từng chủ đề theo khối lượng thực tế.

Vì sao các phương án khác sai

• D. OpenSearch Service nhưng lưu tất cả trong MỘT index toàn cục với mapping mặc định, không phân vùng theo chủ đề, dựa vào mặc định cho mapping và shard, dùng exact k-NN trên toàn bộ dữ liệu — đây là phương án gần nhất (đúng dịch vụ) nhưng phủ định mọi yêu cầu tinh chỉnh của đề. Và exact k-NN quét toàn bộ — với hàng triệu bài mỗi ngày thì độ trễ hoàn toàn không chấp nhận được.
• B. Lưu mọi tài liệu trong Bedrock Knowledge Base, dựa vào gắn thẻ metadata phân biệt chủ đề và luồng truy xuất dựng sẵn — Knowledge Bases là dịch vụ tốt (và là đáp án đúng cho #6406), nhưng ở đây nó không cho tinh chỉnh shard, replica và mapping — đúng ba thứ đề yêu cầu.
• A. Athena federated query tìm trên metadata đã làm giàu và tra ngữ nghĩa qua API embedding bên ngoài — Athena là engine truy vấn SQL cho dữ liệu trên S3, không phải công cụ tìm kiếm; độ trễ tính bằng giây tới chục giây, hoàn toàn không hợp với "real-time insights".

Ghi nhớ

Cách chọn giữa hai lựa chọn vector search trên AWS: | Đề nói | Chọn | |---|---| | "fully managed", "without managing indexes or clusters" | Bedrock Knowledge Bases | | "tune index mappings, shard counts, replica strategies" | OpenSearch Service | | Cần hybrid search tinh chỉnh sâu | OpenSearch Service | | Cần triển khai nhanh, ít vận hành | Knowledge Bases |

Hai câu #6406 và #6422 là cặp đối chiếu rất hay: cùng bài toán tìm kiếm ngữ nghĩa trên kho tài liệu lớn, nhưng ràng buộc ngược nhau nên đáp án ngược nhau. Đọc kỹ vế yêu cầu về vận hành là cách phân biệt.

Ba thành phần của Neural Search plugin: | Thành phần | Việc | |---|---| | Ingest processor | tự sinh embedding khi index tài liệu | | Neural query | truy vấn bằng văn bản, plugin tự mã hoá | | Hybrid query | kết hợp điểm BM25 và vector trong MỘT truy vấn |

Ba trục tinh chỉnh khi chuẩn bị cho đỉnh tải: | Trục | Ảnh hưởng | |---|---| | Số shard | song song hoá — quá ít thì nghẽn, quá nhiều thì tốn overhead | | Số replica | thông lượng đọc — mỗi replica phục vụ được truy vấn | | ef_search | đánh đổi recall với độ trễ, chỉnh được lúc truy vấn |

Trục thứ hai là công cụ trực tiếp cho "query spikes during major events": tăng replica trước sự kiện lớn để tăng năng lực đọc, rồi giảm lại sau đó.

Và một lưu ý về bộ nhớ với HNSW ở quy mô hàng triệu bài mỗi ngày: đồ thị HNSW phải nằm trong RAM. Khi dữ liệu vượt bộ nhớ node, hiệu năng sụp đổ chứ không giảm dần. Hai hướng xử lý: product quantization (giảm bộ nhớ 4–32 lần, đổi lấy chút recall) hoặc lifecycle theo thời gian — tin tức cũ chuyển sang index lạnh hơn, vì phần lớn truy vấn nhắm vào nội dung gần đây.

Đáp án

A và C.

• A — Triển khai MCP server chạy trên Lambda cho các công cụ không trạng thái, nhẹ như tính toán nhỏ và tra cứu nhanh; phơi chúng qua giao diện tuân thủ MCP
• C — Cấp phát MCP server chạy trên ECS cho các công cụ mô phỏng đóng gói container cần GPU hoặc chạy lâu; cho model gọi chúng qua CÙNG giao diện MCP với công cụ nhẹ

Vì sao đúng

Đề nêu ba yêu cầu, và cụm quyết định là "unified framework... in a consistent way": | Yêu cầu | Cơ chế | |---|---| | Việc nhẹ chạy với độ trễ tối thiểu | A — Lambda, khởi động nhanh | | Việc nặng chạy trong môi trường chuyên dụng, co giãn | C — ECS với GPU | | Model truy cập cả hai theo CÁCH THỐNG NHẤT | cùng giao thức MCP |

Vế thứ ba là điểm phân biệt then chốt với phương án B, và nó là toàn bộ giá trị của MCP:

Model Context Protocol là một giao thức chuẩn để model gọi công cụ. Server chạy ở đâu, bằng công nghệ gì — model không cần biết.

Foundation model
      ↓ giao thức MCP (một cách gọi duy nhất)
      ├─ MCP server trên Lambda  → tính toán nhẹ (mili giây)
      └─ MCP server trên ECS+GPU → mô phỏng (hàng giờ)

Nhờ đó, thêm một công cụ mới không phải sửa cách model gọi công cụ — dù công cụ đó chạy trên Lambda hay trên một cụm GPU. Đó chính là nghĩa của "extensible tool framework" mà đề yêu cầu.

Chọn nền tảng theo hình dạng workload: | | Lambda | ECS | |---|---|---| | Thời gian tối đa | 15 phút | không giới hạn | | GPU | ❌ | ✅ | | Khởi động | mili giây (đã ấm) | giây tới phút | | Chi phí khi rảnh | 0 | có (trừ khi scale về 0) | | Hợp với | tra cứu, tính toán nhỏ | mô phỏng dài, cần GPU |

Vì sao các phương án khác sai

• B. MCP server trên Lambda cho công cụ nhẹ, nhưng dùng API Gateway endpoint riêng kích hoạt mô phỏng trên ECS; cấu hình model chỉ dùng MCP cho tiện ích nhanh, gọi API Gateway RIÊNG cho mô phỏng — đây là phương án gần nhất và sai ở đúng vế "unified": hai giao diện khác nhau cho hai loại công cụ nghĩa là model phải biết công cụ nào gọi kiểu nào, và mỗi công cụ mới lại phải quyết định thuộc nhóm nào. Đó là chính thứ MCP sinh ra để loại bỏ.
• D. Một cụm ECS duy nhất chạy MCP server cho cả tính toán nhanh lẫn mô phỏng GPU; mọi request qua cùng một bộ container bất kể quy mô — lãng phí và chậm: chạy một phép tính nhỏ trên container GPU là trả tiền GPU cho việc không cần GPU, và cụm phải luôn sẵn sàng nên không có lợi ích chi phí khi rảnh. Đề nói rõ việc nhẹ cần "minimal latency", việc nặng cần "dedicated compute" — tức là hai môi trường.
• E. Lambda cho CẢ hai loại, tăng bộ nhớ và timeout cho mô phỏng; model gọi thẳng Lambda cho mọi thao tác không phân biệt loại workload — Lambda không chạy được mô phỏng dài: trần cứng 15 phút và không có GPU. Tăng bộ nhớ không vượt qua được hai giới hạn đó.

Ghi nhớ

Model Context Protocol (MCP) — ba khái niệm: | Khái niệm | Nghĩa | |---|---| | MCP server | nơi cung cấp công cụ, tài nguyên, prompt | | MCP client | phía model, gọi tới server | | Transport | stdio, HTTP/SSE — cách hai bên nói chuyện |

Giá trị cốt lõi: một giao thức, nhiều nơi triển khai. Cùng một model gọi được công cụ chạy trên Lambda, ECS, EC2, hay máy cục bộ — mà không cần biết gì về nơi chúng chạy.

Chọn nền tảng cho MCP server: | Nền tảng | Hợp với | |---|---| | Lambda | không trạng thái, ngắn, tải thất thường | | ECS/Fargate | chạy lâu, cần container tuỳ chỉnh | | ECS/EC2 với GPU | mô phỏng, suy luận model nặng | | AWS Batch | job theo lô, xếp hàng, chạy hàng giờ |

Dòng cuối đáng cân nhắc cho đề này: nếu mô phỏng chạy rất lâu và theo lô, AWS Batch phù hợp hơn ECS thường — và MCP server vẫn có thể đóng vai trò gửi job rồi trả về job ID, thay vì giữ kết nối chờ hàng giờ.

Đó dẫn tới một mẫu thiết kế quan trọng cho công cụ chạy lâu:

Model gọi công cụ mô phỏng
    ↓ MCP server: gửi job, TRẢ VỀ NGAY job ID
Model tiếp tục việc khác
    ↓ sau đó gọi công cụ "kiểm tra trạng thái job"
    ↓ khi xong: gọi "lấy kết quả"

Giữ model chờ hàng giờ trong một lời gọi công cụ là không khả thi — timeout ở mọi tầng sẽ cắt ngang. Tách thành gửi–kiểm tra–lấy kết quả là cách đúng, và nó vẫn nằm trọn trong giao diện MCP thống nhất.

Và ba biện pháp an toàn cho MCP server trong môi trường nghiên cứu:

1. IAM role riêng cho mỗi server — công cụ tính toán nhẹ không cần quyền khởi tạo instance GPU.
2. Giới hạn tài nguyên cho job mô phỏng — tránh một truy vấn vô tình khởi động một cụm rất lớn.
3. Ghi vết ai gọi công cụ nào — cần cho cả kiểm soát chi phí lẫn tái lập kết quả nghiên cứu.

Đáp án

B — Dùng Bedrock Provisioned Throughput cấp năng lực model dành riêng cho nhu cầu đỉnh, cấu hình phân bổ token mỗi giây theo mẫu đột biến dự kiến; theo dõi mức sử dụng bằng CloudWatch và điều chỉnh số provisioned unit để giữ phản hồi nhanh trong các đợt tăng tải.

Vì sao đúng

Đề nêu hai yêu cầu của hai bên khác nhau, và chúng kéo về hai hướng: | Bên | Yêu cầu | |---|---| | Tài chính | chi tiêu hằng tháng ĐOÁN TRƯỚC ĐƯỢC | | Chủ sản phẩm | phản hồi nhanh ổn định KỂ CẢ lúc cao điểm |

Provisioned Throughput đáp ứng cả hai cùng lúc, và đó là điều không phương án nào khác làm được: | Yêu cầu | Cách đáp ứng | |---|---| | Chi phí đoán trước | cam kết theo giờ hoặc tháng — con số cố định | | Không bị throttle | năng lực dành riêng, không chia với ai | | Độ trễ ổn định | không xếp hàng chung với traffic on-demand |

Đây là điểm khác biệt căn bản với on-demand:

On-demand:    trả theo token → chi phí BIẾN ĐỘNG theo lưu lượng
              dùng chung năng lực → BỊ THROTTLE lúc cao điểm

Provisioned:  trả theo model unit đã cam kết → chi phí CỐ ĐỊNH
              năng lực dành riêng → không throttle, độ trễ ổn định

Model unit là đơn vị cấp phát, mỗi unit cho một mức thông lượng token mỗi phút đảm bảo:

aws bedrock create-provisioned-model-throughput   --model-id anthropic.claude-3-5-sonnet-20241022-v2:0   --provisioned-model-name tro-ly-ho-tro-prod   --model-units 4   --commitment-duration OneMonth

Và vế "monitor utilization and adjust" trong đáp án là phần vận hành không thể bỏ: nếu cấp quá ít thì vẫn bị throttle, cấp quá nhiều thì lãng phí. CloudWatch cho biết mức sử dụng thực để hiệu chỉnh cho chu kỳ sau.

Vì sao các phương án khác sai

• D. Dùng on-demand với giá trị retry và timeout cao để làm mượt throttling; alarm trên độ trễ và tăng bộ nhớ ở client — đây là phương án gần nhất và sai về bản chất: retry không tạo ra năng lực. Bị throttle rồi thử lại nghĩa là request chờ lâu hơn, đúng thứ chủ sản phẩm muốn tránh. Và tăng bộ nhớ ở client không liên quan gì tới throttling phía dịch vụ.
• A. Lambda gọi on-demand API cho mọi request và đặt bộ nhớ Lambda cao để tối ưu thông lượng; dựa vào Lambda scaling hấp thụ đột biến thay vì điều chỉnh năng lực model — nhầm nút thắt: Lambda co giãn tốt, nhưng Bedrock mới là chỗ bị throttle. Cho 1.000 Lambda cùng gọi một endpoint đang giới hạn chỉ làm tình hình tệ hơn.
• C. Triển khai model trên SageMaker real-time endpoint với instance nhỏ nhất và dựa vào auto scaling xử lý mọi đỉnh tải; tăng giới hạn gọi đồng thời ở phía ứng dụng — auto scaling có độ trễ: khởi tạo instance mới mất vài phút, còn đợt tăng tải khuyến mãi đến trong vài giây. Và tự host model trên SageMaker không cho chi phí đoán trước như tài chính yêu cầu (instance-giờ thay đổi theo số instance đang chạy).

Ghi nhớ

Ba chế độ năng lực của Bedrock: | Chế độ | Chi phí | Độ trễ | Dùng khi | |---|---|---|---| | On-demand | theo token, biến động | có thể bị throttle | tải thấp hoặc thất thường | | Cross-Region inference | theo token | hấp thụ đỉnh qua nhiều Region | không muốn cam kết | | Provisioned Throughput | cố định theo cam kết | ổn định, không throttle | tải lớn, cần đoán trước |

Cách chọn theo từ khoá trong đề: | Đề nói | Chọn | |---|---| | "predictable monthly spending" + "consistently fast" | Provisioned Throughput ← câu này | | "không cấp thừa", "không giữ sẵn năng lực" | cross-Region inference | | Tải thấp, thất thường | on-demand |

Cặp #6358 và #6424 là một đối chiếu đáng nhớ: cả hai đều nói về đỉnh tải, nhưng #6358 cấm cấp thừa nên loại Provisioned Throughput, còn #6424 yêu cầu chi phí đoán trước nên chọn đúng nó. Đọc kỹ ràng buộc chi phí là cách phân biệt.

Ba lựa chọn cam kết của Provisioned Throughput: | Cam kết | Đặc điểm | |---|---| | Không cam kết | linh hoạt, giá cao nhất, huỷ bất cứ lúc nào | | 1 tháng | giảm giá vừa | | 6 tháng | giảm giá nhiều nhất, ràng buộc lâu nhất |

Với lưu lượng có mùa vụ như đề mô tả, mẫu thường dùng là kết hợp: cam kết một mức nền cho lưu lượng thường xuyên, và thêm provisioned unit không cam kết trong mùa cao điểm, hoặc để phần vượt trần chảy sang on-demand.

Và ba điều cần biết khi vận hành:

1. Provisioned Throughput gắn với MỘT model cụ thể — đổi model là phải cấp lại.
2. Không phải model nào cũng hỗ trợ — kiểm tra trước khi thiết kế.
3. Theo dõi ModelUnitsUtilization — dưới 50% liên tục nghĩa là đang trả tiền cho năng lực không dùng; chạm 100% thường xuyên nghĩa là cần thêm unit.

Điểm thứ ba là công việc thật của vế "monitor and adjust" trong đáp án — và cũng là chỗ tiền bị lãng phí nhiều nhất nếu bỏ qua.

Đáp án

B — Validation bằng request model của API Gateway ép cấu trúc JSON nghiêm ngặt, cộng một Lambda tiền xử lý làm sạch và escape trường do người dùng nhập trước khi gọi model; ghi chi tiết lỗi validation và lỗi tiền xử lý vào CloudWatch Logs để chẩn đoán rõ ràng.

Vì sao đúng

Đề nêu hai vấn đề, và đáp án phải giải quyết cả hai: | Vấn đề | Cơ chế | |---|---| | Trường tuỳ chọn sai định dạng, ký tự chưa escape | schema validation + escape | | Lỗi chung chung "model invocation failed", khó chẩn đoán | log chi tiết ở từng tầng |

Vế thứ hai là thứ đề than phiền nhiều nhất, và nó có nguyên nhân rõ ràng: lỗi đang được phát hiện ở nơi xa nhất so với nguyên nhân. Model API chỉ biết "payload không hợp lệ", nó không biết trường nào sai.

Đặt validation ở cửa ngõ đảo ngược điều đó:

{
  "type": "object",
  "required": ["prompt", "taskType"],
  "properties": {
    "prompt": {"type": "string", "maxLength": 20000},
    "taskType": {"type": "string", "enum": ["summarize", "classify"]},
    "metadata": {"type": "object",
                 "properties": {"customerId": {"type": "string",
                                               "pattern": "^KH-[0-9]{6}$"}}}
  }
}

Request sai nhận 400 kèm thông báo chỉ đúng trường lỗi — không tốn một lời gọi model nào.

Lambda escape là tầng thứ hai, vì schema validation không bắt được mọi thứ: một chuỗi hợp lệ theo JSON vẫn có thể chứa ký tự phá vỡ prompt (dấu ngoặc kép chưa thoát, ký tự điều khiển, ký tự NUL).

Và hai loại log riêng biệt cho hai loại lỗi:

logger.error(json.dumps({'loai': 'loi_tien_xu_ly', 'truong': ten_truong,
                         'ly_do': str(e), 'requestId': ctx.aws_request_id}))

Vì sao các phương án khác sai

• A. API Gateway chỉ passthrough, Lambda escape ký tự đặc biệt rồi gọi model; ghi kết quả tiền xử lý vào CloudWatch — đây là phương án gần nhất và thiếu tầng validation: request thiếu trường bắt buộc hoặc sai kiểu vẫn đi qua, và vẫn hỏng ở model với thông báo mơ hồ như cũ.
• **D. SQS làm đệm xếp hàng mọi request, Lambda consumer chuẩn hoá tên trường; dựa vào DLQ bắt payload hỏng — DLQ là nơi chứa lỗi, không phải cơ chế chẩn đoán: bạn biết request hỏng nhưng không biết vì sao. Và thêm hàng đợi vào một API đồng bộ làm ứng dụng hỗ trợ khách hàng chậm hẳn.
• C. Gửi thẳng mọi request tới model và tuỳ biến chính foundation model để từ chối trường sai; metric filter cảnh báo khi model trả lỗi — không tuỳ biến model để làm validation được: model không phải bộ kiểm tra schema, và "cảnh báo khi có lỗi" là phát hiện sau chứ không phải phòng ngừa.

Ghi nhớ

Nguyên tắc fail fast at the edge — chặn ở cửa ngõ, và mỗi tầng bắt một loại lỗi: | Tầng | Bắt gì | |---|---| | JSON Schema (API Gateway) | cấu trúc, kiểu, trường bắt buộc, enum, pattern | | Lambda tiền xử lý | ký tự đặc biệt, chuẩn hoá, ràng buộc nghiệp vụ | | Model | phần còn lại |

Ba loại ký tự hay gây lỗi khi nhét dữ liệu người dùng vào prompt JSON: | Ký tự | Vấn đề | |---|---| | " chưa thoát | phá vỡ cấu trúc JSON | | Ký tự điều khiển (\x00–\x1F) | JSON không cho phép trực tiếp | | Ký tự NUL (\x00) | nhiều CSDL và thư viện từ chối |

Ba nguyên tắc viết log để chẩn đoán được: | Nguyên tắc | Chi tiết | |---|---| | Log có cấu trúc (JSON) | truy vấn được bằng Logs Insights | | Kèm định danh request | nối được các dòng log của cùng một request | | Nêu rõ trường nào sai | không phải "invalid input" |

Và một điều không nên ghi vào log: nội dung prompt đầy đủ khi nó chứa dữ liệu khách hàng. Ghi tên trường và loại lỗi là đủ để gỡ lỗi mà không tạo ra một bản sao dữ liệu nhạy cảm trong log.

Đáp án

B — Dùng SageMaker real-time inference với cấu hình nhiều instance kiểu UltraServer và bật thư viện model parallelism như DeepSpeed hoặc FasterTransformer để chia (shard) model qua nhiều GPU; cấu hình endpoint nạp các phân mảnh phối hợp qua nhiều instance và dùng mạng hiệu năng cao cho giao tiếp giữa các thiết bị lúc suy luận.

Vì sao đúng

Đề nêu ràng buộc rất rõ: model không vừa bộ nhớ của MỘT accelerator, kể cả phần cứng mạnh nhất, và không được thu nhỏ model vì sẽ mất khả năng suy luận.

Đó là bài toán model parallelism, và điểm mấu chốt là phân biệt nó với data parallelism:

Vì model không vừa một GPU, data parallelism không thể áp dụng — không có cách nào đặt một bản sao đầy đủ lên bất kỳ GPU nào. Đó là lý do A và D bị loại ngay.

Model parallelism chia trọng số theo hai chiều:

Tensor parallelism:   chia MỘT lớp qua nhiều GPU
Pipeline parallelism: chia CÁC LỚP qua nhiều GPU
                      GPU0: lớp 1–20 → GPU1: lớp 21–40 → GPU2: lớp 41–60

DeepSpeed và FasterTransformer cài đặt sẵn hai kỹ thuật này, nên bạn không phải tự viết logic chia mảnh và đồng bộ.

Và "high performance networking" trong đáp án không phải chi tiết thừa: với model chia qua nhiều instance (không chỉ nhiều GPU trong một máy), dữ liệu kích hoạt phải đi qua mạng ở mỗi lớp. Không có mạng băng thông cực cao và độ trễ thấp (EFA), giao tiếp trở thành nút thắt và độ trễ suy luận trở nên không dùng được.

Vì sao các phương án khác sai

• A. UltraServer nhiều instance nhưng dựa vào data parallelism; mỗi instance chạy một bản sao ĐẦY ĐỦ của model, đồng bộ thực thi để phối hợp phản hồi — bất khả thi: nếu model không vừa một GPU thì không instance nào nạp nổi bản sao đầy đủ. Đây là phương án gần nhất về hình thức nhưng sai ở đúng khái niệm cốt lõi.
• D. UltraServer nhiều instance nhưng TẮT model parallelism, mỗi instance nạp bản sao đầy đủ; tăng số instance và dựa vào mở rộng ngang để xử lý giới hạn bộ nhớ — cùng lỗi như A, và nói ra rõ ràng hơn: mở rộng ngang tăng THÔNG LƯỢNG, không tăng bộ nhớ khả dụng cho MỘT model. Thêm bao nhiêu máy cũng không giúp một model quá lớn vừa vào một máy.
• C. Host trên một instance GPU lớn, tăng cấp phát bộ nhớ GPU qua cấu hình container; dùng giá trị khởi tạo container mặc định — không "tăng bộ nhớ GPU" bằng cấu hình được: bộ nhớ GPU là phần cứng vật lý. Và đề đã nói rõ model không vừa kể cả phần cứng mạnh nhất.

Ghi nhớ

Ba chiến lược song song hoá — biết dùng cái nào khi: | Chiến lược | Giải quyết | |---|---| | Data parallelism | thông lượng — model vừa một GPU | | Tensor parallelism | một LỚP quá lớn cho một GPU | | Pipeline parallelism | tổng số lớp quá nhiều cho một GPU |

Với model rất lớn, thường kết hợp cả ba: tensor parallel trong một node, pipeline parallel giữa các node, data parallel cho nhiều bản sao của toàn hệ.

Bốn công cụ hỗ trợ model parallelism: | Công cụ | Ghi chú | |---|---| | DeepSpeed | ZeRO, tensor và pipeline parallel — phổ biến nhất | | FasterTransformer / TensorRT-LLM | tối ưu suy luận trên GPU NVIDIA | | vLLM | PagedAttention — thông lượng cao cho suy luận | | SageMaker model parallel library | tích hợp sẵn với SageMaker |

Ba chi tiết vận hành khi triển khai model rất lớn:

1. Kéo dài ContainerStartupHealthCheckTimeoutInSeconds (tối đa 3600) — nạp trọng số hàng trăm GB mất rất lâu, và timeout mặc định sẽ khiến container bị coi là hỏng.
2. Dùng CompressionType: None với S3 prefix — tải song song nhiều tệp nhanh hơn hẳn giải nén một model.tar.gz khổng lồ.
3. Bật EFA (Elastic Fabric Adapter) — mạng độ trễ thấp giữa các instance, thiết yếu khi model chia qua nhiều máy.

Và một lựa chọn thay thế đáng cân nhắc nếu môi trường cho phép: Bedrock hoặc SageMaker JumpStart đã có sẵn nhiều model lớn được tối ưu và triển khai hộ. Tự host chỉ đáng làm khi model là bản riêng hoặc có ràng buộc không dùng được dịch vụ quản lý — đúng như tình huống "open source model" trong đề.

Đáp án

B — Cấu hình Amazon Q Developer sinh mã khung chuẩn, tạo unit test và integration test, phát hiện dùng SDK kém hiệu quả, và tự động review theo luật kiến trúc nội bộ; tích hợp vào quy trình phát triển sao cho MỌI pull request đều được đánh giá nhất quán trước khi duyệt.

Vì sao đúng

Đề liệt kê bốn nhu cầu và một ràng buộc: | Nhu cầu | Cơ chế | |---|---| | Sinh cấu trúc mã chuẩn | Q Developer code generation | | Thực thi luật kiến trúc nội bộ | custom rules trong code review | | Phát hiện dùng SDK sai | Q Developer nhận diện mẫu SDK | | Sinh test tự động đáng tin | unit + integration test | | Không làm chậm tốc độ phát triển | tự động trong PR, không thêm bước thủ công |

Điểm phân biệt nằm ở "every pull request is evaluated consistently" — và đó là toàn bộ vấn đề đề đang mô tả.

Nguyên nhân gốc của tình trạng hiện tại: kiểm tra chất lượng đang phụ thuộc vào con người nhớ làm. Nhiều người đóng góp, mỗi người một thói quen, và kết quả là phong cách lẫn lộn, test thiếu, xử lý lỗi không nhất quán.

Một quy tắc mà không có cơ chế thực thi tự động thì là một gợi ý.

Đó là lý do B hơn hẳn ba phương án còn lại — cả ba đều để con người quyết định cuối cùng, tức là giữ nguyên nguyên nhân gốc.

Và "without slowing development velocity" được đáp ứng vì kiểm tra chạy tự động trong PR, không phải một cuộc họp review thêm.

Vì sao các phương án khác sai

• A. Q Developer sinh mã khung và test cơ bản, cấu hình review tư vấn (advisory) gắn cờ sai lệch; để lập trình viên tự quyết định về chất lượng khi review — đây là phương án gần nhất và sai ở đúng chỗ: "advisory" nghĩa là bỏ qua được. Với một đội mà vấn đề chính là mỗi người áp dụng tiêu chuẩn khác nhau, cho phép tự quyết là quay lại điểm xuất phát.
• C. Q Developer sinh template và báo cáo phân tích tĩnh thỉnh thoảng; dựa vào review thủ công; chỉ chạy kiểm tra trong chu kỳ phát hành — phát hiện quá muộn: lỗi được tìm ra khi mã đã gộp và đã tích tụ, sửa tốn hơn nhiều so với bắt ngay trong PR.
• D. Chỉ dùng Q Developer sinh đoạn mã, dựa vào quy trình duyệt của GitHub để thực thi tính nhất quán kiến trúc; review thủ công để kiểm tra cách dùng SDK — quy trình duyệt của GitHub chỉ bắt buộc phải CÓ người duyệt, nó không kiểm tra nội dung. Và review thủ công là chính thứ đang không hiệu quả.

Ghi nhớ

Ba nơi đặt cửa kiểm soát chất lượng, theo chi phí sửa lỗi tăng dần: | Nơi | Chi phí sửa | |---|---| | Lúc viết mã (IDE) | rẻ nhất — sửa ngay | | Trong pull request | rẻ — chưa gộp | | Trong chu kỳ phát hành | đắt — đã tích tụ | | Trên production | đắt nhất |

Khả năng của Amazon Q Developer đáng biết: | Khả năng | Chi tiết | |---|---| | Sinh mã | từ chú thích hoặc mô tả bằng ngôn ngữ tự nhiên | | Sinh test | unit test có độ phủ, kể cả ca biên | | Code review tự động | quét bảo mật, chất lượng, và luật tuỳ chỉnh | | Chuyển đổi mã | nâng cấp phiên bản ngôn ngữ, framework | | Giải thích mã | hữu ích với mã kế thừa |

Ba loại luật nên tự động hoá cho một nền tảng GenAI: | Luật | Ví dụ | |---|---| | Cách dùng SDK | luôn đặt timeout khi gọi Bedrock; luôn dùng retry có backoff | | Xử lý lỗi | không nuốt exception; không trả e.getMessage() ra ngoài | | Bảo mật | không log nội dung prompt chứa dữ liệu khách hàng |

Và một lưu ý về kỳ vọng: kiểm tra tự động không thay thế review của con người — nó giải phóng review của con người. Khi máy đã lo phong cách, độ phủ test và cách dùng SDK, người review tập trung được vào thứ máy không làm được: thiết kế có đúng không, và đây có phải là cách nên giải quyết vấn đề này không.

Đáp án

B — Tích hợp graph database với một engine phân tích có khả năng vector hỗ trợ tìm kiếm top-K trên văn bản đã embed lưu làm thuộc tính của node hoặc edge; chạy truy vấn tương đồng vector NGAY TRONG graph engine để việc truy xuất tôn trọng quan hệ trong đồ thị trước khi đưa kết quả cho foundation model.

Vì sao đúng

Đề nêu yêu cầu rất cụ thể: truy xuất phải cân nhắc CẢ cấu trúc đồ thị LẪN độ tương đồng ngữ nghĩa của văn bản.

Và câu hỏi ví dụ cho thấy vì sao cần cả hai:

"Nhà cung cấp nào có rủi ro gián đoạn cao nhất quý tới, và vì sao?"
                    ↓
① Ngữ nghĩa: tìm báo cáo sự cố, kết luận kiểm toán nói về "gián đoạn"
② Cấu trúc:  nhà cung cấp đó nối tới kho nào, tuyến nào, có phụ thuộc gì

Trả lời chỉ bằng ① cho ra văn bản liên quan nhưng không biết nó ảnh hưởng tới ai. Chỉ bằng ② cho ra quan hệ nhưng không biết vì sao rủi ro.

Điểm mấu chốt là THỨ TỰ và NƠI thực hiện: chạy tìm kiếm vector bên trong graph engine cho phép kết hợp hai điều kiện trong MỘT truy vấn:

MATCH (nv:NhaCungCap)-[:CUNG_CAP]->(k:Kho)-[:TUYEN]->(:DiemDen)
WHERE nv.diemRuiRo > 0.7
CALL neptune.algo.vectors.topKByNode(nv, 5)
YIELD node AS baoCao, score
RETURN nv, k, baoCao, score

Ràng buộc đồ thị (nv phải nối tới kho, điểm rủi ro trên ngưỡng) được áp trước hoặc cùng lúc với tìm kiếm vector — nên kết quả vừa liên quan về nghĩa vừa đúng về quan hệ.

Đó là điều mà tìm kiếm vector toàn cục rồi lọc sau không làm được: nếu top-K toàn cục không chứa nhà cung cấp có quan hệ liên quan, lọc sau cũng không lấy lại được nó.

Vì sao các phương án khác sai

• D. Chạy tìm kiếm vector trong vector database RIÊNG, rồi truy vấn graph database riêng để lọc kết quả; gộp hai kết quả ở phía client — đây là phương án gần nhất và mắc đúng vấn đề trên: lọc SAU khi đã lấy top-K nghĩa là những node đúng về quan hệ nhưng xếp ngoài top-K không bao giờ được xét. Và gộp ở phía client thì hai bộ điểm số không cùng thang đo.
• C. Lưu graph riêng và xuất toàn bộ node và edge sang vector store, tìm kiếm vector toàn cục, rồi gắn metadata đồ thị vào kết quả để XẤP XỈ tính nhận biết đồ thị — chữ "approximate" là điểm loại: gắn metadata sau không khôi phục được quan hệ nhiều bước. Câu hỏi "nhà cung cấp này ảnh hưởng tới tuyến nào qua kho nào" cần đi nhiều bước trong đồ thị, mà metadata phẳng không diễn đạt được.
• A. Làm phẳng toàn bộ đồ thị thành tài liệu, sinh embedding cho mỗi bản ghi gộp, tìm kiếm vector một lần; để foundation model tự suy ra quan hệ chuỗi cung ứng từ văn bản phẳng — mất hoàn toàn cấu trúc, và giao việc suy luận quan hệ cho model là mời nó bịa. Với câu hỏi rủi ro chuỗi cung ứng, một quan hệ bịa ra có hậu quả thật.

Ghi nhớ

GraphRAG — kết hợp đồ thị tri thức với truy xuất vector: | Thành phần | Đóng góp | |---|---| | Vector search | tìm nội dung liên quan về nghĩa | | Graph traversal | tìm thực thể liên quan qua QUAN HỆ | | Kết hợp trong một truy vấn | kết quả thoả cả hai |

Vì sao GraphRAG mạnh hơn RAG thuần với câu hỏi nhiều bước: | Loại câu hỏi | RAG thuần | GraphRAG | |---|---|---| | "Tài liệu nào nói về X?" | ✅ | ✅ | | "X ảnh hưởng tới ai qua đường nào?" | ❌ — quan hệ không nằm trong một tài liệu | ✅ | | "Nguyên nhân gốc của Y là gì?" | ❌ | ✅ — lần theo chuỗi phụ thuộc |

Dòng giữa là trường hợp trong đề: rủi ro gián đoạn lan truyền qua đồ thị, và không tài liệu đơn lẻ nào chứa toàn bộ đường lan truyền đó.

Hai lựa chọn trên AWS: | Lựa chọn | Đặc điểm | |---|---| | Neptune Analytics | graph engine có tìm kiếm vector dựng sẵn | | Bedrock Knowledge Bases + Neptune Analytics | GraphRAG được quản lý |

Dòng thứ hai đáng biết: Bedrock Knowledge Bases hỗ trợ Neptune Analytics làm vector store, và khi đó nó tự dựng quan hệ giữa các chunk — cho GraphRAG mà không phải tự viết truy vấn đồ thị.

Và một nguyên tắc thiết kế rút ra:

Lọc theo ràng buộc TRƯỚC hoặc TRONG lúc tìm kiếm, đừng lọc sau.

Điều này đúng cho cả metadata filter (#6360, #6412) lẫn ràng buộc đồ thị ở đây: lọc sau chỉ loại bỏ được thứ đã lấy về, nó không lấy thêm được thứ đã bị bỏ sót.

Đáp án

B — Dùng SageMaker ML Lineage Tracking tạo artifact cho dataset, job tiền xử lý, job huấn luyện và model package, rồi liên kết chúng qua action và context thành một đồ thị có hướng không chu trình (DAG); tích hợp AddAssociation API với IAM role chéo tài khoản để mọi tài khoản thử nghiệm ghi lineage về endpoint ở tài khoản production trung tâm.

Vì sao đúng

Đề nêu yêu cầu rất chặt: kiểm toán viên phải tái dựng chính xác dataset nào, job tiền xử lý nào, job huấn luyện nào và artifact nào đã đóng góp vào mỗi endpoint production — bao gồm cả liên kết qua các tài khoản thử nghiệm.

SageMaker Lineage Tracking dựng chính xác cấu trúc đó, với ba loại thực thể: | Thực thể | Nghĩa | |---|---| | Artifact | thứ tồn tại: dataset, model, image, endpoint | | Action | việc đã làm: job huấn luyện, job xử lý, lần triển khai | | Context | nhóm logic: một experiment, một pipeline |

Và association nối chúng thành DAG:

Artifact(dataset ghi chú lâm sàng)
    ↓ ContributedTo
Action(job tiền xử lý)
    ↓ Produced
Artifact(dataset đã che PHI)
    ↓ ContributedTo
Action(job huấn luyện)
    ↓ Produced
Artifact(model package)
    ↓ AssociatedWith
Artifact(endpoint production)

sm.add_association(
    SourceArn=arn_dataset,
    DestinationArn=arn_job_huan_luyen,
    AssociationType='ContributedTo')

Phần chéo tài khoản là điểm phân biệt then chốt. Đề nói rõ thử nghiệm diễn ra ở nhiều tài khoản khác nhau, và kiểm toán viên cần thấy cả những liên kết đó. AddAssociation với IAM role chéo tài khoản cho phép tài khoản thử nghiệm ghi thẳng vào đồ thị lineage trung tâm — nên không có mảnh nào bị rời ra.

Và truy vấn ngược từ endpoint là thứ kiểm toán viên thật sự cần:

LineageQuery(sm_session).query(
    start_arns=[arn_endpoint], direction=LineageQueryDirectionEnum.ASCENDANTS)

Một lời gọi cho ra toàn bộ cây tổ tiên của endpoint đó.

Vì sao các phương án khác sai

• A. Lineage Tracking ghi job huấn luyện và model package, nhưng thông tin dataset và job tiền xử lý để trong tag và CloudWatch Logs; một script báo cáo riêng gộp lineage API, tag và log để dựng đồ thị khi cần — đây là phương án gần nhất và sai ở chỗ lineage bị chia làm ba nguồn không liên kết: tag không có quan hệ, log không có cấu trúc đồ thị, và script gộp là mã tự viết dễ lệch với thực tế. Kiểm toán viên cần một nguồn sự thật, không phải một bản ghép.
• C. Glue crawler catalog dataset và dựa vào quan hệ bảng và job bookmark để SUY RA lineage; dùng Athena tái dựng khi có yêu cầu — "suy ra" không phải "ghi lại": job bookmark cho biết Glue đã đọc tới đâu, nó không ghi lại rằng dataset này đã đi vào model kia. Và Glue không biết gì về job huấn luyện SageMaker.
• D. CloudTrail và CloudWatch Logs cho mọi job và lời gọi endpoint, xuất ra S3, dựng Athena view nối sự kiện log để XẤP XỈ lineage; dựa vào timestamp và tên tài nguyên để TÁI DỰNG THỦ CÔNG — tái dựng theo timestamp là suy đoán: hai job chạy cùng lúc thì không biết cái nào dùng dataset nào. Với hồ sơ y tế chịu quản lý, "xấp xỉ" không phải là câu trả lời chấp nhận được.

Ghi nhớ

Ba thực thể của SageMaker Lineage — nhớ đúng vai: | Thực thể | Trả lời | |---|---| | Artifact | "cái gì" — dataset, model, image | | Action | "làm gì" — huấn luyện, xử lý, triển khai | | Context | "trong khuôn khổ nào" — experiment, pipeline |

Bốn loại association: | Loại | Nghĩa | |---|---| | ContributedTo | đầu vào của một action | | Produced | đầu ra của một action | | AssociatedWith | liên kết chung | | DerivedFrom | dẫn xuất từ |

Hai hướng truy vấn lineage: | Hướng | Cho biết | |---|---| | ASCENDANTS | model này từ đâu ra — dùng cho kiểm toán | | DESCENDANTS | dataset này đã ảnh hưởng tới model nào — dùng khi phát hiện dữ liệu hỏng |

Hướng thứ hai đáng biết cho tình huống sự cố: nếu phát hiện một dataset chứa dữ liệu không được phép dùng, truy vấn xuôi cho biết ngay lập tức model nào bị ảnh hưởng và phải thu hồi.

Ba điều nên làm khi vận hành lineage cho môi trường chịu quản lý:

1. Tự động tạo association trong pipeline, đừng để thủ công — SageMaker Pipelines tự ghi lineage cho các bước của nó.
2. Ghi cả artifact ngoài SageMaker (dataset trên S3, script trong Git) bằng create_artifact với SourceUri.
3. Kiểm thử việc tái dựng định kỳ — chạy thử truy vấn lineage cho một endpoint và xem có đủ đường về tới dữ liệu gốc không. Phát hiện thiếu mắt xích lúc diễn tập tốt hơn lúc kiểm toán.

Đáp án

D — Dùng Amazon Cognito với SAML federation tới nhà cung cấp danh tính doanh nghiệp, cấu hình pre-token generation Lambda trigger làm giàu token với thuộc tính phòng ban và vai trò; áp IAM policy với condition key cho địa chỉ IP nguồn và thời gian để thực thi đặc quyền tối thiểu với API foundation model.

Vì sao đúng

Đề nêu bốn yêu cầu, và D là đáp án duy nhất thoả hết: | Yêu cầu | Cơ chế | |---|---| | Liên kết danh tính doanh nghiệp vào AWS | Cognito + SAML federation | | Làm giàu token với phòng ban và vai trò | pre-token generation Lambda trigger | | Đặc quyền tối thiểu theo thuộc tính VÀ ngữ cảnh | IAM condition key: aws:SourceIp, aws:CurrentTime | | Không sửa luồng đăng nhập hiện có | SAML federation — người dùng vẫn đăng nhập ở IdP cũ |

Pre-token generation trigger là mảnh giải quyết yêu cầu thứ hai — nó cho phép thêm claim vào token ngay lúc phát hành:

def lambda_handler(event, context):
    ma_nv = event['request']['userAttributes']['employeeId']
    ho_so = tra_cuu_ho_so(ma_nv)
    event['response']['claimsOverrideDetails'] = {
        'claimsToAddOrOverride': {
            'phongBan': ho_so['phongBan'],
            'vaiTroLamSang': ho_so['vaiTro'],
            'capTruyCap': ho_so['cap']
        }}
    return event

IAM condition key cho ngữ cảnh request — đây là chỗ "time of day and source network" được thực thi:

{
  "Effect": "Allow",
  "Action": "bedrock:InvokeModel",
  "Resource": "arn:aws:bedrock:*::foundation-model/*",
  "Condition": {
    "IpAddress": {"aws:SourceIp": ["10.20.0.0/16"]},
    "DateGreaterThan": {"aws:CurrentTime": "2026-01-01T07:00:00Z"},
    "DateLessThan":    {"aws:CurrentTime": "2026-01-01T19:00:00Z"},
    "StringEquals": {"aws:PrincipalTag/phongBan": "khoa-noi"}
  }
}

Và "without modifying the existing login flows" được đáp ứng vì SAML federation nghĩa là bác sĩ vẫn đăng nhập ở hệ thống quen thuộc — Cognito chỉ nhận assertion và đổi thành token AWS.

Vì sao các phương án khác sai

• A. Custom authorizer của API Gateway xác thực token của IdP và gắn quyền truy cập model trực tiếp vào TỪNG method; quản lý thuộc tính bác sĩ trong DynamoDB và kiểm tra trong Lambda authorizer — đây là phương án gần nhất và sai ở "centralize authorization logic": gắn quyền vào từng method API là phân tán chính sách ra khắp nơi, và tự viết logic kiểm tra thuộc tính trong Lambda là dựng lại thứ IAM condition làm sẵn.
• B. IAM Identity Center với tự động cấp phát người dùng, ánh xạ vai trò doanh nghiệp sang IAM role; thực thi ràng buộc thời gian và mạng bằng service control policy — SCP là công cụ sai cho việc này: SCP đặt trần quyền cho tài khoản hoặc OU, nó không phân biệt được người dùng cá nhân hay ngữ cảnh request của họ. Và IAM Identity Center hợp cho truy cập của nhân viên vào AWS, không hợp cho ứng dụng web phục vụ hàng nghìn bác sĩ.
• C. Dùng Cognito user pool làm IdP CHÍNH và DI TRÚ danh tính bác sĩ khỏi hệ thống doanh nghiệp; áp resource-based policy và security group rule — vi phạm thẳng "without modifying the existing login flows": di trú danh tính là thay đổi lớn nhất có thể. Và security group lọc theo mạng, không lọc theo danh tính người dùng.

Ghi nhớ

Hai dịch vụ danh tính của AWS — chọn đúng cái: | | Cognito | IAM Identity Center | |---|---|---| | Dành cho | người dùng ứng dụng (khách hàng, bác sĩ) | nhân viên truy cập AWS | | Quy mô | hàng triệu | hàng nghìn | | Federation | SAML, OIDC, mạng xã hội | SAML, SCIM | | Cấp gì | token + tạm quyền AWS | quyền truy cập tài khoản và ứng dụng |

Ba Lambda trigger của Cognito đáng biết: | Trigger | Dùng để | |---|---| | Pre token generation | thêm claim vào token | | Pre sign-up | tự động duyệt hoặc từ chối đăng ký | | Post authentication | ghi log, cập nhật hồ sơ |

Các IAM condition key cho kiểm soát theo ngữ cảnh: | Condition key | Kiểm soát | |---|---| | aws:SourceIp | mạng nguồn | | aws:CurrentTime | thời gian | | aws:PrincipalTag/* | thuộc tính của người dùng — nền tảng của ABAC | | aws:SourceVpce | qua VPC endpoint nào | | aws:MultiFactorAuthPresent | có MFA không |

Dòng thứ ba là chìa khoá của ABAC (attribute-based access control): thay vì tạo một role cho mỗi tổ hợp phòng ban và vai trò, bạn gắn thuộc tính vào principal và viết một policy dùng chúng. Với một bệnh viện có hàng chục khoa và nhiều cấp bác sĩ, khác biệt là giữa vài policy và vài trăm role.

Và một lưu ý về aws:SourceIp với kiến trúc có proxy: nếu request đi qua ALB hoặc CloudFront, condition key này thấy IP của proxy, không phải của bác sĩ. Khi đó phải kiểm tra IP ở tầng ứng dụng (đọc X-Forwarded-For) hoặc dùng aws:VpcSourceIp khi lưu lượng đi qua VPC endpoint.

Đáp án

A và B.

• B — Cấu hình lại cụm OpenSearch với thêm shard, số replica tối ưu, loại instance phù hợp, và tinh chỉnh tham số ANN như ef_search và ef_construction
• A — Chia dữ liệu thành nhiều index chuyên biệt theo danh mục sản phẩm và áp tinh chỉnh ANN cùng thay đổi shard riêng cho từng index

Vì sao đúng

Đề nêu ba nguyên nhân gây chậm, và hai đáp án cùng nhau xử lý cả ba: | Nguyên nhân | Đáp án | |---|---| | Kích thước index quá lớn | A — chia theo danh mục | | Cấu hình shard chưa tối ưu | A và B | | Tham số ANN chưa tinh chỉnh | B |

B — ba trục điều chỉnh trong cùng một cụm: | Trục | Ảnh hưởng | |---|---| | Số shard | song song hoá — quá ít thì nghẽn, quá nhiều thì tốn overhead | | Số replica | thông lượng ĐỌC — mỗi replica phục vụ được truy vấn | | Loại instance | HNSW cần index nằm trong RAM | | ef_search | recall so với độ trễ, chỉnh được lúc truy vấn |

Trục replica là công cụ trực tiếp cho "hàng nghìn truy vấn đồng thời": tăng replica là tăng số bản sao phục vụ đọc.

A — chia index theo danh mục giải quyết vấn đề kích thước theo cách mà tinh chỉnh không làm được:

Một index 8 triệu vector → mỗi truy vấn duyệt không gian rất lớn

Index theo danh mục:
  thoi-trang: 3 triệu   ← truy vấn về áo quần chỉ chạm index này
  dien-tu:    2 triệu
  gia-dung:   3 triệu

Ba lợi ích: không gian tìm kiếm nhỏ hơn, shard tinh chỉnh riêng theo khối lượng thật, và index nóng có thể đặt trên node mạnh hơn.

Hai đáp án bổ sung nhau: A giảm quy mô bài toán, B tối ưu cách giải nó.

Vì sao các phương án khác sai

• C. Thay ANN bằng exact k-NN trên index đơn hiện tại và tăng dung lượng lưu trữ — đi ngược hoàn toàn: exact k-NN quét toàn bộ 8 triệu vector cho mỗi truy vấn. ANN tồn tại chính vì lý do này. Và tăng dung lượng lưu trữ không liên quan gì tới độ trễ truy vấn.
• E. Giảm về MỘT shard toàn cục và tắt replica để gom tài nguyên vào ít node hơn — loại bỏ mọi khả năng song song: một shard nghĩa là một luồng xử lý cho mỗi truy vấn, và không replica nghĩa là không có bản sao nào chia tải đọc — đúng lúc đề nói có hàng nghìn truy vấn đồng thời.
• D. Chuyển toàn bộ embedding sang Bedrock Knowledge Bases và dùng truy xuất được quản lý thay cho OpenSearch — Knowledge Bases là dịch vụ tốt, nhưng đề mô tả một đội đang muốn tinh chỉnh shard và tham số ANN — tức là cần kiểm soát mà dịch vụ quản lý không phơi ra. Và di trú 8 triệu vector là dự án lớn, không phải một "optimization strategy".

Ghi nhớ

Ba tham số HNSW và hướng đánh đổi: | Tham số | Tăng lên thì | |---|---| | ef_search | recall tốt hơn, chậm hơn — chỉnh lúc TRUY VẤN | | ef_construction | đồ thị chất lượng hơn, xây index lâu hơn | | m | recall tốt hơn, tốn bộ nhớ hơn |

ef_search là chỗ nên thử đầu tiên vì nó không cần reindex.

Danh sách kiểm khi vector search chậm dần theo quy mô: | Bước | Kiểm tra | |---|---| | 1 | Index có vượt bộ nhớ node không? — HNSW cần nằm trong RAM | | 2 | Có hot shard không? — metric theo shard, không phải theo cụm | | 3 | ef_search có phù hợp không? | | 4 | Replica có đủ cho tải đọc không? | | 5 | Có nên chia index không? |

Bước 1 quan trọng nhất ở quy mô hàng triệu vector: khi đồ thị HNSW vượt bộ nhớ, hiệu năng sụp đổ chứ không giảm dần. Hai hướng xử lý là product quantization (giảm bộ nhớ 4–32 lần, đổi lấy chút recall) hoặc thêm node.

Quy tắc thô cho số shard: | Quy tắc | Giá trị | |---|---| | Kích thước mỗi shard | 10–50 GB | | Số shard chính | bội số của số data node | | Replica cho tải đọc cao | 2 trở lên |

Và một lưu ý về việc chia index theo danh mục: nó chỉ hiệu quả khi truy vấn biết trước danh mục. Nếu người dùng tìm chung chung, bạn phải truy vấn nhiều index rồi gộp kết quả — vẫn được, nhưng lợi ích giảm. Với gợi ý sản phẩm thì thường có ngữ cảnh danh mục, nên A phù hợp.