RAG, fine-tuning hay agentic search: tính chi phí từng lớp

Con bot hỗ trợ của bạn trả lời sai chính sách hoàn tiền, và nhóm họp hai tiếng để tranh luận nên làm RAG hay fine-tuning. Không ai trong phòng nói được chính xác lỗi đang nằm ở đâu, nên cả hai phương án đều nghe hợp lý.

Bài này đưa ra cách chọn ngược lại: bắt đầu từ triệu chứng bạn quan sát được trong trace, rồi mới chọn lớp rẻ nhất sửa được triệu chứng đó — kèm cách ước tính chi phí trước khi viết dòng code đầu tiên.

Quy tắc gốc: chọn theo lỗi, không chọn theo kiến trúc

Bài phân tích của Bigcircle nêu nguyên tắc rất gọn: "Choose between RAG and fine-tuning by the failure you can see. Use retrieval when the model is missing a fact, and fine-tuning when the facts are right and a specialist says the output reads wrong. Use agentic search, also called agentic RAG, only when no single query can find the answer."

Và lớp đứng trước tất cả là prompting, vì "Prompting comes before all three, because it costs nothing extra to try."

Câu trả lời quen thuộc "RAG cho kiến thức, fine-tuning cho hành vi" được chính tác giả đánh giá là gần đúng nhưng vỡ ngay ở hệ thống đầu tiên cần cả hai: nền tảng của họ chạy production từ 2023 với cả fine-tuned model, retrieval trên index có kiểm duyệt lẫn schema-constrained decoding trong cùng một request — vì mỗi lớp sửa một loại lỗi mà hai lớp kia không chạm tới.

Bốn lớp, bốn triệu chứng khác nhau

Lớp	Triệu chứng bạn thấy	Độ trễ tăng thêm	Gánh nặng dài hạn
Prompting	Output không nhất quán, hoặc sai theo cách bạn không mô tả nổi	Không	Không
Retrieval (RAG)	Model thiếu một dữ kiện, hoặc biết dữ kiện cũ	Một lần search trước khi gọi model	Giữ index luôn mới
Fine-tuning	Dữ kiện đúng, nhưng chuyên gia đọc thấy văn phong sai	Không, sau khi đã serve	Một model phải tự nuôi và retrain
Agentic search	Không một truy vấn đơn lẻ nào tìm ra câu trả lời	Một lần gọi model mỗi bước, bước sau chờ bước trước	Chứng minh được vòng lặp dừng vì lý do chính đáng

Đọc bảng từ trái sang phải. Một lớp bên phải không sửa được lỗi thuộc về lớp bên trái — đó là lý do thứ tự quan trọng hơn lựa chọn.

Lớp 1: vét cạn prompting trước đã

Phép thử trong bài đáng để bê nguyên vào quy trình review: đưa prompt của bạn cho một người ngoài không biết gì về sản phẩm và nhờ họ làm task đó. Nếu họ quay lại hỏi, model cũng có đúng những câu hỏi ấy — khác ở chỗ model không hỏi, nó chọn một cách hiểu, cam kết với nó, và bạn ghi nhận kết quả như một lỗi của model.

Ba việc làm trước khi đề xuất bất kỳ lớp nào tốn tiền:

• Ràng buộc output bằng cơ chế, không bằng văn mô tả. Constrained decoding loại bỏ token không hợp lệ ngay khi model đang viết, nên output luôn parse được. Còn đang parse free text bằng regex kèm retry loop thì lỗi nằm ở prompt.
• Cho xem output thay vì tả output. Đếm số ví dụ trong prompt trước khi ai đó nhắc tới fine-tune; nếu đếm ra 0, bản miễn phí của cùng ý tưởng còn chưa được thử.
• Viết điều kiện từ chối. Một câu kiểu "nếu các đoạn truy xuất được không chứa câu trả lời, hãy nói vậy và dừng lại". Thiếu nó, model lấp khoảng trống bằng thứ nghe hợp lý.

Và không có eval set thì mọi quyết định phía dưới đều mù: gom 20 đến 50 case thật có output chuẩn, chấm cùng một cách qua mọi lần chạy. Chưa có tập đó thì bạn không phân biệt được một bản sửa với một lần may mắn.

Lớp 2: RAG, và bốn lựa chọn quyết định chất lượng

Dùng retrieval khi lỗi là kiến thức thiếu hoặc cũ: dữ kiện riêng của doanh nghiệp, tài liệu viết sau knowledge cutoff, thứ thay đổi hàng tuần, thứ mà mỗi user chỉ được xem một phần.

Điểm dễ bị bỏ qua: chất lượng retrieval phụ thuộc vào chunking, embeddings, hybrid search (để mã part number và tên riêng vẫn khớp chính xác) và reranking — nhiều hơn là phụ thuộc vào model hay vector database bạn chọn. Theo bài viết, trong thử nghiệm contextual retrieval của Anthropic tháng 9/2024, tỉ lệ truy vấn mà chunk đúng không lọt top 20 giảm từ 5,7% xuống 1,9% sau khi mỗi chunk mang thêm 50–100 token ngữ cảnh, keyword search chạy song song với embeddings, và một reranker sắp xếp lại kết quả. Riêng phần ngữ cảnh thêm vào cắt 35% lỗi, thêm keyword search lên 49%, thêm reranker lên 67% — model giữ nguyên suốt quá trình.

Một chi tiết bảo mật đáng chép vào checklist: phân quyền thuộc về câu truy vấn. Filter áp sau khi retrieval đã chạy nghĩa là tài liệu đã nằm trong kết quả search, và bất cứ thứ gì phía sau ghi log, cache hay tóm tắt kết quả đó đều có thể làm rò rỉ.

Lớp 3: fine-tuning, và hóa đơn không nằm ở lần training

Fine-tune khi lỗi là hình thức, hoặc là những phán đoán mà một quy tắc viết ra không giải quyết được — và không bao giờ khi lỗi là thiếu kiến thức. Tác giả nói thẳng: fine-tuning không dạy được dữ kiện một cách đáng tin.

Phần chi phí mới là chỗ nhiều team ước tính sai. Bài viết khuyên tính tiền lần training sau cùng, vì LoRA và QLoRA đã làm nó nhỏ lại, trong khi bốn dòng còn lại thì không: dữ liệu do chuyên gia viết hoặc kiểm, evaluation chứng minh model tuned tốt hơn chứ không chỉ khác đi, tính vĩnh viễn (mỗi base model mới là một quyết định làm lại, và nhà cung cấp thì khai tử base bạn đã tune), và vận hành (hosting, pin version, rollback).

Dòng cuối có hạn chót cụ thể: theo bài viết, tính đến 22/10/2026, trang deprecations của OpenAI ghi 6/1/2027 là ngày cuối khách hàng hiện hữu còn tạo được fine-tuning job.

Cảnh báo hay nhất về synthetic data cũng ở đây: nếu bạn sinh ví dụ huấn luyện từ chính prompt của mình, thứ bạn vừa train là một bản sao đắt tiền của prompt đó.

Lớp 4: agentic search, trả bằng độ trễ

Chỉ dùng khi không một truy vấn đơn lẻ nào tìm ra câu trả lời, vì mỗi bước tìm kiếm thêm là một lần gọi model nữa mà người dùng phải chờ. Tác giả mô tả công cụ nghiên cứu khách hàng tiềm năng của chính họ chỉ bật vòng lặp search sau khi hybrid retrieval đã ngừng cải thiện, và cho biết một lần chạy đã rút 420 mục thu thập được xuống còn 6 mục thực sự trả lời câu hỏi. Đây là số liệu nhà cung cấp tự công bố về sản phẩm của họ — đọc như một tuyên bố cần kiểm chứng trên dữ liệu của bạn, không phải benchmark trung lập.

Và có một trường hợp đáng nói to: khi kho tài liệu không chứa câu trả lời thì đó không phải vấn đề kỹ thuật. Không lớp nào sửa được một tài liệu không tồn tại.

Tính tiền trước khi chọn lớp

Ba biến chi phối gần như mọi hóa đơn LLM API: input token (system prompt, tin nhắn người dùng và mọi ngữ cảnh đính kèm — lặp lại ở mỗi request), output token (tính tiền riêng, thường ở mức cao hơn input), và số request mỗi ngày nhân với lựa chọn model. Reasoning output và vòng lặp agent nhiều bước là thứ âm thầm nhân khối lượng output lên. Ghi ra thành đẳng thức kế toán thay vì một shortlist nhà cung cấp:

request_cost_units = (input_tokens * input_rate) + (output_tokens * output_rate)
monthly_units = sum(tenant.request_cost_units for tenant in usage_events)

Đây là ví dụ minh họa — thay input_rate/output_rate bằng bảng giá thực tế của nhà cung cấp bạn dùng.

Với workload hỏi đi hỏi lại (chatbot nội bộ, bot tra cứu hóa đơn, trợ lý chính sách), hóa đơn thường bị đẩy lên bởi ngữ cảnh lặp chứ không phải bởi số câu hỏi. Khuyến nghị trong bài: trả lời các câu hỏi ổn định từ một cache phạm vi theo tenant trước khi gọi model, rồi chỉ truy xuất đúng các trường cần cho lượt hiện tại; giữ prompt nhỏ và đánh version; đo input/output token theo từng tenant. Đổi sang model rẻ hơn là quyết định sau, không phải cái điều khiển đầu tiên.

Làm gì trong tuần này

Mở trace của ba lỗi gần nhất mà team đã đổ cho "model dở", và với mỗi lỗi trả lời đúng một câu: đoạn văn đúng có nằm trong context không? Có — lỗi hình thức hoặc lỗi prompt, không phải lỗi RAG. Không — sửa chunking, hybrid search và reranking trước khi ai đó nhắc tới fine-tune. Nếu tài liệu chứa câu trả lời không tồn tại trong kho, ghi vào ticket đúng như vậy.

Song song, chạy ước tính chi phí cho đường đi nhiều lưu lượng nhất trước khi nó lên production. Ước tính trước tốn vài phút; giải thích một hóa đơn bất ngờ thì tốn lâu hơn nhiều.