Agent không đói dữ liệu, đói ngữ cảnh

Pinecone Nexus đáng chú ý không vì thêm một lớp retrieval mới, mà vì nó ép builder nhìn lại: agent cần dữ liệu thô hay tri thức đã được nấu chín?

“Cứ nối agent vào toàn bộ data lake là xong.”

Câu này mình nghe ở nhiều team hơn mức nên nghe. Nó hợp lý thật: công ty có docs, tickets, contracts, meeting notes, wiki, file CSV nằm rải rác; agent thì cần biết việc nội bộ; vậy cứ dựng RAG, nhét hết vào vector database, rồi để model tự tìm. Như mở tủ lạnh thấy đủ nguyên liệu và kết luận bữa tối sẽ ngon.

Nhưng Pinecone Nexus vừa vào public preview làm lung lay một niềm tin khá phổ biến: vấn đề của agent enterprise không chỉ là tìm đúng tài liệu, mà là hiểu tài liệu nào còn đáng tin, liên quan ra sao, và đại diện cho “cách công ty thật sự vận hành” ở thời điểm hiện tại.

Nói thẳng ra thì, nhiều agent không thất bại vì thiếu retrieval. Chúng thất bại vì phải tự “nêm nếm” business context trong từng request.

Sơ đồ tóm tắt ý chính của bài viết.

Thứ đang diễn ra: retrieval đang bị kéo lên một tầng mới

Pinecone gọi Nexus là một knowledge engine — lớp biên dịch tri thức doanh nghiệp để agent truy vấn trực tiếp. Điểm đáng chú ý không nằm ở chữ “engine”, mà ở động tác “compile”: gom kiến thức phân tán thành một lớp có cấu trúc hơn, thay vì mỗi lần agent chạy lại đi lục từng mảnh tài liệu rồi tự ráp nghĩa.

Ở tầng thấp hơn, Pinecone cũng đẩy một hướng rất thực dụng: template biến dữ liệu trong Azure Blob Storage thành knowledge base dùng được cho AI. Template đó xử lý parsing, chunking, embedding và indexing end-to-end. Nghĩa là nếu team bạn đang có PDF, Markdown, HTML, JSON, CSV nằm trong Azure, đường từ “file nằm đó” tới “query được” ngắn hơn nhiều.

Nhưng Nexus không chỉ là “pipeline ingest tiện hơn”. Nó đặt ra một câu hỏi khó hơn cho builder:

Khi nào bạn cần search tốt hơn, và khi nào bạn cần một lớp tri thức đã được biên tập?

Đây là chỗ nhiều team dễ nhầm. Vector database giải quyết bài toán semantic search — tìm theo nghĩa, không chỉ theo keyword. RAG giải quyết bài toán đưa tài liệu liên quan vào prompt. Nhưng business context là thứ khác: quy trình nào là bản mới, team nào thực sự approve, policy nào hay bị override, mục tiêu quý này dịch ra quyết định sản phẩm ra sao.

Một nhân viên ba năm biết mấy thứ đó mà không cần search. Agent mới vào việc thì không.

Mổ xẻ: đừng nhầm “có tài liệu” với “có tri thức”

Hình dung thế này: team bạn có ba tài liệu về refund policy.

• Một file PDF từ năm ngoái.
• Một trang wiki mới hơn nhưng chưa ai cập nhật ví dụ.
• Một thread support nói cách xử lý ngoại lệ cho khách enterprise.

Nếu dùng retrieval thuần, agent có thể lấy cả ba, rồi cố suy luận. Kết quả có thể đúng, cũng có thể “nửa đúng”: trả lời theo policy cũ nhưng thêm chút ngoại lệ mới, nghe rất mượt mà mà vận hành thì toang.

Nexus đang bán một ý tưởng khác: đẩy một phần chi phí hiểu và chọn lọc ra khỏi per-query retrieval loop. retrieval loop là vòng mỗi lần user hỏi thì hệ thống lại tìm tài liệu, nhét vào context, để model suy luận. Nếu mỗi request đều phải làm món mới từ nguyên liệu sống, token tăng, latency tăng, và độ nhất quán giảm. Nếu có một phần tri thức đã được chuẩn bị trước, agent đỡ phải đoán trong lúc đang phục vụ.

Đây không phải chuyện “RAG chết rồi”. Ngược lại, nó là dấu hiệu RAG đang trưởng thành: từ “tìm đoạn văn liên quan” sang “duy trì lớp ngữ cảnh doanh nghiệp có thể truy vấn”.

Builder nên tách ba tầng ra rõ:

| Tầng | Dùng để làm gì | Khi nào đủ | Khi nào thiếu |
|---|---|---|---|
| Raw retrieval | Tìm đoạn tài liệu liên quan | FAQ, docs ít mâu thuẫn, search nội bộ đơn giản | Tài liệu trùng, cũ, nhiều ngoại lệ |
| Curated knowledge | Biên dịch tri thức thành lớp có cấu trúc | Agent cần quyết định dựa trên context công ty | Nếu tri thức thay đổi liên tục mà không có quy trình cập nhật |
| Agent runtime | Điều phối tool, approval, timeout, observability | Workflow có tool calling và nhiều bước | Nếu chỉ có search, không có kiểm soát hành vi |

tool calling là khả năng model gọi API/công cụ thay vì chỉ trả lời chữ. observability là lớp quan sát để biết agent đã làm gì, gọi tool nào, tốn bao lâu, lỗi ở đâu.

Điều đáng giữ: framework “3 câu hỏi trước khi mua lớp tri thức”

Với developer hoặc tech lead, mình sẽ không nhìn Nexus như một món đồ chơi mới để thử cho vui. Mình nhìn nó như một lời nhắc: đừng build agent enterprise bằng tâm thế chatbot có thêm search.

Trước khi chọn Nexus, tự build RAG, hay dùng template kiểu Azure-to-Pinecone, team nên trả lời ba câu:

1. Tri thức của bạn có mâu thuẫn không?

Nếu docs của bạn sạch, ít version, ít ngoại lệ, retrieval truyền thống có thể đã đủ. Dựng ingestion pipeline, chunk hợp lý, chọn embedding model ổn, thêm evaluation là đi được.

Nếu cùng một khái niệm xuất hiện ở nhiều nơi, mỗi nơi đúng một nửa, bạn cần curation. curation ở đây là quá trình chọn, chuẩn hóa, gắn quan hệ và loại bỏ nhiễu — giống nấu lửa nhỏ liu riu để nước dùng trong hơn, không phải cứ đổ thêm nguyên liệu.

2. Agent có cần quyết định hay chỉ cần trích dẫn?

Nếu user hỏi “policy này nằm ở đâu?”, search tốt là đủ.

Nếu agent phải trả lời “trường hợp này có nên refund không, cần ai approve, theo process nào?”, nó cần business context. Lúc đó, tài liệu không chỉ là bằng chứng; nó là input cho quyết định.

Ví dụ cụ thể: một agent hỗ trợ finance duyệt expense. Nó không chỉ cần biết policy “khách sạn tối đa bao nhiêu”. Nó còn cần biết ngoại lệ cho hội nghị, cấp bậc nhân sự, ngân sách phòng ban, và quy trình approve tháng này. Nếu mỗi lần đều lục docs rồi suy luận, bạn đang đặt quá nhiều áp lực lên model.

3. Chi phí đang nằm ở query hay ở chuẩn bị dữ liệu?

Pinecone nhấn mạnh việc chuyển một phần token spend khỏi từng query sang bước curation một lần. Đây là tradeoff rất đáng soi.

Nếu workload ít, dữ liệu thay đổi liên tục, user hỏi đa dạng và chưa rõ pattern, curation nặng có thể chưa đáng.

Nếu workload lặp lại, yêu cầu latency và accuracy cao, mỗi câu trả lời sai kéo theo ticket nội bộ hoặc rủi ro vận hành, đầu tư vào lớp tri thức trước có lý hơn.

Điều nên bỏ qua: cuộc đua “tool nào cũng thành agent platform”

Tuần này nhìn quanh sẽ thấy một bức tranh khá ồn: Pinecone đẩy Nexus, Vercel AI SDK 7 thêm reasoning control, tool approvals, durability, telemetry; Fireworks nói về hạ tầng training kiểu frontier lab; X mở hosted MCP server để AI tools truy cập nền tảng qua quyền user.

Các mảnh này đều quan trọng, nhưng không cùng giải một bài toán.

reasoning control trong AI SDK 7 là cách chỉnh mức suy luận của model qua API thống nhất hơn. durability là khả năng workflow sống sót qua lỗi, timeout, hoặc tác vụ dài. MCP server là cổng chuẩn để AI app kết nối tool/service. batch invariance và zero-KLD trong câu chuyện Fireworks là chuyện đảm bảo training và serving cho kết quả số học khớp nhau khi làm reinforcement learning — rất sâu, nhưng không phải team nào cũng cần chạm ngay.

Bẫy là gom tất cả vào một roadmap kiểu: “quý này làm agent platform hoàn chỉnh”. Nghe rất đã, nhưng dễ thành nồi lẩu framework.

Nếu bài toán của bạn là agent không biết context công ty, hãy ưu tiên knowledge layer.

Nếu bài toán là agent gọi tool lung tung, hãy ưu tiên approval, sandbox, timeout.

Nếu bài toán là tích hợp nguồn dữ liệu ngoài như X, GitHub, Slack, Notion, hãy soi MCP và quyền truy cập.

Nếu bài toán là post-training model chuyên biệt, lúc đó mới nói tới hạ tầng training/serving khớp số.

Đừng để release mới quyết định kiến trúc. Hãy để failure mode quyết định.

Một buổi chiều để kiểm tra team bạn đang thiếu gì

Không cần migrate gì lớn. Lấy một workflow agent đang hoặc sắp build, rồi làm bài test nhỏ này.

Bước 1: Chọn 10 câu hỏi thật
Lấy từ support ticket, Slack nội bộ, CRM note, hoặc request của ops. Tránh câu hỏi demo quá sạch.

Bước 2: Gắn nhãn câu hỏi

A. Cần tìm tài liệu
B. Cần hiểu policy hiện hành
C. Cần nối nhiều phòng ban / hệ thống
D. Cần gọi tool hoặc tạo action
E. Cần approval của người thật

Bước 3: Chạy qua hệ thống hiện tại
Ghi lại không chỉ câu trả lời đúng/sai, mà cả: tài liệu nào được retrieve, context có mâu thuẫn không, agent có cần hỏi lại không, tool nào được gọi, có log đủ để debug không.

Bước 4: Quyết định theo điểm nghẽn

• Sai vì không tìm ra đoạn liên quan → cải thiện ingestion, chunking, embedding, index.
• Sai vì tìm đúng nhưng hiểu sai version/process → cần curated knowledge layer.
• Sai vì gọi tool thiếu kiểm soát → cần runtime guardrails, approval, timeout.
• Sai mà không biết vì sao → cần telemetry trước khi thêm model mới.

Chỉ sau bài test này, bạn mới nên hỏi “dùng Nexus, tự build, hay chỉ cần template ingest?”.

Cách nghĩ mới: tri thức là sản phẩm, không phải phụ phẩm của data

Điểm mình muốn bạn mang về không phải “hãy dùng Pinecone Nexus”. Public preview vẫn là public preview; team nghiêm túc cần tự kiểm chứng với dữ liệu, quyền truy cập, latency, cost và quy trình cập nhật của mình.

Điểm đáng giữ là cách phân loại: data là nguyên liệu, retrieval là cách lấy nguyên liệu, còn business context là món đã được nấu để agent có thể dùng mà không đau bụng.

Sau bài này, nếu ai trong team nói “cứ cho agent đọc hết docs”, bạn có thể hỏi lại nhẹ nhàng: “Docs nào là sự thật vận hành hôm nay?”

Câu đó nghe ít hào nhoáng hơn launch mới, nhưng thường cứu production tốt hơn. Agent không kén ăn, nhưng cho ăn đồ sống mãi thì trước sau gì cũng đầy bụng.

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