Tại sao một câu trả lời đầy tự tin có thể tồi tệ hơn cả việc không có câu trả lời nào
Bạn vừa xây dựng xong chatbot nội bộ. Bạn nạp vào đó mọi chính sách nhân sự, thông số kỹ thuật kỹ thuật và tài liệu hướng dẫn nhân viên mới mà công ty bạn có. Một nhân viên mới hỏi về hạn mức chi phí đi lại cho các bữa tối với khách hàng. Con bot phản hồi ngay lập tức. Nghe có vẻ rất chắc chắn. Hạn mức mà nó đưa ra là 75 USD mỗi người.
Chính sách thực tế quy định là 50 USD. Con bot đã tự bịa ra câu trả lời. Nó chưa từng mở các tệp của bạn. Nó chỉ đơn giản là đoán, dựa trên các khuôn mẫu nằm sâu trong dữ liệu huấn luyện từ nhiều năm trước. Đây là thực tế phũ phàng khi chạy các mô hình ngôn ngữ lớn (LLM) thô trên các tài liệu riêng tư. Chúng không có quyền truy cập vào kiến thức nội bộ của bạn. Khi các sự thật cần thiết nằm ngoài trọng số huấn luyện (training weights), chúng sẽ thêu dệt thay vì thừa nhận là không biết. Trong môi trường thực tế (production), điều này không còn là chuyện buồn cười nữa mà bắt đầu trở thành một rủi ro.
Retrieval-Augmented Generation, hay RAG, được tạo ra để giải quyết chính xác vấn đề này. Thay vì yêu cầu mô hình phải ghi nhớ mọi thứ, bạn cho phép nó tra cứu thông tin.
Từ việc đoán mò đến việc đọc hiểu
Hãy coi một LLM thô như một đồng nghiệp tài giỏi với trí nhớ siêu phàm, nhưng người đó đã rời công ty trước khi bạn gia nhập. Họ có thể viết văn hay, giải quyết các câu đố logic và giải thích các khái niệm một cách đơn giản. Tuy nhiên, nếu hỏi họ về những thay đổi API của quý trước, họ sẽ chỉ bịa ra một thứ gì đó nghe có vẻ hợp lý. Họ không còn lựa chọn nào khác.
RAG cung cấp cho người đồng nghiệp đó quyền truy cập vào một tủ hồ sơ. Khi người dùng đặt câu hỏi, hệ thống không ném câu hỏi một cách mù quáng vào mô hình. Trước tiên, nó truy xuất các tài liệu liên quan, đưa chúng vào prompt dưới dạng ngữ cảnh, và sau đó mới yêu cầu mô hình đọc và trả lời. Mô hình chuyển từ việc hồi tưởng các sự thật sang việc thấu hiểu các sự thật đang hiện hữu ngay trước mắt nó.
Quy trình này được chia rõ rệt thành hai phần: công việc chuẩn bị ngoại tuyến (offline) và phản hồi trực tuyến (online).
Giai đoạn 1: Giai đoạn chuẩn bị (Offline)
Rất lâu trước khi bất kỳ ai nhập câu hỏi, bạn phải biến bộ sưu tập tài liệu lộn xộn của mình thành một cơ sở kiến thức có thể tìm kiếm được. Công việc nền tảng này quyết định liệu hệ thống RAG của bạn sẽ phát triển mạnh mẽ hay âm thầm thất bại.
Document loaders (các bộ tải tài liệu) là điểm khởi đầu của bạn. Các trình kết nối này lấy văn bản thô từ PDF, không gian làm việc Notion, thư mục SharePoint, trang web và wiki nội bộ. Đây là nơi thực tế bắt đầu nảy sinh vấn đề. Một bộ tải có thể trích xuất văn bản sạch từ tài liệu Word, nhưng lại gặp khó khăn với một tệp PDF đã quét (scanned PDF) vốn thực chất chỉ là một hình ảnh không có lớp văn bản nhúng. Bộ tải trả về một chuỗi rỗng, cơ sở dữ liệu của bạn không lưu trữ gì cả, và sau đó người dùng sẽ nhận được câu trả lời "Tôi không biết" mà không có cảnh báo nào. Luôn xác minh những gì bộ tải của bạn thực sự trích xuất được. Hãy kiểm tra ngẫu nhiên một vài tài liệu từ mỗi nguồn trước khi bạn tin tưởng vào quy trình (pipeline).
Tiếp theo là text splitting (chia nhỏ văn bản), hay còn gọi là chunking. Bạn không thể đưa một chính sách bảo mật dài 80 trang vào một prompt trong một khối duy nhất; bạn sẽ vượt quá giới hạn ngữ cảnh và làm nhiễu tín hiệu trong đống tạp âm. Thay vào đó, bạn cắt tài liệu thành các đoạn (chunks). Bí quyết nằm ở việc chọn kích thước phù hợp. Các đoạn quá nhỏ, như chỉ là một câu đơn lẻ, thường làm mất đi ngữ cảnh quan trọng. Một đoạn đọc là "Tất cả các yêu cầu phải được quản lý phê duyệt" sẽ quên mất rằng quy tắc này chỉ áp dụng cho việc đi công tác quốc tế. Các đoạn quá lớn, như cả một chương, sẽ làm loãng embedding và gây nhầm lẫn cho quá trình truy xuất vì chúng bao hàm mười lăm chủ đề khác nhau cùng một lúc. Trong thực tế, nhiều nhóm bắt đầu với các đoạn từ 300 đến 500 token, với độ chồng lấp (overlap) là 50 token để các câu chạy qua ranh giới giữa các đoạn không bị cắt vụn. Hãy điều chỉnh điều này dựa trên nội dung của bạn. Tài liệu API có thể chấp nhận các đoạn nhỏ hơn. Các hợp đồng pháp lý thường cần các đoạn lớn hơn để bảo toàn logic điều kiện.
Sau khi được chia nhỏ, mỗi đoạn sẽ được chuyển đổi thành một embedding. Điều này có nghĩa là chạy văn bản qua một mô hình để tạo ra một danh sách các con số, một vector, đại diện cho ý nghĩa ngữ nghĩa của đoạn văn đó. Các ý tưởng tương tự sẽ nằm gần nhau trong không gian toán học này. "chính sách đóng góp đối ứng 401k" và "quy tắc đóng góp hưu trí" sẽ nằm gần nhau hơn là "chính sách đóng góp đối ứng 401k" và "thiết lập máy in văn phòng". Các vector này được lưu trữ trong một vector database (cơ sở dữ liệu vector), chẳng hạn như Pinecone, Weaviate, hoặc một lựa chọn mã nguồn mở như Chroma. Kho lưu trữ vector không chỉ là một nơi chứa dữ liệu thô. Nó là một chỉ mục được tối ưu hóa cho việc tìm kiếm láng giềng gần nhất xấp xỉ (approximate nearest-neighbor search), cho phép bạn tìm thấy các đoạn liên quan nhất trong vài mili giây ngay cả khi có hàng triệu tài liệu.
Giai đoạn 2: Luồng trực tuyến (Online)
When a user finally asks, "What is our travel reimbursement policy for client dinners?", the live pipeline kicks in.
The