Web search cho agent: đừng tô màu lên prod

Web search cho agent: đừng tô màu lên prod

Agent biết lướt web không tự nhiên đáng tin hơn. Cái đáng bàn là cách team đo freshness, kiểm nguồn, chặn rủi ro và biết khi nào nên dừng.

Có một kiểu demo rất dễ làm cả phòng họp sáng mắt: hỏi agent về một release vừa ra, nó trả lời vanh vách, kèm link, giọng tự tin như vừa bước ra khỏi phòng họp sản phẩm. Tech lead gật gù. PM mở backlog. Một bạn backend lặng lẽ nhắn riêng: “Rồi nếu nó trích nhầm blog rác thì ai chịu?”

Đấy mới là câu hỏi đáng tiền.

Web Search trên Amazon Bedrock AgentCore vừa được giới thiệu ở trạng thái generally available, tương thích MCP — Model Context Protocol, tức chuẩn để agent khám phá và gọi tool theo cách thống nhất. Về mặt sản phẩm, đây là một mảnh ghép tiện: agent có thể gọi web search qua AgentCore Gateway, không phải tự lo search API, key, quota, parsing kết quả lộn xộn.

Nhưng nếu bạn đang build hệ thống AI thật, điểm cần đổi cách nghĩ là: web search không phải lớp “thêm kiến thức” cho agent; nó là một dependency production cần đo, giới hạn và có tiêu chí dừng. Đừng tô thêm lớp màu lên một bản phác thảo chưa có khung.

Sơ đồ minh họa cho bài Web search cho agent: đừng tô màu lên prod

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

Chuyện đang diễn ra: model mới không chữa được kiến thức cũ

Mấy tuần gần đây, release về AI có một nhịp khá rõ: model mạnh hơn, tool gần code hơn, inference bớt vòng thừa, monitoring chi tiết hơn. Cohere có Command A+ nhấn vào reasoning, multimodal, multilingual và agentic workload. GitHub Copilot CLI được kéo gần hơn tới language server — thành phần hiểu cấu trúc code thật, không chỉ đoán bằng text. SageMaker Async Inference hỗ trợ inline payload cho request nhỏ, bớt phải vòng qua S3. SageMaker cũng thêm detailed metrics và dashboard để debug inference.

Tất cả đều chỉ về một hướng: khả năng của model không còn là toàn bộ câu chuyện.

Agent gặp một giới hạn rất cũ: kiến thức của model bị “đóng băng” ở thời điểm training. Nếu bạn hỏi giá cổ phiếu hôm nay, kết quả bóng đá tối qua, hay changelog vừa ship, model nền tự thân không biết. Web search giải quyết phần freshness — độ mới của thông tin.

Web Search trên Bedrock AgentCore đưa phần đó vào dạng managed connector hoặc managed target qua AgentCore Gateway. Agent có thể discover tool bằng tools/list và invoke như các MCP tools khác. Phía sau là web index do Amazon vận hành, được mô tả là có quy mô hàng chục tỷ tài liệu và được refresh liên tục, có thể phản ánh nội dung mới trong vài phút. Query traffic ở trong AWS, và truy xuất có thể kết hợp knowledge graph với semantic snippet extraction — trích đoạn ngữ nghĩa phù hợp cho context model.

Nghe ổn. Nhưng ổn để demo khác với ổn để cho khách hàng bấm nút.

Mổ lớp đầu: search tốt không đồng nghĩa answer đúng

Nói thẳng ra thì, web search chỉ giúp agent tìm được vật liệu mới hơn, không đảm bảo agent dùng vật liệu đó đúng cách.

Ví dụ cụ thể: team bạn làm một agent hỗ trợ sales nội bộ. Người dùng hỏi: “Tính năng X của đối thủ đã hỗ trợ region Việt Nam chưa?” Agent gọi web search, thấy một trang forum, một trang docs cũ, một bài blog mới. Nếu không có rule kiểm nguồn, nó có thể lấy forum làm chính, rồi trả lời chắc nịch. Lúc đó lỗi không nằm ở model “kém thông minh”, mà ở pipeline không biết phân biệt nét cọ chính với vệt màu phụ.

Với builder, nên tách web search thành 4 lớp quyết định:

| Lớp | Câu hỏi cần chốt | Nếu bỏ qua sẽ hỏng ở đâu |
|---|---|---|
| Freshness | Thông tin cần mới tới mức nào? phút, giờ, ngày? | Search quá thường xuyên, tốn chi phí và nhiễu |
| Authority | Nguồn nào được tin hơn? docs chính thức, blog vendor, báo, forum? | Agent trích nguồn yếu như nguồn mạnh |
| Extraction | Lấy snippet nào đưa vào context? | Context window đầy nhưng thiếu ý quan trọng |
| Audit | Có log query, link, timestamp, output không? | Không debug được khi người dùng phản ánh sai |

Context window là vùng ngữ cảnh model còn giữ trong một lượt xử lý. Khi bạn nhét quá nhiều kết quả web vào đó, model không tự nhiên khôn hơn; đôi khi nó chỉ bị loãng tín hiệu.

Đây là lý do web search cần guardrail ngay từ đầu: allowlist domain, blacklist domain, giới hạn số kết quả, bắt buộc citation, và policy khi kết quả mâu thuẫn.

Mổ lớp hai: managed connector giảm việc, không xóa trách nhiệm vận hành

Điểm đáng giữ của Bedrock AgentCore Web Search là nó cắt bớt một đống việc ít ai muốn làm: mua search API riêng, quản lý credential outbound, xử lý quota, normalize format trả về, viết glue code parsing kết quả. Với team đã ở AWS và đang dùng AgentCore Gateway, connector MCP-compatible là cách đi gọn.

Nhưng “managed” không có nghĩa là bạn khỏi vận hành.

Bạn vẫn phải trả lời các câu hỏi rất đời:

Ở đây, bài về SageMaker detailed metrics là một tín hiệu cùng hướng: production AI cần nhìn được P99 latency, GPU memory pressure, KV cache, traffic lệch AZ, autoscaling chưa kịp kích hoạt. KV cache là bộ nhớ tạm của attention khi model sinh token, ảnh hưởng trực tiếp tới latency và throughput. Với agent có tool search, bạn cũng cần metric tương tự ở tầng orchestration: thời gian gọi search, số lần retry, số kết quả dùng thật, tỷ lệ answer có citation, tỷ lệ người dùng bấm “không đúng”.

Nếu không đo, bạn chỉ đang treo tranh lên tường rồi hy vọng khách không soi gần.

Một buổi thử nhỏ: đừng roll out cho toàn bộ agent

Hình dung thế này: bạn là tech lead của team 6 người, đã có agent nội bộ trả lời câu hỏi về sản phẩm. Bạn muốn thêm web search để cập nhật release mới từ vendor. Đừng bật cho mọi câu hỏi. Làm một thử nghiệm hẹp trong một buổi chiều.

1. Chọn một use case có nhu cầu freshness thật

Đừng chọn “hỏi gì cũng search”. Chọn một luồng rõ:

Nếu câu hỏi có thể trả lời từ knowledge base nội bộ đã kiểm duyệt, ưu tiên RAG nội bộ. RAG là retrieval-augmented generation, tức lấy tài liệu liên quan rồi đưa cho model trả lời. Web search chỉ nên vào khi freshness hoặc coverage bên ngoài quan trọng.

2. Viết policy trước prompt

Đừng bắt prompt gánh hết. Tạo policy nhỏ, kiểu:

web_search_policy:
  allowed_domains:
    - docs.vendor.com
    - aws.amazon.com
    - github.blog
  max_results: 5
  require_citation: true
  conflict_behavior: "state_uncertainty"
  no_result_behavior: "ask_for_manual_check"
  sensitive_query_redaction: true

Đây không phải cấu hình chính thức của dịch vụ nào; chỉ là ví dụ minh họa để team chốt rule trước khi nối tool.

3. Đo bằng bộ câu hỏi cố định

Tạo 20-30 câu hỏi đại diện, gồm cả câu dễ, câu mới, câu có nguồn mâu thuẫn, câu không nên search. Với mỗi câu, lưu:

Đừng cần benchmark to tát. Cái bạn cần là biết agent đang vẽ đúng đường viền hay đang tô lem ra ngoài.

4. Đặt tiêu chí dừng ngay từ đầu

Một thử nghiệm tốt phải biết khi nào ngưng. Ví dụ minh họa:

Các ngưỡng cụ thể tùy sản phẩm. Nhưng phải có ngưỡng. Không có tiêu chí dừng thì pilot sẽ biến thành production bằng đường vòng.

Điều đáng giữ: freshness có chọn lọc

Web Search trên AgentCore đáng chú ý nhất ở chỗ nó đưa freshness vào agent theo chuẩn tool, thay vì mỗi team tự vá một mớ API và parser. Nếu bạn đang trong AWS, muốn query traffic nằm trong AWS, và đã đi theo AgentCore Gateway, đây là lựa chọn đáng thử.

Nhưng giá trị thật không phải “agent có Internet”. Giá trị là agent biết khi nào cần hỏi web, hỏi ở đâu, và trả lời với bằng chứng nào.

Mình sẽ giữ 3 nguyên tắc này:

  1. Search là tool có quyền hạn, không phải reflex mặc định.
  2. Citation là dữ liệu vận hành, không chỉ trang trí UI.
  3. Freshness phải trả giá bằng latency, nhiễu và rủi ro nguồn.

Điểm này cũng giải thích vì sao các release khác liên quan. Inline payload cho SageMaker Async Inference cho thấy một cải tiến nhỏ ở đường đi request có thể giảm bớt operational surface area. Copilot CLI với language servers nhắc mình rằng context có cấu trúc thường đáng giá hơn context nhiều chữ. Command A+ hay model mạnh hơn vẫn cần dữ liệu đúng lúc, đúng nguồn.

Điều nên bỏ qua: FOMO “agent nào cũng cần web”

Không phải agent nào cũng nên có web search.

Nếu agent xử lý dữ liệu nội bộ, tài liệu pháp lý đã kiểm duyệt, workflow tài chính cần audit chặt, hoặc câu trả lời phải bám policy công ty, web search có thể làm hệ thống khó kiểm soát hơn. Trong các case đó, RAG nội bộ, curated knowledge base, hoặc manual approval có thể hợp lý hơn.

Cũng đừng dùng web search để che prompt yếu. Nếu agent không biết phân loại intent, không biết gọi tool đúng lúc, không có schema output rõ ràng, thêm search chỉ làm lỗi có vẻ “cập nhật” hơn.

Sau bài này, điều mình muốn bạn nghĩ khác là: đừng hỏi “agent có web search chưa?”, hãy hỏi “web search có được vận hành như một dependency chưa?”

Nếu câu trả lời là chưa, khoan tô thêm màu. Cứ dựng khung, thử nét nhỏ, soi dưới đèn trước đã. Tranh treo prod mà lem màu thì khách không gọi đó là nghệ thuật đâu.

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

Nguồn tham khảo