Trí tuệ Tài liệu Doanh nghiệp: Xây dựng RAG từng bước, từ quy mô tối thiểu đến quy mô kho ngữ liệu

Mô hình ngôn ngữ lớn Trí tuệ tài liệu doanh nghiệp: Chuỗi bài viết về xây dựng RAG từng bước, từ quy mô tối thiểu đến quy mô kho ngữ liệu Dành cho các kỹ sư AI muốn hiểu rõ từng bước, không chỉ gọi thư viện Angela Shi Ngày 22/5/2026 25 phút đọc Chia sẻ Khoảng ba năm trước, AI tạo sinh bùng nổ và RAG xuất hiện như một giải pháp tiêu chuẩn cho câu hỏi “chúng tôi có tài liệu, chúng tôi muốn đặt câu hỏi”. Ý tưởng này nghe có vẻ kỳ diệu. Cách triển khai mà mọi người mô tả đều giống nhau, lặp đi lặp lại: chia nhỏ tài liệu, đẩy các đoạn tài liệu vào kho vector, nhúng câu hỏi, truy xuất top-k theo độ tương đồng cosine, tùy chọn sắp xếp lại, gửi kết quả đến một LLM. Các nhà cung cấp hội tụ vào đó. Các bản trình bày tư vấn hội tụ vào đó. Các bài nói chuyện tại hội nghị hội tụ vào đó. Công thức RAG mà mọi người mô tả: chia nhỏ, kho vector, top-k cosine, tùy chọn sắp xếp lại, LLM – Hình ảnh của tác giả. Sau đó, các triển khai bắt đầu được đưa vào sử dụng và kết quả thường gây thất vọng. Người dùng không tin tưởng vào câu trả lời. Các trích dẫn mơ hồ hoặc thiếu sót. Các đoạn văn được truy xuất thường lạc đề cũng như hữu ích. Và phản xạ của nhóm, mỗi lần, là kéo thêm công cụ từ cùng một hộp công cụ: một mô hình mạnh hơn, một cửa sổ ngữ cảnh dài hơn, một công cụ sắp xếp lại tốt hơn, nhiều MLOps hơn cho phía sản xuất. Cách tiếp cận luôn giống nhau: “đây là một vấn đề về CNTT. Cơ sở hạ tầng tốt hơn, công cụ tốt hơn, mô hình tốt hơn sẽ khắc phục nó”. Tôi bắt đầu tự mình xem xét vấn đề này, trên các tài liệu doanh nghiệp thực tế, với các chuyên gia lĩnh vực thực tế trong phòng. Kinh nghiệm của tôi không phù hợp với cách tiếp cận đó. Công việc thực sự tạo ra sự khác biệt không phải là về cơ sở hạ tầng. Đó là kỹ thuật, cộng với sự hiểu biết về lĩnh vực kinh doanh, cộng với một chút toán học cơ bản. Không phải toán học chuyên sâu. Chỉ đủ để thấy một embedding thực sự đo lường điều gì, một reranker thực sự làm gì, tại sao một thủ thuật cụ thể hữu ích trong một số trường hợp và gây hại trong những trường hợp khác. Và sau đó, phần mà hầu hết các nhóm bỏ qua: hiểu rõ các tài liệu mà hệ thống phải trả lời câu hỏi. Ai đọc chúng. Chúng chứa gì. Từ vựng mà các chuyên gia sử dụng. Những câu hỏi nào xuất hiện hàng tuần. Hầu hết các công ty không phải là Google. Họ cũng không phải là các phòng thí nghiệm nghiên cứu. Họ không chạy QA (Hỏi đáp) miền mở trên web mở. Họ không tự đào tạo các mô hình embedding của riêng mình. Họ có một vài loại tài liệu cốt lõi, vài chục chuyên gia lĩnh vực đã nắm rõ kho ngữ liệu, và một tập hợp các câu hỏi lặp đi lặp lại cần câu trả lời có trích dẫn và dấu vết kiểm toán. Kiến trúc phù hợp cho bối cảnh đó không phải là những gì các bản trình bày của nhà cung cấp đưa ra và không phải là những gì các bài báo nghiên cứu theo đuổi. Đó là một kiến trúc khuếch đại các chuyên gia và sử dụng truy xuất rẻ tiền, có thể dự đoán được khi có thể. Hầu hết các hệ thống RAG mà tôi đã thấy trong sản xuất doanh nghiệp đều tệ hơn một tập lệnh Python trăm dòng. Các nguyên tắc cơ bản bị hỏng, và việc chồng chất thêm không giúp ích gì. Các embedding quá mơ hồ về ý nghĩa để chọn đoạn văn phù hợp, và việc phân tích cú pháp cẩu thả đến mức LLM nhận được đầu vào rác, đầu ra rác. Khi một hệ thống như vậy bắt đầu gặp sự cố, phản xạ tiêu chuẩn là thêm các lớp: một reranker, một mô hình embedding được tinh chỉnh mà không ai có thể biết là có ích, một tác nhân viết lại truy vấn, một tác nhân chấm điểm, một khung điều phối biến mỗi câu hỏi thành mười cuộc gọi LLM. Mỗi lớp tăng thêm tính hợp lý cho bản demo. Không có lớp nào khắc phục được nền tảng: vẫn không có cách nào để biết liệu các đoạn văn được truy xuất có đúng hay không, và vẫn không có cách nào để giải thích cho người dùng tại sao một trang cụ thể lại được trả về. Tập lệnh chúng tôi sẽ xây dựng trong bài viết đầu tiên có khoảng một trăm dòng và không có cơ sở dữ liệu vector, không có framework và không có tác nhân. Nó nhận một tệp PDF và một câu hỏi, phân tích, truy xuất ba trang hàng đầu bằng cách sử dụng độ tương đồng cosine đơn giản, gửi chúng đến một LLM với lược đồ Pydantic và trả về một câu trả lời có cấu trúc với các trích dẫn dòng và một tệp PDF nguồn được đánh dấu. Tập lệnh đó có thể kiểm chứng và hữu ích hơn nhiều so với nhiều hệ thống sản xuất tôi đã thấy tận mắt. Khoảng cách giữa hai bên không phải là kỹ thuật nhắc lệnh, và cũng không phải là một thuật toán truy xuất tốt hơn. Nó đến từ ba thói quen mà ngành công nghiệp bỏ qua: hiểu rõ tài liệu, hiểu những gì các chuyên gia đã biết và không nhầm lẫn RAG với học máy. Loạt bài này kết nối những thói quen đó vào một quy trình gồm bốn khối: phân tích tài liệu, phân tích câu hỏi, truy xuất, tạo, với một bước chú thích PDF tùy chọn để trả lại trích dẫn cho người đọc. Bốn khối cộng với chú thích PDF, với dữ liệu được đặt tên trên mỗi mũi tên – Hình ảnh của tác giả 1. RAG được sử dụng trong doanh nghiệp như thế nào 1.1 Bài báo năm 2020: truy xuất như ngữ cảnh Vào tháng 5 năm 2020, Patrick Lewis và các đồng nghiệp tại Facebook AI Research đã đặt ra thuật ngữ này trong Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (Lewis et al. 2020, bản in trước arXiv). Tóm tắt của họ nêu ra ba lỗi mà kiến trúc này được thiết kế để khắc phục, được trích dẫn trực tiếp: Các mô hình được đào tạo trước “không thể dễ dàng mở rộng hoặc sửa đổi bộ nhớ của chúng, không thể cung cấp thông tin chi tiết về các dự đoán của chúng một cách trực tiếp và có thể tạo ra ‘ảo giác’.” Giải pháp kết hợp một bộ tạo (BART) với một chỉ mục vector dày đặc trên Wikipedia, được truy cập tại thời điểm suy luận. Động thái kiến trúc quan trọng: lấy một đoạn văn từ một kho ngữ liệu, đưa nó cho LLM, để nó tạo ra từ ngữ cảnh đó thay vì chỉ từ bộ nhớ trong quá trình đào tạo. Ba lỗi đó ánh xạ rõ ràng vào ba thuộc tính mà RAG doanh nghiệp đang đấu tranh: tính mới của kho ngữ liệu, trích dẫn, câu trả lời có căn cứ. Loạt bài này là sự tiếp nối trực tiếp của dòng tư duy năm 2020 đó, được áp dụng cho các ràng buộc của doanh nghiệp. 1.2 “RAG” có nghĩa là gì trong loạt bài này Đối với hầu hết các nhà phát triển ngày nay, “RAG” đã thu hẹp lại thành một công thức cụ thể: một kho vector, truy xuất độ tương đồng nhúng và một LLM ở cuối. Loạt bài này sẽ tiếp tục sử dụng từ này, nhưng theo nghĩa rộng hơn ban đầu của nó: trích xuất thông tin, tìm kiếm thông tin và trả lời câu hỏi trên một kho tài liệu. Cơ chế truy xuất là một lựa chọn thiết kế mà kiến trúc cho phép, không phải là một phần của định nghĩa. Nhiều quy trình doanh nghiệp mà loạt bài này bảo vệ d