Nâng model không cứu được agent của bạn

Agent production hay sập không phải vì model yếu. Thủ phạm thật nằm ở lớp context và orchestration — thứ nhiều team đang bỏ qua.

Câu hỏi mà team bạn đang hỏi sai

Mỗi lần agent trả kết quả lệch, phản xạ đầu tiên của hầu hết team là gì? "Chắc model chưa đủ mạnh, đợi bản mới rồi thử lại."

Mình đã thấy pattern này lặp đi lặp lại ở ít nhất bốn team Việt Nam trong năm nay: agent chạy demo ngon lành, lên staging thì loạn, rồi ai cũng nghĩ lỗi nằm ở reasoning. Thực tế, frontier model hiện tại — Claude, GPT-4o, Gemini — đều đủ sức reasoning cho phần lớn tác vụ business. Cái sập không phải ở bước model suy nghĩ, mà ở mọi thứ xảy ra trước bước đó.

Pinecone gần đây gọi tên rất chính xác: vấn đề không phải model quality, mà là context engineering — cách bạn chuẩn bị và đưa dữ liệu vào cho model trước khi nó bắt đầu suy luận. Bài teardown này mổ xẻ xem cái gì đáng giữ từ nhận định đó, và cái gì chỉ là marketing.

Agent đang sập ở đâu thật?

Khi một agent nhận task, quy trình thường diễn ra thế này: nhận yêu cầu → quyết định cần thông tin gì → tìm kiếm → đánh giá kết quả → tìm thêm → ghép mảnh → rồi mới bắt đầu trả lời. Đến lúc model thực sự suy luận, phần lớn token budget và thời gian đã cháy hết cho vòng lặp search-retrieve-evaluate.

Nói cách khác: agent của bạn không dốt, nó chỉ đang phải tự soạn giáo trình giữa giờ thi. Thay vì được phát tài liệu tóm tắt sẵn trước khi vào phòng, nó phải tự chạy khắp thư viện, lật từng cuốn sách, rồi cố tổng hợp trong khi đồng hồ đang đếm ngược.

Vấn đề này bùng ra khi bạn scale qua nhiều domain. Ví dụ cụ thể: giả sử team bạn 8 người, đang build hệ thống agent phục vụ cả bộ phận sales, legal, và support. Dữ liệu sales nằm trong CRM, legal cần đọc hợp đồng PDF, support thì dựa vào knowledge base nội bộ. Mỗi domain cần một context pipeline riêng — cách chunk, cách index, cách rank kết quả đều khác. Hand-build từng pipeline một? Pipeline đầu tiên mất hai tuần. Pipeline thứ hai mất ba tuần vì "domain này khác". Pipeline thứ ba thì team kiệt sức.

Đây chính là chỗ mà upgrading model không giúp được gì. Bạn có swap từ GPT-4o sang Claude Opus hay ngược lại, nếu context layer — lớp chuẩn bị dữ liệu trước khi model nhìn thấy — vẫn rối, kết quả vẫn flaky (lúc đúng lúc sai không theo pattern nào).

Bốn dòng trong bảng điểm production

Pinecone đặt ra bốn tiêu chí cho context layer production-ready. Mình nghĩ framework này đáng để mọi team builder dán lên tường:

1. Accuracy (độ chính xác) — Agent đúng 70% thời gian nghe có vẻ khá, nhưng trong production thì vô dụng. Khi output lúc đúng lúc sai mà không có pattern rõ ràng, user mất niềm tin nhanh hơn bạn tưởng.

2. Task latency (độ trễ mỗi tác vụ) — Budget tính bằng giây, không phải phút. Agent mất 45 giây để trả lời một câu hỏi support thì user đã tắt tab rồi.

3. Token cost (chi phí token) — Mỗi lần agent lặp vòng search-retrieve-evaluate, bill nhân lên. Không kiểm soát thì chi phí compound qua từng bước trong workflow.

4. Governance (kiểm soát nguồn gốc) — Khi agent trả lời sai, bạn phải trace được nó lấy thông tin từ đâu. Không trace được thì không sửa được, không sửa được thì không ship được.

Bốn tiêu chí này như bảng điểm cuối kỳ — thiếu một môn là rớt. Nhiều team mình biết đạt accuracy nhưng fail latency, hoặc latency ngon mà governance bằng không.

Điều đáng giữ: tư duy "compiled knowledge"

Thuật ngữ compiled knowledge (tri thức đã được biên dịch sẵn) là cách nghĩ đáng giữ nhất ở đây. Thay vì để agent tự tìm và tổng hợp dữ liệu thô mỗi lần chạy, bạn tiền xử lý dữ liệu thành dạng model dùng được ngay.

Khác biệt tương tự như phát cho sinh viên đống tài liệu gốc 500 trang, versus bản tóm tắt có cấu trúc 20 trang. Cùng một sinh viên, cùng một đề thi — nhưng kết quả khác hẳn.

Kịch bản cho team Việt Nam: giả sử bạn đang build agent đọc hợp đồng cho một công ty logistics. Thay vì mỗi query agent phải đọc lại toàn bộ PDF (tốn token, chậm, hay lẫn), bạn:

Chi phí upfront cao hơn, nhưng mỗi query sau đó nhanh hơn, rẻ hơn, và dễ trace hơn đáng kể.

Nếu bạn đang dùng stack open-source, pipeline này hoàn toàn build được với Unstructured (tiền xử lý document) kết hợp bất kỳ vector database nào — Qdrant, Weaviate, hay chính Pinecone. Điểm mấu chốt không phải tool nào, mà là có nghĩ theo hướng compiled knowledge hay không.

Điều nên lọc bỏ

Không phải mọi thứ trong narrative "context engineering giải quyết tất cả" đều đáng nghe.

Bẫy 1: Mua giải pháp trước khi hiểu bài toán. Một team fintech ở TP.HCM mà mình biết đã mua subscription một managed context platform trước khi thậm chí profile xem agent tốn token ở bước nào. Kết quả: platform chạy ngon nhưng bottleneck thật sự nằm ở prompt quá dài, không phải retrieval. Tiền mất, vấn đề vẫn còn.

Bẫy 2: Over-engineer cho tác vụ đơn giản. Nếu agent của bạn chỉ cần trả lời FAQ từ knowledge base 200 trang, bạn không cần compiled knowledge pipeline phức tạp. Một RAG pipeline cơ bản với chunking hợp lý là đủ. Đừng over-engineer cho bài toán mà brute-force vẫn chạy tốt.

Bẫy 3: Bỏ qua guardrail vì "model đủ thông minh". Context layer tốt mà không có output validation — lớp kiểm tra đầu ra trước khi trả về user — thì vẫn có thể trả kết quả nguy hiểm. Guardrail không phải optional, nó là yêu cầu cứng.

Checklist trước khi đổi model

Lần tới agent lỗi, trước khi reflex "swap model", chạy qua bốn bước này:

Nếu cả bốn điểm đều ổn mà output vẫn tệ — lúc đó mới tính chuyện đổi model. Mà thường thì đến bước hai là đã tìm ra thủ phạm rồi.

---

Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo