Lợi nhuận:
- Thiết kế các thành phần và luồng dữ liệu của trợ lý RAG doanh nghiệp đầu cuối
- Kết hợp dữ liệu đa nguồn (wiki, ticket, PDF, cơ sở dữ liệu) vào một trợ lý duy nhất
- Đưa ra quyết định kiến trúc về khả năng mở rộng, bộ nhớ đệm và độ trễ
Trong các bài học trước, chúng ta đã học từng phần một: nhúng, cơ sở dữ liệu vectơ, phân đoạn, truy xuất. Bây giờ, hãy kết hợp những điều này và xây dựng kiến trúc toàn diện của một trợ lý có khả năng giao tiếp với dữ liệu của công ty bạn. Mục đích là để nhân viên hỏi: “Chính sách nghỉ phép của chúng tôi là gì?” Một hệ thống nơi mọi người có thể đặt câu hỏi, trả lời dựa trên các tài liệu nội bộ thực tế, trích dẫn và kết hợp nhiều nguồn dữ liệu. Đơn vị này xử lý toàn bộ kiến trúc, luồng dữ liệu và các quyết định ở cấp độ sản xuất.
Thành phần đầu cuối
Trợ lý RAG của công ty bao gồm hai dòng riêng biệt. Dòng lập chỉ mục (ngoại tuyến) chuẩn bị dữ liệu; Dòng truy vấn (trực tuyến) trả lời câu hỏi.
Các thành phần dòng chỉ mục:
- Trình kết nối: Trình kết nối lấy dữ liệu từ các nguồn - wiki, hệ thống vé, kho lưu trữ tệp, cơ sở dữ liệu, email.
- Chuẩn hóa: Chuyển đổi các định dạng khác nhau (PDF, HTML, DOCX) thành văn bản rõ ràng; làm sạch đầu trang/chân trang.
- Phân chia + siêu dữ liệu: Phân chia và gắn thẻ (nguồn, ngày tháng, thẩm quyền).
- Nhúng + tải: Ghi vectơ và siêu dữ liệu vào cơ sở dữ liệu vectơ.
Các thành phần đường dẫn truy vấn:
- Tiền xử lý truy vấn: Viết lại, phân cấp.
- Truy xuất: Tìm kiếm kết hợp + bộ lọc siêu dữ liệu + xếp hạng lại.
- Tạo lời nhắc: Đặt ngữ cảnh + câu hỏi + hướng dẫn vào mẫu.
- Tạo: Câu trả lời có căn cứ (theo ngữ cảnh) từ mô hình + nguồn.
- Xử lý hậu kỳ: Định dạng trích dẫn, kiểm tra bảo mật, ghi nhật ký.
Mẹo: Tách dòng chỉ mục khỏi dòng truy vấn về mặt vật lý. Việc lập chỉ mục chậm và định kỳ (chạy theo đợt qua đêm); Dòng điều tra phải nhẹ nhàng và ngay lập tức. Việc trộn hai dòng buộc phải xử lý nặng trong khi người dùng chờ đợi.
Trực quan hóa luồng dữ liệu
[INDEXING - offline]Tài nguyên → Chuẩn hóa → Chunk+Siêu dữ liệu → Nhúng → Vector DB (wiki, ticket, PDF, DB)[QUERY - online]Câu hỏi của người dùng → Xử lý trước → Truy xuất (kết hợp+bộ lọc+xếp hạng lại) → Lời nhắc (ngữ cảnh+câu hỏi+hướng dẫn) → Mô hình → Câu trả lời+Nguồn → Người dùng
Kết hợp dữ liệu đa nguồn
Ở các công ty thực sự, câu trả lời không dừng lại ở một nơi. “Làm thế nào để hoàn lại tiền cho khách hàng?” Bạn có thể tìm thấy câu trả lời cho câu hỏi trong bài viết trợ giúp (thủ tục), trong lịch sử yêu cầu (ví dụ thực tế) và trong bản PDF chính sách (quy tắc). Trợ lý nên tìm kiếm tất cả chúng trong một nhóm.
Điểm quan trọng: khi kết hợp các tài nguyên vào một kho lưu trữ vectơ duy nhất, mỗi phân đoạn phải mang siêu dữ liệu `source_tour`. Vì vậy, bạn có thể tìm kiếm tất cả và lọc chúng nếu cần thiết, chẳng hạn như "chỉ mang theo các chính sách chính thức". Ngoài ra, các nguồn khác nhau có mức độ tin cậy khác nhau: chính sách chính thức > bài viết trợ giúp > phiếu yêu cầu của nhân viên. Bạn có thể chỉ định mức độ ưu tiên này trong việc sắp xếp lại hoặc nhắc nhở.
Nguồn
Loại nội dung
tin tưởng
Tần suất cập nhật
Chính sách PDF
quy tắc chính thức
cao
hàng tháng
Bài viết trợ giúp
Thủ tục
trung bình cao
hàng tuần
Lịch sử vé
mẫu thật
trung bình
liên tục
wiki
Ghi chú hỗn hợp/hiện tại
Biến
liên tục
Khả năng mở rộng, bộ nhớ đệm và độ trễ
Ba vấn đề nổi bật trong sản xuất. Độ trễ: Trải nghiệm sẽ kém đi khi người dùng chờ hơn 2 giây. Giải pháp: hiển thị câu trả lời ở dạng phát trực tuyến - nó được hiển thị trên màn hình khi người mẫu viết. Bộ nhớ đệm: Đối với các câu hỏi thường gặp và bối cảnh lặp đi lặp lại, bộ nhớ đệm vừa tăng tốc độ vừa giảm chi phí. Quy mô: Khi người dùng tăng lên, cần có khả năng mở rộng quy mô truy xuất và mô hình hóa các cuộc gọi theo chiều ngang.
Nguyên tắc chung về mặt chi phí: bước tốn kém nhất thường là số lượng mã thông báo chuyển sang mô hình lớn hơn. Do đó, việc giảm bối cảnh xuống còn 4 phần tốt bằng cách sắp xếp lại sẽ cải thiện cả chất lượng và chi phí. Thiết kế phổ biến là sử dụng mô hình nhỏ hơn/nhanh hơn để phân loại hoặc định tuyến đơn giản và mô hình mạnh hơn cho câu trả lời cuối cùng (ví dụ: claude-opus-4-8).
Lưu ý: Không nên lập chỉ mục theo kiểu “làm một lần, quên đi”. Tài liệu được thay đổi, xóa, thêm. Thiết lập chiến lược lập chỉ mục lại: phát hiện các tài liệu đã thay đổi và chỉ xử lý lại chúng. Chỉ mục cũ tạo ra câu trả lời có vẻ hiện hành nhưng sai.
Kiến trúc yếu / Kiến trúc mạnh
Yếu (tập lệnh đơn, mọi thứ trộn lẫn):
Khi người dùng hỏi: đọc tài liệu tại thời điểm đó, cắt nhỏ, nhúng, tìm kiếm, trả lời.# Vấn đề: tất cả việc lập chỉ mục được lặp lại cho mỗi câu hỏi; giây chậm trễ, # không tách nguồn, không bộ lọc, không làm mới.
Mạnh mẽ (tách ống + siêu dữ liệu + bộ đệm + phát trực tuyến):
Lập chỉ mục: chạy hàng loạt vào ban đêm, làm mới các tài liệu đã thay đổi. Truy vấn: dòng nhẹ — xử lý trước → truy xuất kết hợp+bộ lọc → xếp hạng lại → lời nhắc → mô hình (phát trực tuyến) → trích dẫn → nhật ký. Các câu hỏi thường gặp và nguồn được lưu trữ.
Ba hộp nhỏ
Trường hợp 1 - Đường truyền lộn xộn, độ trễ nặng. Một công ty khởi nghiệp đã viết một tập lệnh xử lý lại các tệp PDF với mỗi câu hỏi; Mỗi câu trả lời mất trung bình 11 giây. Khi dòng lập chỉ mục được tách ra và dữ liệu trước đó được chuyển đến kho lưu trữ vectơ, thời gian truy vấn giảm xuống còn 1,3 giây và khi phát trực tuyến, "từ đầu tiên" xuất hiện sau 400 mili giây.
Trường hợp 2 - Quá nhiều tài nguyên, sai mức độ ưu tiên. Một trợ lý hỗ trợ coi trọng bản PDF chính sách và các phiếu yêu cầu cũ; Mô hình đôi khi đưa ra đánh giá không chính xác của nhân viên từ hai năm trước làm quy tắc chính thức. Khi siêu dữ liệu source_tour và hướng dẫn "xem xét chính sách chính thức trong trường hợp xung đột" được thêm vào lời nhắc, các lỗi ưu tiên sai đã giảm 89%.
Trường hợp 3 - Chỉ số cũ. Một trợ lý nhân sự đang làm việc với một chỉ số không được cập nhật trong 3 tháng; Chính sách nghỉ phép đã thay đổi, nhưng trợ lý vẫn nói ngày xưa. Khi cài đặt tính năng làm mới hàng ngày để phát hiện các tệp đã thay đổi, tỷ lệ phản hồi hiện tại đã tăng từ 70% lên 99%.
Những lỗi thường gặp
- Trộn các dòng truy vấn và lập chỉ mục: Quá trình xử lý nặng được thực hiện trong khi người dùng chờ đợi; sự chậm trễ bùng nổ.
- Không đưa loại nguồn vào siêu dữ liệu: Không ưu tiên và lọc; Nguồn không đáng tin cậy có vẻ là chính thức.
- Không thiết lập chiến lược làm mới: Chỉ số trở nên cũ kỹ; Những câu trả lời sai xuất hiện hiện tại được tạo ra.
- Bỏ qua phát trực tiếp: Người dùng nhìn vào màn hình trống; Độ trễ nhận thấy trở nên cao.
- Sử dụng mô hình lớn nhất ở mỗi bước: Chi phí tăng không cần thiết; Để lại tay lái cho mô hình nhỏ hơn.
Tóm lại
- Trợ lý RAG của công ty bao gồm hai dòng riêng biệt: lập chỉ mục ngoại tuyến và truy vấn trực tuyến; tách biệt chúng về mặt vật lý.
- Lập chỉ mục = trình kết nối + chuẩn hóa + đoạn/siêu dữ liệu + nhúng/tải lên; truy vấn = tiền xử lý + truy xuất + nhắc + tạo + hậu xử lý.
- Dữ liệu nhiều nguồn được kết hợp vào một kho lưu trữ duy nhất nhưng siêu dữ liệu source_type và mức độ ưu tiên tin cậy vẫn được giữ nguyên.
- Truyền trực tuyến và bộ nhớ đệm để xử lý độ trễ, điều chỉnh ngữ cảnh và lựa chọn mô hình phù hợp với chi phí là rất quan trọng.
- Nếu không lập chỉ mục lại, chỉ mục sẽ trở nên cũ kỹ; Xử lý lại các tài liệu thay đổi thường xuyên.
Nhiệm vụ ứng dụng
Vẽ sơ đồ kiến trúc của một trợ lý cho nhóm của bạn. (1) Xác định ít nhất ba nguồn dữ liệu thực và ghi lại nhu cầu về trình kết nối, tần suất cập nhật và mức độ tin cậy cho từng nguồn. (2) Vẽ các dòng chỉ mục và truy vấn riêng biệt bằng sơ đồ mũi tên hộp. (3) “Tôi có thể giảm độ trễ và chi phí ở đâu trong trợ lý này?” Viết ít nhất hai quyết định cụ thể cho câu hỏi. (4) Mô tả chiến lược làm mới của bạn bằng một câu: tài nguyên nào sẽ được lập chỉ mục lại và tần suất như thế nào?
danh sách kiểm tra
- [ ] Tôi có thể vẽ các dòng chỉ mục và truy vấn một cách riêng biệt và với các thành phần chính xác.
- [ ] Tôi có thể kết hợp dữ liệu đa nguồn với source_type và mức độ ưu tiên tin cậy.
- [ ] Tôi có thể đưa ra quyết định phát trực tuyến/bộ nhớ đệm về độ trễ và lựa chọn mô hình theo chi phí.
- [ ] Tôi biết tại sao chiến lược lập chỉ mục lại là cần thiết.
- [ ] Tôi nhớ rằng bước tốn kém nhất trong kiến trúc của tôi thường là mã thông báo chuyển sang mô hình lớn hơn.