Compliance AI — khi model không phải nhân vật chính

Hai team xây AI xử lý hồ sơ nội bộ trên cùng Bedrock. Điều quyết định thành bại không phải model, mà là cách tổ chức knowledge layer bên dưới.

Nếu bạn đang build hệ thống AI để xử lý tài liệu nội bộ — compliance, bug triage, hay bất kỳ quy trình nào đòi hỏi đọc hiểu hàng ngàn file rời rạc — câu hỏi đầu tiên bạn Google chắc là "nên dùng model nào?".

Sai câu hỏi.

Mình vừa đọc kỹ hai case study từ Amazon Finance và Miro. Hai team, hai bài toán khác nhau, cùng dùng Amazon Bedrock làm backbone. Nhưng điều thú vị nhất không nằm ở model. Nó nằm ở những quyết định kiến trúc mà cả hai team đều phải giải trước khi model được gọi lần đầu tiên.

Hai bài toán, một nút thắt giống nhau

Amazon Finance vận hành hệ thống xử lý yêu cầu từ cơ quan quản lý — regulatory inquiries — trên nhiều khu vực pháp lý khác nhau. Mỗi yêu cầu đến dưới dạng PDF, PowerPoint, Word, CSV — đủ loại. Team phải tổng hợp thông tin từ hàng ngàn tài liệu lịch sử, tìm tiền lệ phù hợp, rồi biên soạn phản hồi đúng deadline.

Miro — platform phục vụ hơn 95 triệu người dùng — có bài toán khác: routing bug report đến đúng team. Với gần 100 đội kỹ thuật, mỗi bug report thường thiếu context, lẫn lộn giữa text, stack trace, screenshot. Kết quả? Bug bị chuyển vòng vòng giữa các team, ước tính gây lãng phí tương đương 42 năm công suất mỗi năm chỉ vì routing sai.

Hai bài toán nghe khác xa nhau. Nhưng nút thắt cốt lõi giống hệt: knowledge fragmentation — dữ liệu tri thức nằm rải rác, không có cấu trúc, và không ai nắm được toàn cảnh.

Quyết định trước dòng code đầu tiên

Cả hai team đều chọn Bedrock, đều dùng RAG. Nhưng kiến trúc knowledge layer (tầng tổ chức và truy xuất tri thức) mới là nơi phân định kết quả.

Amazon Finance không xây một knowledge base chung cho cả công ty. Mỗi team tài chính tạo và duy trì knowledge base riêng, chỉ chứa tài liệu và tham chiếu của team đó. Quyết định này nghe đơn giản, nhưng nó giải quyết một vấn đề mà nhiều team Việt Nam đang mắc: nhồi hết mọi thứ vào một index rồi thắc mắc sao retrieval kém.

Nói thẳng ra: tách knowledge base theo domain không phải vì kỹ thuật phức tạp, mà vì ngữ cảnh mỗi domain khác nhau. Tài liệu thuế khác tài liệu kiểm toán, dù cùng nằm trong "Finance". Khi bạn trộn lẫn, model phải tự phân biệt — và nó sẽ sai ở những chỗ bạn không ngờ.

Miro đi theo hướng khác: thay vì chỉ dùng nội dung bug report, họ bổ sung thêm product context — thông tin về kiến trúc sản phẩm, vùng trách nhiệm của từng team — vào pipeline phân loại. Đây là điều biến bài toán multi-class classification (phân loại nhiều nhóm) từ "đoán mò" thành "suy luận có cơ sở".

Hãy nghĩ thế này: nếu bạn đưa một bộ hồ sơ cho hội đồng xét xử mà không kèm bối cảnh vụ việc, họ sẽ phải tự suy diễn — và mỗi người suy một kiểu. Cung cấp đủ chứng cứ kèm ngữ cảnh, phán quyết chính xác hơn hẳn. AI xử lý tài liệu cũng vậy.

Con số — và điều phía sau con số

Miro công bố kết quả: giảm 6 lần số lần bug bị chuyển nhầm team, thời gian xử lý rút ngắn 5 lần. Ấn tượng, nhưng phần đáng học hơn là tại sao con số đó xảy ra.

Không phải vì model giỏi hơn. Mà vì pipeline có đủ context để model ra quyết định đúng. Khi bug report được bổ sung metadata về product area, model không cần "đoán" team nào sở hữu tính năng đó — nó có dữ kiện.

Amazon Finance thì không công bố metric cụ thể, nhưng kiến trúc của họ tiết lộ một ưu tiên khác: observability (khả năng quan sát và truy vết). Với hệ thống compliance, biết tại sao AI trả lời như vậy quan trọng không kém việc trả lời đúng. Họ xây lớp theo dõi toàn bộ quá trình: từ tài liệu nào được truy xuất, đến cách câu trả lời tiến hóa qua nhiều lượt trao đổi.

Plot twist: phần tốn công nhất trong cả hai hệ thống không phải prompt engineering hay chọn model. Mà là thiết kế cách tổ chức dữ liệu và xây feedback loop (vòng phản hồi để hệ thống tự cải thiện).

Ba câu hỏi trước khi builder Việt Nam bắt tay xây

Từ hai case study này, mình rút ra một framework nhỏ — ba câu bạn nên trả lời trước khi viết dòng code đầu tiên:

1. Knowledge base nên tách hay gộp?
Nếu dữ liệu của bạn phục vụ nhiều domain với thuật ngữ và ngữ cảnh khác nhau, tách ra. Chi phí vận hành thêm một vài index rẻ hơn rất nhiều so với chi phí debug retrieval sai.

2. Context nào cần bổ sung ngoài nội dung gốc?
Giả sử team bạn 5 người, đang xây chatbot nội bộ đọc tài liệu quy trình. Đừng chỉ nhồi tài liệu vào vector store. Hãy hỏi: metadata nào giúp model phân biệt tài liệu quy trình HR với tài liệu quy trình kỹ thuật? Version nào còn hiệu lực? Ai là owner?

3. Observability đặt ở đâu?
Đây là phần bị bỏ quên nhiều nhất. Với hệ thống nội bộ, bạn cần biết: model truy xuất tài liệu nào, tại sao chọn tài liệu đó, và người dùng cuối có chấp nhận kết quả không. Không có lớp này, bạn đang vận hành một hệ thống mà không ai kiểm chứng được — giống tòa xử án mà không ghi biên bản phiên tòa.

Bắt đầu từ đâu?

Nếu bạn đang ở giai đoạn đầu, đây là thứ tự ưu tiên thực tế:

Tuần 1 — Audit dữ liệu: Gom hết tài liệu nội bộ liên quan, phân nhóm theo domain. Đánh dấu tài liệu nào còn hiệu lực, tài liệu nào cần loại. Bước này không cần AI, chỉ cần một spreadsheet và sự kiên nhẫn.

Tuần 2 — Prototype với scope nhỏ: Chọn một domain duy nhất, xây knowledge base cho domain đó. Dùng Bedrock, hoặc nếu ngân sách hạn chế, thử open-source stack: Qdrant hoặc pgvector cho vector store, kết hợp với bất kỳ LLM nào bạn đang có quyền truy cập.

Tuần 3 — Bổ sung observability: Log lại mỗi query: tài liệu nào được retrieve, score bao nhiêu, người dùng có feedback gì. Đừng đợi đến lúc có vấn đề mới bắt đầu log — lúc đó đã muộn.

Một cái bẫy phổ biến: nhiều team nhảy thẳng vào tuần 2, skip tuần 1, rồi tự hỏi sao retrieval toàn trả về tài liệu hết hạn từ năm ngoái. Dữ liệu rác vào thì kết quả rác ra — model dù xịn đến đâu cũng không cứu được.

Bài học lớn nhất từ cả Amazon Finance lẫn Miro không phải về công nghệ. Nó về kỷ luật tổ chức dữ liệu và thiết kế hệ thống trước khi nghĩ đến model — phần việc ít hào nhoáng nhất, nhưng quyết định mọi thứ phía sau.

---

Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng