Công cụ đo lường AI Architecture: Cách đánh giá RAG trước khi scale lên Production

RAG chạy được chưa có nghĩa là kiến trúc đã sẵn sàng cho Production.

Một hệ thống RAG có thể trả lời đúng trong buổi demo chỉ sau vài ngày. Tài liệu được đưa vào vector database, model truy xuất được context và người dùng đã nhìn thấy câu trả lời đầu tiên.

Nhưng khi workload bắt đầu có nhiều người dùng, nhiều nguồn dữ liệu và nhiều quyền truy cập khác nhau, câu hỏi không còn là “RAG có chạy không?”. Team cần biết kiến trúc hiện tại đang có những control nào, control nào mới chỉ là giả định, khoảng trống nào có thể trở thành production incident và nên cải thiện điều gì trước.

Đây là lúc doanh nghiệp cần một cách đo lường AI Architecture - không phải để chấm model mạnh hay yếu, mà để biến kiến trúc thành các capability, control, evidence, gap và hành động cải thiện có thể xem xét được.

“Đo lường AI Architecture” nghĩa là gì?

Trong bài viết này, đo lường AI Architecture không có nghĩa là tự động quét toàn bộ hạ tầng rồi tuyên bố hệ thống đã an toàn hoặc sẵn sàng production.

Đó là quá trình đánh giá có cấu trúc một workload cụ thể:

• Xác định workload, người dùng và outcome cần bảo vệ.
• Kiểm tra các architecture capability và technical control quan trọng.
• Ghi nhận evidence hiện có thay vì chỉ dựa trên câu trả lời “team đã làm rồi”.
• Phân biệt critical gap, production blocker, improvement và evidence gap.
• Chuyển findings thành improvement plan, owner và KPI có thể theo dõi.

Một công cụ đo lường AI Architecture cần nối được ba lớp: hiện trạng kỹ thuật, quyết định ưu tiên và kế hoạch cải thiện.

RAG chạy được chưa phải một architecture baseline

Một workload RAG thường đi qua nhiều lớp:

• Người dùng và ứng dụng.
• Identity và access policy.
• Query processing và retrieval orchestration.
• Embedding, vector search, metadata filter và reranking.
• Model generation và output handling.
• Logging, evaluation, monitoring và incident response.

Chỉ cần pipeline trả về một câu trả lời chưa đủ để kết luận toàn bộ kiến trúc đã sẵn sàng.

Có vector database không đồng nghĩa retrieval đang tốt. Có IAM không đồng nghĩa quyền truy cập tài liệu đã được áp dụng đúng. Có logging không đồng nghĩa team trace được một câu trả lời sai qua toàn bộ retrieval-generation pipeline. Có evaluation cũng chưa chắc evaluation phản ánh traffic, edge case và failure mode thực tế.

Một architecture baseline cần mô tả được hệ thống đang làm gì, được phép làm gì, phụ thuộc vào đâu, được đánh giá thế nào và ai chịu trách nhiệm khi nó không hoạt động như kỳ vọng.

Khác gì checklist, benchmark và infrastructure scan?

Ba cách tiếp cận này đều hữu ích, nhưng chúng trả lời những câu hỏi khác nhau.

Cách tiếp cận	Câu hỏi chính	Giới hạn
Checklist	Team đã xem xét các hạng mục cần thiết chưa?	Dễ dừng ở trạng thái tick box, không yêu cầu evidence
Benchmark	Model hoặc hệ thống đạt kết quả bao nhiêu?	Một con số tổng hợp có thể che khuất failure mode và control gap
Infrastructure scan	Tài nguyên và cấu hình nào đang tồn tại?	Không tự hiểu business outcome, behavior và operating ownership
Architecture assessment	Capability nào tồn tại, evidence ở đâu, gap nào quan trọng và phải cải thiện thế nào?	Phụ thuộc vào phạm vi workload và chất lượng thông tin đầu vào

Architecture assessment không thay thế code review, security testing, load test hay production monitoring. Nó tạo một cấu trúc chung để các hoạt động đó được đặt đúng vào bối cảnh của workload và quyết định kiến trúc.

Sáu miền cần nhìn khi đánh giá một Enterprise RAG workload

Không phải workload nào cũng sử dụng cùng một stack. Tuy nhiên, một assessment thực tế nên nhìn được ít nhất sáu miền sau.

1. Business outcome và ownership

• Workload phục vụ ai và hỗ trợ quyết định hoặc workflow nào?
• Một kết quả thành công được đo bằng gì?
• Failure nào có thể chấp nhận, failure nào không?
• Ai là business owner, technical owner và người chấp nhận kết quả?

Nếu outcome không rõ, team rất dễ tối ưu retrieval score hoặc model quality mà không biết việc đó có cải thiện công việc thật hay không.

2. Data và retrieval

• Nguồn dữ liệu nào được phép đưa vào corpus?
• Source document, chunk, embedding và index có version hay không?
• Metadata, tenant boundary và access filter được áp dụng ở đâu?
• Freshness được theo dõi thế nào?
• Citation có trỏ lại đúng nguồn đã dùng để tạo câu trả lời không?

Retrieval quality là vấn đề kiến trúc, không chỉ là prompt engineering.

3. Model và generation

• Model được chọn dựa trên quality, latency, cost và risk nào?
• Structured output được kiểm tra ra sao?
• Khi model hoặc provider lỗi, hệ thống fallback hay degraded thế nào?
• Prompt, model version và generation policy có thể truy vết không?

Một model mạnh hơn không tự động tạo ra workload đáng tin cậy hơn nếu phần context và control phía trước không ổn định.

4. Application và integration

• RAG được gọi từ ứng dụng nào?
• Input được chuẩn hóa và kiểm tra ở đâu?
• Output được hiển thị, lưu lại hay dùng để kích hoạt hành động nào?
• Các API, tool và downstream system có contract rõ ràng không?

Khi output của AI bắt đầu tác động đến workflow thật, application boundary trở thành một phần của AI Architecture.

5. Operations và reliability

• Team có trace được một request từ input tới retrieval, model và response không?
• Latency, error, token usage và cost được attribution theo workload nào?
• Indexing failure, stale data và provider incident được phát hiện ra sao?
• Có runbook, fallback, rollback và owner xử lý sự cố không?

Production readiness không phải trạng thái đạt được một lần. Nó là khả năng quan sát và cải thiện workload khi hệ thống tiếp tục thay đổi.

6. Security và governance

• Identity của người dùng và workload được xác định thế nào?
• Least privilege được áp dụng ở từng lớp nào?
• Sensitive data có thể đi vào prompt, log hoặc model ngoài ý muốn không?
• Ai phê duyệt policy exception và high-risk action?
• Evidence nào được lưu để audit một quyết định hoặc incident?

Guardrail chỉ ở output không thể bù cho một retrieval layer đã đưa sai dữ liệu vào context.

Worked example - RAG assistant trước khi mở rộng toàn doanh nghiệp

Giả sử một doanh nghiệp có RAG assistant dùng cho support team. Tài liệu đến từ nhiều phòng ban, một số tài liệu có quyền truy cập hạn chế, người dùng đăng nhập bằng tài khoản doanh nghiệp và câu trả lời cần đi kèm citation.

Sau giai đoạn thử nghiệm với 20 người, team muốn mở hệ thống cho toàn công ty.

Nếu chỉ nhìn vào demo, kết luận có thể là “RAG đang hoạt động”. Nhưng trước khi scale, team cần trả lời các câu hỏi khác:

Miền	Câu hỏi cần trả lời
Outcome	Câu trả lời “đạt” được đo theo tiêu chí nào?
Retrieval	Chunking, metadata, freshness và citation được kiểm chứng ra sao?
Access	Quyền của người dùng có được áp dụng trước khi context vào model không?
Evaluation	Có case thật, edge case và access-denied case hay chưa?
Reliability	Khi model, vector store hoặc nguồn dữ liệu lỗi thì hệ thống degraded thế nào?
Operations	Ai chịu trách nhiệm khi retrieval quality giảm hoặc index không được cập nhật?

Vấn đề của workload lúc này không còn là “chọn model nào”. Team cần biết control nào đã tồn tại, control nào mới chỉ là giả định và control nào phải trở thành engineering backlog.

Control phải đi cùng evidence

Một control không nên được coi là “đã có” chỉ vì team nói rằng đã triển khai.

• “Có access control” cần evidence về identity, filtering boundary và negative test.
• “Có evaluation” cần dataset, expected outcome, threshold và người phê duyệt.
• “Có observability” cần trace được retrieval, generation, error và latency.
• “Có rollback” cần chỉ ra version nào được quay lại và state được reconcile thế nào.
• “Có data governance” cần source owner, classification, retention và deletion path.

Evidence không nhất thiết phải là một tài liệu đồ sộ. Nó có thể là configuration, test result, trace, dashboard, runbook, ticket, architecture decision record hoặc một policy đã được owner xác nhận.

Điểm quan trọng là một người khác có thể kiểm tra lại kết luận của assessment mà không phải đứng cạnh người đã xây hệ thống.

Một kiến trúc tốt không chỉ chạy được, mà còn phải thay đổi được

Đến đây, assessment vẫn đang nhìn workload ở trạng thái hiện tại: hệ thống có capability nào, control nào đang tồn tại và evidence nào chứng minh điều đó.

Nhưng production architecture không đứng yên. Model được nâng cấp, embedding thay đổi, dữ liệu tiếp tục tăng, quyền truy cập được mở rộng và một runtime hôm nay phù hợp có thể không còn phù hợp sau một năm.

Vì vậy, một câu hỏi khác cần được đưa vào quá trình đo lường:

Nếu phải thay đổi một thành phần quan trọng của workload, kiến trúc hiện tại có giữ được capability, context và control mà doanh nghiệp đang phụ thuộc hay không?

Đây là nơi AI Architecture Assessment gặp AI Migration.

AI Migration như một architecture stress test

AI Migration không chỉ là đổi API endpoint. Với một workload RAG, hệ thống còn phụ thuộc vào prompt, embedding, vector index, chunking, metadata, retrieval logic, access filter, evaluation set, observability và cách ứng dụng sử dụng kết quả.

Nếu những thành phần này không được xác định rõ, việc thay đổi model hoặc runtime không còn là một quyết định kiến trúc có kiểm soát. Nó trở thành quá trình tìm lại những dependency mà team đã vô tình tạo ra trong nhiều tháng vận hành.

Có thể dùng các câu hỏi migration như một bài stress test cho kiến trúc hiện tại:

Câu hỏi migration	Điều nó tiết lộ
Có thể thay model mà không viết lại toàn bộ application không?	Mức độ coupling giữa model và application
Có thể rebuild vector index từ nguồn dữ liệu gốc không?	Data provenance và khả năng tái tạo retrieval layer
Có evaluation baseline để so sánh trước và sau thay đổi không?	Khả năng đo behavioral parity
Quyền truy cập có nằm ngoài model và vector database không?	Identity và authorization boundary
Có thể xác định pending workflow và scheduled task không?	Mức độ kiểm soát operational state
Có thể rollback mà không tạo duplicate action không?	Idempotency và recovery architecture
Có biết thành phần nào phụ thuộc riêng vào provider không?	Portability và vendor-dependency risk
Có người chịu trách nhiệm phê duyệt target workload không?	Ownership và acceptance governance

Bài AI Migration Framework trình bày sâu hơn về workload discovery, behavioral baseline, memory, operational state, validation, cutover và rollback. Ở đây, điều quan trọng là migration-readiness phản ánh mức trưởng thành của kiến trúc ngay cả khi doanh nghiệp chưa có kế hoạch đổi nền tảng.

Quay lại RAG: nếu đổi embedding hoặc retrieval layer thì sao?

Giả sử team muốn đổi embedding model hoặc chuyển retrieval layer sang một nền tảng khác.

Nếu chỉ còn các vector đã tạo mà không xác định được source document, chunking version, metadata schema và access rule, team không có một migration path đáng tin cậy.

Nếu có thể quay lại governed source documents, tái tạo index, giữ tenant boundary, chạy retrieval regression test và so sánh kết quả với baseline đã được phê duyệt, việc thay đổi trở thành một engineering process có kiểm soát.

Hai hệ thống đều có thể trả lời được câu hỏi của người dùng. Nhưng chỉ một hệ thống có kiến trúc đủ rõ để thay đổi mà không phải đoán.

Đây cũng là lý do công cụ đo lường AI Architecture không nên chỉ hỏi hệ thống đang sử dụng công nghệ gì. Nó cần giúp team nhìn thấy:

• Capability nào đang tồn tại?
• Control đó được chứng minh bằng evidence nào?
• Dependency nào chưa được quản lý?
• Khi kiến trúc thay đổi, baseline nào phải được giữ lại?
• Gap nào cần giải quyết trước khi scale hoặc migration?

Assessment không thực hiện migration thay cho engineering team. Nó giúp team nhìn thấy mức độ sẵn sàng trước khi thay đổi model, data, runtime hoặc provider trở thành deadline.

Từ architecture gaps đến improvement plan và KPI

Không phải mọi gap đều có mức ưu tiên giống nhau.

• Critical gate - có thể dẫn đến data exposure, hành động không được phép hoặc không thể vận hành an toàn.
• Production blocker - cần xử lý trước khi mở rộng workload.
• Improvement - có thể đưa vào roadmap theo mức độ ảnh hưởng.
• Evidence gap - control có thể tồn tại nhưng chưa đủ bằng chứng để xác nhận.

Mỗi finding nên được chuyển thành một hành động có owner, mức ưu tiên và cách đo tiến độ. Ví dụ:

Finding	Action	KPI gợi ý
Không có access-denied evaluation case	Bổ sung negative test theo nhóm quyền	100% nhóm quyền quan trọng có negative test
Không theo dõi index freshness	Ghi nhận ingestion lag và failed document	Freshness SLO và số document lỗi được theo dõi
Không version chunking pipeline	Version cấu hình và lưu source-to-index lineage	Mỗi index release truy ngược được source và pipeline version
Không có retrieval baseline	Tạo evaluation set từ query thật	Critical retrieval scenarios có pass/fail threshold
Chưa có fallback owner	Xây runbook và phân công incident owner	Runbook được tabletop test theo chu kỳ

Giá trị của assessment không nằm ở một điểm số đẹp. Nó nằm ở việc team biết điều gì cần làm tiếp theo và có thể kiểm tra kiến trúc đã cải thiện hay chưa.

Khi nào team nên thực hiện AI Architecture Assessment?

Không cần chờ đến khi workload gặp incident.

Những thời điểm phù hợp gồm:

• Trước khi bắt đầu một RAG PoC quan trọng.
• Trước khi chuyển từ PoC sang production.
• Trước khi mở rộng số người dùng, data source hoặc phạm vi quyền truy cập.
• Khi retrieval quality thiếu ổn định nhưng team chưa xác định được nguyên nhân.
• Trước khi đổi model, embedding, vector store, runtime hoặc provider.
• Sau một incident cần chuyển lessons learned thành architecture improvement.
• Khi CTO hoặc engineering leadership cần cơ sở để ưu tiên đầu tư.

Assessment càng sớm thì chi phí sửa architectural gap thường càng dễ kiểm soát. Nhưng assessment chỉ có giá trị khi phạm vi workload rõ ràng và người trả lời hiểu hệ thống thực tế.

Thử công cụ đo lường AI Architecture

TitanBases AI Architecture Observatory - giao diện Enterprise RAG Architecture Assessment bản tiếng Việt. Nguồn: TitanBases AI Architecture Observatory.

TitanBases AI Architecture Observatory hiện cung cấp Enterprise RAG Architecture Assessment cho một workload cụ thể. Assessment sử dụng 18 technical controls để tạo capability view, xác định critical gaps, đề xuất prioritized actions và suggested KPIs.

Đây là self-reported architecture assessment. Công cụ không tự động scan infrastructure, không thay thế security audit và không cấp chứng nhận production readiness.

Bạn có thể thử công cụ đo lường AI Architecture mà không cần kết nối trực tiếp vào hệ thống đang vận hành.

Kết luận

Khi RAG mới được xây dựng, team thường hỏi model nào tốt, vector database nào nhanh và framework nào dễ triển khai.

Khi RAG bắt đầu đi vào vận hành, câu hỏi thay đổi. Dữ liệu nào được phép xuất hiện trong context? Ai biết retrieval đang giảm chất lượng? Một thay đổi nhỏ trong chunking, embedding hoặc model sẽ được đánh giá bằng baseline nào? Nếu hệ thống trả lời sai, ai có đủ evidence để xác định lỗi nằm ở đâu?

AI Architecture Assessment không thay thế việc thiết kế hay triển khai hệ thống. Nó giúp team nhìn thẳng vào những gì đã có, những gì còn đang được giả định và những gì phải được làm trước khi scale biến một khoảng trống nhỏ thành sự cố production.

Một workload không cần đợi đến khi gặp incident mới bắt đầu tự đánh giá kiến trúc của chính nó.

Ghi chú tác giả

Tác giả làm việc tại TitanBases trong các dự án liên quan đến cloud, data và AI architecture. Bài viết trình bày góc nhìn kỹ thuật về việc đánh giá kiến trúc RAG, migration-readiness và cải thiện workload; không phải chứng nhận hoặc cam kết production readiness.