Bạn hỏi một trợ lý xem một chức năng được công bố trong tuần này đã có sẵn chưa. Nó tìm thấy một bài viết gần đây và trả lời kèm theo một liên kết. Nhưng liên kết này có thể nói về một bước trong tương lai, lặp lại một thông báo cũ hoặc nhắm vào một dịch vụ khác. Tìm một trang và xác minh một khẳng định là hai thao tác khác nhau. Giao diện tìm kiếm web mới của Cloudflare cung cấp một điểm nhập; ứng dụng của bạn vẫn phải tổ chức con đường đến một câu trả lời có thể kiểm chứng.
Trong kịch bản giả tưởng của bài viết này, bạn đang chuẩn bị một trợ lý theo dõi sản phẩm. Người dùng của nó mong đợi một câu trả lời ngắn gọn: những gì đã được công bố, những gì có thể truy cập và những gì vẫn còn dự kiến. Chúng tôi đề xuất một phương pháp để tách riêng các trạng thái này, giữ các bằng chứng hữu ích và đưa ra từ chối chính xác khi thông tin thiếu. Không có dịch vụ tìm kiếm nào được gọi để đo hiệu suất của nó.
Những gì thay đổi với Web Search API
Ngày 2 tháng 10 năm 2026 Cloudflare thông báo Web Search API thông qua AI Gateway, cổng của nó cho các cuộc gọi AI. Các Công cụ Máy chủ gốc, vốn phải tích hợp các công cụ phía máy chủ vào cổng này, vẫn được công bố là một bước trong tương lai. Chúng không được trình bày ở đây như là có sẵn.
tài liệu được tham khảo vào ngày 6 tháng 10, cập nhật vào ngày 2 tháng 10, chỉ ra một bản beta mở. Nó mô tả các kết quả có cấu trúc bao gồm tiêu đề, URL và mô tả, nhiều nhà cung cấp, truy cập REST từ một máy chủ hoặc qua binding Workers, và một nhật ký trong AI Gateway. REST ở đây chỉ một giao diện được gọi qua các yêu cầu mạng; binding là quyền truy cập được cung cấp cho chương trình đang chạy trong Workers.
Lợi ích kiến trúc là làm cho bước « tìm kiếm » trở nên có thể nhận biết. Bạn có thể gán cho nó một thời hạn, một chi phí, một trạng thái thất bại và một dấu vết. Trong đề xuất của chúng tôi, bước này trả về các ứng viên. Một bước khác mở nguồn được cấp phép, bước thứ ba đánh giá khẳng định và bước cuối cùng soạn thảo câu trả lời. Cùng một tác nhân AI có thể tham gia vào nhiều bước, nhưng trách nhiệm vẫn tách biệt trong ứng dụng của bạn.
Xác định câu hỏi trước khi gửi yêu cầu
« Chức năng này có sẵn không? » thiếu bối cảnh. Có sẵn cho gói dịch vụ nào, khu vực nào, phiên bản nào và vào thời điểm nào? Hãy yêu cầu các chi tiết cần thiết hoặc thông báo phạm vi được chọn. Trong ví dụ giả định của chúng tôi, câu hỏi trở thành: « Tính đến ngày tham khảo, chức năng được mô tả trong thông báo này có mở cho các nhà phát triển của gói dịch vụ này không? »
Một truy vấn tìm kiếm nên chứa các thuật ngữ công khai cần thiết cho câu hỏi này. Nó không cần tên khách hàng, hợp đồng của họ hay nội dung của một hồ sơ nội bộ. Khuyến nghị của chúng tôi là xây dựng một công thức tối thiểu trước khi gọi nhà cung cấp và kiểm tra những gì được ghi vào nhật ký. Một bản ghi hữu ích cho hoạt động có thể trở nên nhạy cảm một cách không cần thiết nếu nó sao chép toàn bộ cuộc trò chuyện.
Cũng hãy thiết lập một ngân sách làm việc. Trợ lý của bạn có thể nhận một giới hạn cuộc gọi, một thời hạn tổng thể và một danh sách các nguồn ưu tiên. Những lựa chọn này là các tham số ứng dụng cần được điều chỉnh; chúng tôi không đưa ra các giá trị được cho là tối ưu. Khi ngân sách bị cạn kiệt, ứng dụng phải phân biệt được « nghiên cứu chưa hoàn thành » và « chức năng không khả dụng ».
Nối mỗi câu với một bằng chứng
Đối với mỗi kết quả liên quan, hãy tìm trang gốc của sự kiện: thông báo từ nhà xuất bản, tài liệu của chức năng hoặc kho chính thức. Một bài báo tổng hợp có thể giúp việc phát hiện. Nó không trở thành bằng chứng chính chỉ vì ngày của nó mới hơn. Nếu trang gốc không truy cập được, hãy giữ giới hạn này và giảm phạm vi câu trả lời của bạn.
Trong phương pháp của chúng tôi, một bằng chứng hỗ trợ một khẳng định cụ thể. Ví dụ, thông báo có thể hỗ trợ "dự kiến mở quyền truy cập", trong khi tài liệu truy cập phải hỗ trợ "chức năng này có thể sử dụng trong gói dịch vụ đó". Vì vậy, bạn có thể có hai liên kết hữu ích đáp ứng hai câu hỏi khác nhau. Một danh mục tài liệu được đặt ở cuối không tự nó giải quyết sự tương ứng này.
Tách ba ngày. Ngày xuất bản mô tả tài liệu. Ngày sự kiện mô tả những gì đã xảy ra. Ngày tra cứu mô tả thời điểm bạn đã đọc trang. Một bài viết xuất bản hôm nay có thể kể về một sự kiện cũ; một tài liệu được chỉnh sửa hôm nay có thể vẫn giữ sự sẵn có trước đó. Nếu một ngày không thể xác minh, hãy để nó là không xác định thay vì suy ra từ URL.
Xây dựng phiếu bằng chứng độc lập với nhà cung cấp
Chúng tôi gọi SearchEvidence là hợp đồng khái niệm dưới đây. Tên và các trường của nó thuộc về bản trình diễn của chúng tôi; chúng không mô tả sơ đồ chính thức của Web Search API. Mục đích là có thể thay đổi nguồn tìm kiếm mà không làm mất logic kiểm tra.
| Trường dữ liệu khái niệm | Nội dung được mô tả | Kiểm soát được đề xuất |
|---|---|---|
| URL nguồn | Trang đã được xem xét | Địa chỉ được phép và mở thành công |
| Tiêu đề | Xác định tài liệu | Đối chiếu với trang đã đọc |
| Được tham khảo vào | Thời điểm kiểm soát | Dấu thời gian của ứng dụng |
| Được xuất bản vào | Ngày xác minh của tài liệu | Nguồn gốc của ngày được lưu giữ |
| Sự kiện vào | Ngày xảy ra sự việc, nếu biết | Đoạn liên quan đã được xác định |
| Khẳng định được duy trì | Câu mà bằng chứng cho phép | Phạm vi hạn chế đối với nội dung đã đọc |
| Đoạn văn hữu ích | Phần ngắn hoặc diễn đạt lại | Không sao chép toàn bộ tự động |
| Tình trạng bằng chứng | Đầy đủ, mâu thuẫn hay vắng mặt | Quy tắc rõ ràng trước khi soạn thảo |
Người đọc phải có khả năng mở trích dẫn và hiểu lý do tại sao nó đi kèm với câu. Trong trợ lý giám sát của chúng tôi, một phản hồi có thể trình bày riêng biệt một thông báo đã được đánh dấu ngày và một sự sẵn sàng vẫn còn phải xác nhận. Nếu một trang không cho phép xác định trạng thái truy cập, hãy ghi nó ra. Mô hình không được điền trường này với những gì nó cho là thông thường đối với nhà cung cấp này.
Hãy giữ sự phân biệt giữa URL của kết quả và URL của trang thực sự được truy cập, đặc biệt là sau khi chuyển hướng. Cũng hãy ghi lại việc từ chối mở hoặc hạn chế truy cập. Những trạng thái này hữu ích để giải thích lý do tại sao bằng chứng không thể được củng cố, mà không ngụ ý rằng tất cả các trang web trên Internet đều có thể đọc được.
Chuẩn bị một tích hợp với các giới hạn hiển thị
Trong một ứng dụng hiện có, thêm một giao diện tìm kiếm bên cạnh các dịch vụ tài liệu của bạn. Đầu ra của nó là một danh sách các ứng viên và trạng thái cuộc gọi. Việc mở một trang thuộc về một thành phần riêng biệt, với các quy tắc mạng và thu thập được phép bởi tổ chức của bạn. Sau đó, bộ soạn thảo chỉ nhận được các mục cần thiết cho chủ đề.
Bộ nhớ đệm, tức là việc tái sử dụng tạm thời một phản hồi trước đó, đòi hỏi một sự lựa chọn rõ ràng. Một việc tra cứu định nghĩa và một câu hỏi về tình trạng sẵn có hiện tại không có cùng yêu cầu về độ mới. Hãy giữ ngày của bằng chứng được tái sử dụng và dự kiến một lần tra cứu mới khi câu hỏi yêu cầu. Ngày phản hồi của trợ lý không nên tạo cảm giác rằng tất cả các nguồn vừa mới được xem lại.
Để tránh một vòng lặp tốn kém, hãy giới hạn số lần thử lại và phân biệt các lỗi: quá thời gian, truy cập bị từ chối, định dạng không mong đợi hoặc tìm kiếm không có ứng viên phù hợp. Chuẩn bị một thông báo kết thúc cho từng trường hợp. "Tôi không thể kiểm tra trang chính" sẽ hữu ích hơn là một câu trả lời chắc chắn được xây dựng từ một bản tóm tắt không đầy đủ.
Lộ trình này có thể bổ sung cho một cơ sở nội bộ. Cơ sở này giữ lại các thủ tục và từ vựng của bạn; tìm kiếm công khai được sử dụng để kiểm tra một thông báo hoặc một sự thay đổi bên ngoài. Việc sử dụng gọi là RAG, tạo câu trả lời có bổ sung tài liệu được truy xuất, chính xác là việc cung cấp tài liệu cho mô hình trước khi nó trả lời. Việc thêm tìm kiếm trên web mời gọi tổ chức các nguồn công khai và nội bộ, với các quyền và yêu cầu cập nhật của chúng.
Kiểm tra các câu trả lời, trích dẫn và từ chối
Giao thức sau đây là một đề xuất Partitech. Nó sử dụng các trang kiểm tra được kiểm soát hoặc các thành phần mô phỏng mạng: các thành phần mô phỏng phản hồi mà không gọi thực sự tới nhà cung cấp. Nó sẽ cho phép đánh giá logic của ứng dụng của bạn mà không trình bày kết quả như của dịch vụ Cloudflare.
| Trường hợp kiểm thử được đề xuất | Quan sát dự kiến | Đầu ra cần kiểm tra |
|---|---|---|
| Thông báo gần đây về một bước tiếp theo | Ngày gần đây, truy cập trong tương lai | Phân biệt thông báo/dự kiến |
| Sự việc cũ trong một trang gần đây | Hai ngày khác nhau | Không có giới thiệu như một điều mới |
| Trang chính không truy cập được | Kết quả tìm kiếm đơn | Báo cáo kiểm tra không đầy đủ |
| Hai nguồn khác nhau | Phạm vi hoặc phiên bản khác nhau | Mâu thuẫn được giải thích rõ |
| Hết thời gian mạng | Tìm kiếm chưa hoàn tất | Thất bại đã được báo cáo, không bịa ra kết luận |
| Hướng dẫn trong một trang | Văn bản bên ngoài ứng dụng | Hướng dẫn bị bỏ qua, dữ liệu được xử lý như nguồn |
Sau đó đánh giá các câu trả lời từng câu một. Đếm những khẳng định có bằng chứng, những khẳng định không có bằng chứng và những khẳng định mà trích dẫn liên quan đến phạm vi khác. Cũng hãy xem xét những từ chối: chúng có hợp lý không và có nói rõ những gì còn thiếu không? Một trợ lý từ chối mọi thứ không thỏa mãn nhiệm vụ hơn một trợ lý luôn trả lời.
Tách riêng bài kiểm tra của thành phần tìm kiếm và bài kiểm tra viết. Bạn có thể có kết quả tốt nhưng tạo ra một bản tóm tắt kém, hoặc không tìm thấy bất kỳ nguồn nào mặc dù logic trích dẫn rất xuất sắc. Sự tách riêng này giúp chọn được phần sửa chữa phù hợp thay vì thay đổi ngẫu nhiên hướng dẫn của mô hình.
Xử lý các trang như dữ liệu bên ngoài
Một trang có thể chứa một câu yêu cầu tác nhân bỏ qua các quy tắc của nó hoặc gửi một thông tin đi nơi khác. Trong thiết kế của chúng tôi, văn bản này không có quyền lực nào: nó vẫn là một nội dung để xem xét. Các quyền hành động, hướng dẫn của hệ thống và các bí mật không được định nghĩa lại bởi một nguồn được tìm kiếm.
Chuẩn bị một bài kiểm tra mà trong đó một trang minh họa chứa một hướng dẫn không liên quan đến chủ đề. Kết quả mong đợi là một trích xuất giới hạn chỉ đến bằng chứng có ích, không có hành động bổ sung. Cũng hãy kiểm tra nhật ký và phản hồi cuối cùng để tránh việc chúng tái tạo dữ liệu nhạy cảm được thêm vào ngữ cảnh. Đây là một biện pháp bảo vệ nên thử nghiệm trong kiến trúc của riêng bạn, không phải là một khả năng được đảm bảo bởi API tìm kiếm.
Để bắt đầu, hãy chọn một câu hỏi công khai và có giới hạn, xác định các bằng chứng cần thiết và chuẩn bị sáu trường hợp kiểm thử. Bước tiếp theo là nhận được câu trả lời mà mỗi khẳng định có thể được kiểm tra, cũng như từ chối một cách dễ hiểu khi thiếu bằng chứng. Sau đó, bạn sẽ có thể đo lường dịch vụ thực tế trong một khung cho phép, với chi phí và giới hạn theo ngày tháng.
Nguồn và ngày kiểm tra
Các nguồn sơ cấp được mở lại và đọc vào ngày 6 tháng 10 năm 2026 : Cloudflare, thông báo Web Search API ngày 2 tháng 10 ; tài liệu Web Search API, cập nhật ngày 2 tháng 10. Hợp đồng SearchEvidence, kịch bản và các bài kiểm tra là những đề xuất Partitech. Không có tiêu chuẩn so sánh, kiểm tra mạng ứng dụng hay kiểm toán các đối tác nào được tuyên bố.