Thiết kế một Lớp Kiến thức Bền vững Không Phỏng đoán

Trí tuệ nhân tạo Thiết kế một lớp tri thức bền vững không phỏng đoán RAG chỉ truy xuất, không bao giờ ghi nhớ. Một bản thiết kế trung lập về nhà cung cấp cho các ứng dụng tích lũy sự hiểu biết. Bao gồm một triển khai Azure-native hoàn chỉnh (Microsoft Foundry, Azure AI Search, Cosmos DB, FastAPI) được ánh xạ tới một kho dữ liệu bảo hiểm tài sản. Miodrag Cekikj Ngày 16/8/2026 49 phút đọc Chia sẻ Ảnh của Will Grobbelaar trên Unsplash Trong loạt bài RAG-ING Ahead của mình, tôi đã thực hiện một ngăn xếp truy xuất đám mây-native hoàn chỉnh: xử lý giọng nói và tài liệu, phân đoạn (chunking), nhúng (embeddings), Azure AI Search và một lớp trợ lý nằm trên cùng. Loạt bài đó đã trả lời câu hỏi mà tôi có vào thời điểm đó, về cơ bản là 'làm thế nào để tôi khiến một mô hình ngôn ngữ trả lời các câu hỏi về các tài liệu mà nó chưa từng được huấn luyện'? Ngăn xếp này vẫn hoạt động. Retrieval-Augmented Generation (RAG) vẫn là cách thực tế nhất để định vị một mô hình trong thông tin riêng tư, chuyên biệt hoặc mới thay đổi mà không cần huấn luyện lại bất cứ điều gì.[1] Nếu bạn có một kho dữ liệu và cần câu trả lời từ đó, RAG vẫn là nơi bạn bắt đầu. Nhưng tôi đã chạy mô hình này được một thời gian, trên các dự án kéo dài hơn một bản demo, và một câu hỏi khác bắt đầu làm tôi bận tâm: Hệ thống truy xuất cùng một đoạn văn, suy luận về nó, đưa ra một câu trả lời tốt — và sau đó loại bỏ tất cả suy luận đó. Ngày mai, ai đó hỏi một câu hỏi liên quan, và nó lại thực hiện công việc tương tự, từ đầu, với cùng chi phí, mà không đảm bảo đạt được cùng một kết luận. Bản năng đầu tiên của tôi là điều chỉnh bộ máy thay vì đặt câu hỏi về nó. Tôi đã thử nghiệm với các cơ chế bộ nhớ đệm (caching) khác nhau dựa trên nhúng: nhận ra rằng một câu hỏi đến gần về mặt ngữ nghĩa với một câu hỏi mà hệ thống đã trả lời, và phục vụ phản hồi trước đó thay vì phải trả tiền cho toàn bộ quá trình truy xuất và tạo lại. Bộ nhớ đệm ngữ nghĩa thực sự giúp giảm chi phí và độ trễ, và tôi vẫn sẽ khuyến nghị nó. Nhưng phải mất một thời gian tôi mới thừa nhận bản chất thực sự của nó. Nó lưu trữ câu trả lời, không phải sự hiểu biết. Phản hồi được lưu trữ cũng dễ bị loại bỏ như phản hồi gốc. Không có gì về mô hình miền của hệ thống được cải thiện, và ngay khi một câu hỏi nằm ngoài ngưỡng tương đồng, công việc lại bắt đầu từ con số không. Dù tôi đã điều chỉnh gì, khái niệm kiến trúc RAG chính bên dưới vẫn giữ nguyên. Hình 1 – Bộ nhớ đệm ngữ nghĩa mà tôi đang thử nghiệm. Một lần trùng khớp là một lối tắt qua quy trình; một lần không trùng khớp bắt đầu từ con số không. Dù bằng cách nào, không có gì được tích lũy — hộp đứt nét là phần hóa ra bị thiếu. Hình ảnh do tác giả cung cấp. Đó không phải là vấn đề truy xuất. Truy xuất đang thực hiện chính xác những gì nó được thiết kế để làm. Đó là một vấn đề kiến trúc. Không có nơi nào trong một hệ thống RAG tiêu chuẩn để sự hiểu biết được tích lũy. Không có lượng bộ nhớ đệm, sắp xếp lại hay chiến lược phân đoạn nào có thể khắc phục điều đó, bởi vì tất cả chúng đều tối ưu hóa việc tra cứu, không có cái nào cung cấp cho hệ thống một bộ nhớ. Bài viết này nói về việc xây dựng nơi còn thiếu đó. Đây là kết quả của công việc và thử nghiệm mới nhất của tôi xung quanh RAG, GraphRAG và suy luận tác nhân (agentic reasoning) trên một kho tài liệu, điểm mà các điều chỉnh gia tăng không còn đủ nữa và bản thân thiết kế phải thay đổi. Tôi sẽ trình bày nó trong ba phần. Phần I mang tính trung lập về nhà cung cấp. Phần này mô tả kiến trúc như một mẫu thiết kế: các lớp, mô hình đối tượng, các chế độ lỗi mà nó được tạo ra để tồn tại và cơ chế quản trị mà nó đòi hỏi. Không có phần nào phụ thuộc vào Azure, hay bất kỳ cơ sở dữ liệu hoặc nhà cung cấp mô hình cụ thể nào. Nếu bạn đang sử dụng AWS, GCP, hoặc chạy Postgres với pgvector và một mô hình cục bộ, thiết kế này vẫn có giá trị và tôi mong muốn nó hữu ích cho bạn. Phần II là triển khai trên Azure. Từng dịch vụ một, với lý do cho mỗi lựa chọn, hạ tầng dưới dạng mã (infrastructure-as-code) thực tế và một ứng dụng FastAPI đang chạy mà bạn có thể sao chép và triển khai. Phần III là phần trình diễn. Một công ty bảo hiểm tài sản tổng hợp có tên Ostermere Mutual, hai mươi mốt tài liệu liên kết với nhau và ba hướng dẫn chi tiết cho thấy mẫu thiết kế này thực hiện được điều mà một hệ thống truy xuất thông thường không thể làm được. Tất cả dữ liệu trong bộ dữ liệu đều là tổng hợp. Ostermere Mutual không tồn tại. Cơ quan quản lý, chính sách, yêu cầu bồi thường, con người, các khu vực gió hoặc các số liệu cũng không tồn tại. Không có nội dung nào ở đây là lời khuyên về bảo hiểm, pháp lý, thẩm định hoặc yêu cầu bồi thường, và không có trang nào trong bản demo đại diện cho một cách giải thích thực tế về bất kỳ chính sách thực tế nào. Lưu ý về tên gọi: tài liệu hiện tại của Microsoft sử dụng Microsoft Foundry cho nền tảng hợp nhất trước đây gọi là Azure AI Foundry. Tôi sử dụng Foundry xuyên suốt, đồng thời giữ nguyên các tên dịch vụ Azure quen thuộc ở những nơi giúp kiến trúc dễ theo dõi hơn. Mục lục Phần I – Thiết kế: 1. Nơi RAG cổ điển hoạt động và nơi nó dừng lại 2. Truy xuất không phải là sự hiểu biết tích lũy 3. Ba lớp 4. Điều gì thực sự tồn tại trong lớp kiến thức 5. Sáu chế độ lỗi 6. Viết kiến thức là một loại rủi ro khác 7. Định tuyến truy vấn 8. Khi nào bạn không nên xây dựng hệ thống này Phần II – Triển khai trên Azure: 9. Ánh xạ các lớp với các dịch vụ 10. Blob Storage 11. Document Intelligence 12. Azure AI Search 13. Cosmos DB 14. Microsoft Foundry 15. FastAPI trên Container Apps 16. Định danh 17. Vòng đời nhập liệu Phần III – Phần trình diễn: 18. Ostermere Mutual 19. Quy tắc có phạm vi 20. Sự mâu thuẫn 21. Ngày xảy ra tổn thất 22. Kho Obsidian 23. Lập luận về chi phí 24. Quản trị 25. Những gì tôi sẽ xây dựng tiếp theo 26. Tóm tắt tất cả Dự án hoàn chỉnh (ứng dụng, hạ tầng, bộ dữ liệu và một kho Obsidian sẵn sàng mở) có sẵn trong kho lưu trữ GitHub đi kèm tại github.com/mcekikj/persistent-knowledge-layer, theo giấy phép MIT. Phần I – Thiết kế 1. Nơi RAG cổ điển hoạt động và nơi nó dừng lại Một luồng RAG thông thường đủ đơn giản để vẽ trong một dòng. Hình 2 – Quy trình RAG cổ điển. Mọi câu hỏi bắt đầu từ bên trái. Không có gì tồn tại sau bên phải.