RAG không phải là toàn bộ công cụ: Những kỹ thuật NLP mà bài toán thực tế vẫn cần

Một yêu cầu hỗ trợ xuất hiện trong hàng đợi, và hệ thống phải xác định nội dung trước khi có thể trả lời. Phản xạ tự nhiên của kỹ sư là đưa ngay vào prompt cho LLM. Cách đó thường hiệu quả, nên nó trở thành thói quen. Nhưng đó cũng là cách chậm nhất, tốn kém nhất và khó giải thích nhất.

Có sáu phương pháp rẻ hơn nằm ngay dưới phản xạ đó: khớp chính xác (exact match) khi yêu cầu đã có mã định danh rõ ràng; sửa lỗi chính tả khi chỉ sai một ký tự; tìm kiếm từ khóa dựa trên từ vựng do chuyên gia xây dựng; và embeddings cho những cách diễn đạt mà từ vựng không bao phủ hết. Phần lớn yêu cầu được xử lý bằng một trong những cách này trong vài mili-giây, và mỗi cách đều có thể chỉ ra luật mà nó đã áp dụng.

Phân tầng phương pháp xử lý văn bản từ đơn giản đến phức tạp

Vấn đề nằm ở phản xạ "cứ dùng LLM"

Phản xạ nhảy thẳng lên bậc thang cao nhất — LLM — trong khi sáu bậc thấp hơn có thể giải quyết hầu hết các trường hợp. Kiến thức kỹ thuật thực sự nằm ở việc hiểu toàn bộ các bậc thang đó, và biết chọn bậc thấp nhất có thể giải quyết vấn đề.

Đây là triết lý xuyên suốt bộ bài viết bổ trợ (bonus series) của hai tác giả Angela Shi và Kezhan Shi trên Towards Data Science, xoay quanh các bài toán tài liệu thực tế: phân loại yêu cầu, khớp văn bản tự do với danh sách tham chiếu, đọc bảng biểu, xử lý nhiễu OCR, và chạy model trên máy cá nhân khi dữ liệu không được phép rời khỏi hệ thống.

Bốn nhóm chủ đề chính

1. Các vấn đề thực tiễn xuyên suốt pipeline

Đây là nhóm phổ biến nhất. Các bài viết này xử lý những mối quan tâm chạm vào nhiều hơn một thành phần (brick) của kiến trúc RAG.

B01: Văn bản nhiễu trong RAG — Ba nguồn gốc của vấn đề: lỗi gõ của người dùng, nhiễu khi phiên âm nhanh, và lỗi ký tự từ OCR. Bốn mươi năm nghiên cứu về sửa lỗi chính tả cổ điển (Levenshtein, BK-tree, Soundex, SymSpell) chỉ giải quyết được một trong ba. Embeddings và LLM hấp thụ phần còn lại. Giải pháp thực dụng: sửa chính tả câu hỏi dựa trên từ vựng của kho tài liệu tại thời điểm parse, để nguyên phần nội dung nhiễu, và thiết kế retrieval để thích ứng với nhiễu.

B03: Khi RAG nói "tôi không biết" — Một câu trả lời sai một cách tự tin là một lỗi. Nhưng một câu "không có câu trả lời" trống rỗng cũng tệ không kém. Mỗi thành phần trong bốn thành phần cần cung cấp cho người dùng một bằng chứng: đã parse những gì, đã tìm kiếm từ vựng nào, đã quét những trang nào, tại sao không có gì khớp. Điều này biến "tôi không biết" thành một quy trình có thể kiểm toán.

B04: Bảng biểu trong PDF — Đây là nơi hầu hết các pipeline RAG thất bại một cách âm thầm. Việc làm phẳng bảng thành văn bản tuyến tính là sai lầm phổ biến. Giải pháp đúng là bốn mức biểu diễn (row-as-line, table_df riêng biệt, columnar với kiểu dữ liệu đặt tên, columnar không đồng nhất), kèm theo chuẩn đoán trên năm trục và các phép toán idempotent để di chuyển bảng giữa các mức.

B07: Mock trung thực — Một mock đơn giản hóa kiểu trả về vì sự tiện lợi là một mock che giấu lỗi production. Nguyên tắc: mọi mock phải có đúng hình dạng của đối tượng mà nó đại diện. Nguyên tắc này cắt qua mọi thành phần có hợp đồng kiểu dữ liệu: parsing trả về DataFrame, question parsing trả về Pydantic, retrieval trả về frame có provenance, generation trả về JSON có kiểu.

2. Các hình dạng pipeline thay thế

Hai bài viết này là phản biện cho hình dạng mặc định mà series bảo vệ — kho tài liệu kế thừa có cấu trúc đối nghịch.

B02: FAQ như một RAG — Khi đội ngũ tự thiết kế kho tài liệu, mọi thứ đảo ngược. Parsing trở nên tầm thường, retrieval đóng vai trò cache, và few-shot prompting trở thành bài toán retrieval. Bài viết kết thúc bằng vòng phản hồi biến FAQ thành kho tài liệu sống, phát triển theo câu hỏi thực tế của người dùng.

B06: Kiến trúc dispatched — Hầu hết các thủ thuật tiết kiệm token kiểu agent (multi-step planner, prompt-pruning, context compression) đang giải quyết vấn đề do lựa chọn kiến trúc sai. Chọn kiến trúc trước — một bộ định tuyến xác định đưa mỗi câu hỏi đến một handler cụ thể — và hầu hết các thủ thuật trở nên không cần thiết.

3. Benchmark có thể tái lập

Đây là những bài viết sẽ "già đi" theo thời gian vì model thay đổi, nhưng phương pháp luận vẫn còn nguyên giá trị.

B05: Chọn model cho enterprise RAG — Chạy cùng một pipeline trên cùng tài liệu và câu hỏi, chỉ thay đổi LLM: OpenAI, Anthropic, Mistral tự host, Llama, Phi, Qwen. Kết luận hiếm khi là "model lớn nhất thắng"; một pipeline tốt cộng với dispatcher mạnh có thể thu hẹp khoảng cách giữa model $20/M-token và model miễn phí tự host.

B08: Bốn parser PDF trên cùng một CV — Một parser đã biến "do not redistribute" thành "document redistribution" — một lỗi nghiêm trọng. So sánh hai OCR layout-aware và hai vision LLM trên CV tổng hợp. Kết quả cho thấy nơi mỗi parser thắng, nơi mỗi parser thua, và những gì cần kiểm tra trong CV mà bất kỳ parser nào cũng có thể làm hỏng.

4. Stack LLM cục bộ

Ba bài viết tạo thành một sub-series trả lời câu hỏi lớn: "Có thể chạy toàn bộ pipeline trên một GPU tại bàn làm việc khi cloud không phải là lựa chọn?"

Chạy local LLM với Ollama trên GPU cá nhân

B10: Bước RAG duy nhất vẫn cần LLM, chạy local với Ollama — Khi cloud bị giới hạn tốc độ, nằm sau VNet, hoặc bị cấm vì dữ liệu nhạy cảm, local LLM giữ pipeline sống. qwen2.5:7b chạy tốt ở bước xác nhận cuối, nhưng qwen3:4b có lỗi lặng lẽ bỏ qua schema — một cảnh báo rằng model nhỏ hơn nhưng "thông minh hơn" không phải lúc nào cũng thay thế được.

B11: Local embeddings cho RAG — Trên dữ liệu OCR nhiễu, một model local có khả năng phân tách tốt hơn cả text-embedding-ada-002 của cloud. Cloud thắng về chất lượng văn bản sạch, local thắng về yêu cầu lưu trú dữ liệu và một dải nhiễu cụ thể.

B12: Model local nhỏ đến mức nào? — Mười một model Ollama từ 815 MB đến 9.1 GB. Tính hợp lệ cấu trúc JSON xuất hiện từ 1B. Trích xuất nguyên văn không bịa đặt bắt đầu từ 7B. Lựa chọn nhỏ nhất đủ dùng cho production: qwen2.5:7b.

Ba lộ trình đọc gợi ý

Lộ trình xử lý nhiễu: Đọc B01 (chính tả) và B04 (bảng biểu) — bao phủ hầu hết các lỗi "parser trả về thứ vô dụng" mà đội production sẽ gặp.

Lộ trình phản biện kiến trúc: Đọc B02 (FAQ như RAG) và B06 (dispatched architecture) — hai bài đảo ngược hình dạng mặc định của corpus và routing, giúp bạn đọc hiểu rõ khi nào nên chọn phía ngược lại.

Lộ trình self-hosted: Đọc B10, B11, B12 theo thứ tự — trả lời câu hỏi "có thể chạy toàn bộ cascade trên một GPU không?" với một model cụ thể cho mỗi tầng.

Tiêu chí cho một bài bonus xứng đáng

Không phải việc còn sót lại. Ba bài kiểm tra:

• Chạm nhiều thành phần nhưng không thuộc riêng thành phần nào: Nếu lập luận chạm từ hai thành phần trở lên và không thể đặt vào một thành phần duy nhất — đó là ứng viên bonus.
• Đọc độc lập được với từ vựng của series: Bonus giả định bạn đọc biết từ vựng của spine nhưng không yêu cầu đọc bài bonus khác.
• Kết luận có thể thay thế, phương pháp luận thì không: Số liệu benchmark có thể lỗi thời nhưng phương pháp vẫn còn giá trị.

Những gì series này không bao gồm

Các định dạng tài liệu khác (Word, Excel, PowerPoint, email), các mục đích khác trên tài liệu (dịch thuật, tóm tắt, so sánh), document production với tool catalog, agentic loop, và các vấn đề vận hành multi-tenant SaaS — tất cả sẽ được xử lý trong các tập sau.

Kết luận

Bài học trọng tâm: RAG không phải là toàn bộ công cụ. Kỹ thuật thực sự nằm ở việc biết khi nào dùng phương pháp cổ điển rẻ tiền và khi nào cần đến LLM. Với độc giả Việt Nam, nơi chi phí API và yêu cầu lưu trú dữ liệu là những ràng buộc thực tế, việc nắm vững "nấc thang giải pháp" này — từ khớp chính xác đến self-hosted LLM — không chỉ giúp tối ưu chi phí mà còn đảm bảo hệ thống có thể giải thích được quyết định của mình.