Công cụ Tìm kiếm Web của Agent: Đo lường Chất lượng Quyết định Nghiên cứu

Tóm tắt nhanh:

• Chất lượng tìm kiếm và chất lượng câu trả lời cần được đo lường riêng biệt. Các kết quả phù hợp vẫn có thể dẫn đến một khuyến nghị không được chứng cứ hỗ trợ.
• Mỗi chỉ số cần có một tập đối tượng đủ điều kiện được khai báo rõ. Loại trừ các tác vụ chưa được giải quyết có thể làm cho tác tử trông tốt hơn mà không cải thiện việc nghiên cứu của nó.
• Việc hỗ trợ cho một khẳng định đòi hỏi mối quan hệ giữa văn bản và bằng chứng. Số lượng URL không thể xác định liệu các khẳng định nội dung của câu trả lời có được biện minh hay không.
• Kết quả tìm kiếm có cấu trúc, không cần trích xuất HTML hỗ trợ việc khám phá có thể kiểm tra được. Hãy lưu giữ ngữ cảnh của chúng cùng với các bản ghi đọc và quyết định của ứng dụng của bạn.

---

Giới thiệu: Một kết quả phù hợp vẫn có thể dẫn đến câu trả lời sai

Một công cụ tìm kiếm web cho tác tử tham gia vào một chuỗi các quyết định. Tác tử diễn giải câu hỏi, chọn truy vấn, chọn ứng viên, đọc tài liệu nguồn và quyết định sẽ nói gì. Một điểm chất lượng coi chuỗi này là một sự kiện duy nhất không thể giải thích câu trả lời đã sai ở đâu.

Sự phân biệt này quan trọng trong quá trình mua sắm. Một nhà cung cấp có thể cung cấp một nguồn công khai phù hợp trong khi ứng dụng lại đọc một phần đã lỗi thời. Một quy trình làm việc khác có thể chọn một nguồn yếu dù đã nhận được các ứng viên mạnh. Cả hai đều có thể tạo ra câu trả lời kém, nhưng thay thế dịch vụ tìm kiếm chỉ giải quyết được một số nguyên nhân có thể xảy ra.

Scrapeless Google Search API cung cấp các kết quả có cấu trúc cho giai đoạn khám phá. Để đánh giá thành phần đó một cách công bằng, hãy kết nối đầu ra của nó với một thiết kế đo lường rõ ràng cho toàn bộ tác vụ. Bài viết này đề xuất một từ điển chỉ số, quy trình rà soát và phương pháp so sánh cho các ứng dụng nghiên cứu. Bài viết không đưa ra điểm số đã đo, mẫu phản hồi hoặc kết quả benchmark.

Xác định đơn vị trước khi xác định điểm số

Một phép đo nghiên cứu cần một đơn vị phân tích có thể nhận diện được. Hãy tách riêng tác vụ người dùng, thao tác tìm kiếm, kết quả ứng viên, tài liệu đã thu thập và khẳng định trong câu trả lời trong bản ghi của bạn.

Một tác vụ có thể bao gồm nhiều thao tác tìm kiếm. Một nguồn có thể xuất hiện ở các vị trí kết quả khác nhau hoặc được phát hiện bởi các truy vấn khác nhau. Câu trả lời cuối cùng có thể chứa các khẳng định được hỗ trợ bởi cùng một tài liệu. Gộp các đơn vị này lại có thể làm tăng ảo tưởng về độ bao phủ hoặc che khuất công việc lặp lại.

Đối với một trợ lý chính sách sản phẩm giả định, tác vụ là yêu cầu của người dùng về một sản phẩm cụ thể và khu vực áp dụng. Các thao tác tìm kiếm là những lần cố gắng định vị tài liệu liên quan. Tài liệu chính sách thu thập được là bằng chứng. Câu nêu rõ tính đủ điều kiện là một khẳng định. Mỗi đơn vị trả lời một câu hỏi đánh giá khác nhau.

Việc tách biệt này cũng giúp phân biệt kiến thức đã được mô hình học với tài liệu được truy xuất, một phân biệt được thiết lập trong nghiên cứu về sinh kết hợp truy xuất (retrieval-augmented generation). Một câu trả lời đúng không phải là bằng chứng cho việc công cụ đã cung cấp bằng chứng. Việc đánh giá của bạn nên xem xét liệu khẳng định có được hỗ trợ bởi tài liệu thực sự có sẵn cho quy trình làm việc hay không.

Viết một từ điển chỉ số với mẫu số rõ ràng

Một từ điển chỉ số nên nêu rõ cái gì được tính, trường hợp nào đủ điều kiện và cách xử lý các quan sát thiếu. Hãy bắt đầu với các định nghĩa bằng lời mà người đánh giá có thể áp dụng nhất quán trước khi thêm các phép tính vào bảng điều khiển.

Định nghĩa mức độ liên quan của ứng viên là tỷ lệ các ứng viên đã được rà soát được đánh giá là hữu ích cho nhu cầu thông tin của tác vụ. Mẫu số của nó là tập ứng viên đã được rà soát theo chính sách lấy mẫu, không phải mọi trang trên web. Định nghĩa mức độ hoàn tất thu thập là tỷ lệ tài liệu đã chọn mà phần văn bản cần thiết trở nên khả dụng thông qua kênh thu thập được cho phép. Không chỉ số nào trong số này là điểm chấp nhận câu trả lời.

Định nghĩa mức độ bao phủ khẳng định được hỗ trợ là tỷ lệ các khẳng định sự kiện quan trọng mà người đánh giá có thể liên kết với bằng chứng đầy đủ. Hãy giải thích điều gì khiến một khẳng định là quan trọng. Một câu dẫn nhập vô hại không nên làm loãng tác động của một khẳng định không được hỗ trợ nhưng lại quyết định khuyến nghị.

Các khái niệm chất lượng trong Data Quality Vocabulary cung cấp nền tảng hữu ích để phân biệt một đánh giá với một nhãn chất lượng mang tính phổ quát. Từ điển chỉ số của bạn nên nêu tên tác vụ và quy tắc đánh giá. Một điểm số không có ngữ cảnh đó có thể trông chính xác nhưng vẫn khó diễn giải.

Giữ nguyên sự khác biệt giữa vắng mặt và không quan sát được

Một quan sát không khả dụng không được phép bị âm thầm chuyển thành một kết quả tìm kiếm âm tính. Hãy ghi nhận liệu quy trình làm việc đã tìm kiếm hay chưa, liệu phản hồi có sử dụng được hay không và liệu nội dung nguồn liên quan đã được thu thập hay chưa.
Giả sử một trợ lý giả định được hỏi về một điều kiện bảo hành công khai. Giai đoạn tìm kiếm trả về các ứng viên, nhưng đoạn chính sách cần thiết không khả dụng thông qua kênh đã được phê duyệt. Nhiệm vụ đó không thiết lập rằng điều kiện đó không tồn tại. Nó thiết lập một giới hạn trong bằng chứng sẵn có cho ứng dụng.

Hãy sử dụng các kết quả nhiệm vụ khác nhau cho công việc được chấp nhận, được hỗ trợ một phần, chưa được giải quyết, bị từ chối và bị hủy. Đây là các danh mục đề xuất cho ứng dụng, không phải các trường được nhà cung cấp tìm kiếm đảm bảo. Giữ lại lý do đằng sau mỗi danh mục để người đánh giá có thể phân biệt giữa bằng chứng không đủ với một hạn chế về chính sách hoặc một việc hủy do người dùng.

Kịch bản gắn kết tìm kiếm cho sản phẩm AI hữu ích khi quyết định những quan sát này thuộc về đâu. Khám phá có cấu trúc có thể khiến giai đoạn tìm kiếm trở nên có thể kiểm tra, trong khi ứng dụng của bạn phải duy trì các trạng thái bằng chứng ở giai đoạn sau. Đừng gán lỗi chất lượng ở cấp công cụ chỉ vì một giai đoạn thu thập tài liệu không thể hoàn thành công việc riêng của nó.

Đánh giá Mức độ Hỗ trợ ở Cấp Yêu Cầu (Claim)

Việc rà soát yêu cầu (claim) nên đặt câu hỏi liệu tài liệu được trích dẫn có biện minh cho khẳng định cụ thể được đưa ra hay không. Việc trùng chủ đề hoặc đề cập đến cùng một công ty là không đủ.

Với ví dụ về bảo hành, một nguồn có thể chứng minh rằng bảo hành tồn tại mà không chứng minh rằng nó áp dụng tại quốc gia được yêu cầu. Một yêu cầu về điều kiện đủ điều kiện theo vùng cần đoạn văn phù hợp. Một nguồn về một phiên bản sản phẩm khác có thể là bối cảnh liên quan trong khi vẫn không vượt qua được kiểm tra hỗ trợ thực tế.

Ghi lại phán quyết về mức độ hỗ trợ cùng với tham chiếu đoạn văn và bất kỳ điều kiện bổ sung nào. Các phân biệt hữu ích bao gồm hỗ trợ trực tiếp, hỗ trợ kèm điều kiện đã nêu, mâu thuẫn và tài liệu không đủ. Tránh ép toàn bộ bằng chứng vào một nhãn nhị phân đúng–sai khi chính yêu cầu đó cần được thu hẹp.

Ý tưởng về nguồn gốc cho thông tin dẫn xuất giúp tổ chức mối quan hệ này. Giữ lại đoạn văn nào đã được thu thập mà yêu cầu phụ thuộc vào và phép biến đổi nào đã tạo ra câu trả lời. Khi đó một trích dẫn có thể được xem xét như một quan hệ bằng chứng thay vì được tính như một yếu tố trang trí trong phản hồi.

Bắt đầu Scraping với Scrapeless

Tăng sức mạnh cho quy trình tự động hóa và web scraping của bạn với Scrapeless!
Đăng ký hôm nay để nhận $5 tín dụng miễn phí — không cần thẻ tín dụng.

Nhận tín dụng miễn phí ngay trong Bảng điều khiển Scrapeless.

Đo lường Tính Độc Lập của Nguồn mà Không Đếm Các Bản Sao (Mirror)

Sự chứng thực độc lập yêu cầu các nguồn gốc bằng chứng khác nhau, chứ không chỉ là các URL khác nhau. Một thông báo được sao chép, một bài báo phát hành đồng thời và một bản tóm tắt trích dẫn bài báo đó đều có thể phụ thuộc vào cùng một phát biểu gốc.

Với các nhiệm vụ yêu cầu sự chứng thực, hãy yêu cầu người đánh giá ghi lại nguồn gốc rõ ràng của từng yêu cầu nội dung. Chính sách của nhà xuất bản và một thử nghiệm độc lập có thể cung cấp các loại bằng chứng khác nhau. Nhiều trang tái tạo lại chính sách vẫn hữu ích cho việc khám phá nhưng không nhất thiết thiết lập được sự xác nhận độc lập.

Nhận diện tài nguyên cũng cần được chú ý. Cú pháp tổng quát của định danh tài nguyên cung cấp cơ sở để phân tích URL, nhưng chính sách khử trùng lặp của bạn phải giữ lại các phân biệt có ý nghĩa như phiên bản tài liệu và phạm vi pháp lý áp dụng. Loại bỏ mọi thành phần truy vấn một cách bừa bãi có thể gộp chung những bằng chứng lẽ ra cần phải được tách riêng.

Giữ lại địa chỉ được phát hiện ban đầu cùng với khóa định danh đã chọn. Khi một người đánh giá đặt câu hỏi về một lần gộp, bản ghi đó cho phép nhóm kiểm tra những gì thực sự đã xuất hiện. Mục đích không phải là tối đa hóa số lượng nguồn duy nhất; mà là hiểu liệu câu trả lời có dựa trên bằng chứng đủ phù hợp hay không.

Tách Thời Gian Công Cụ Khỏi Thời Gian Để Có Câu Trả Lời Được Chấp Nhận

Thời gian để có một câu trả lời được chấp nhận bao gồm các giai đoạn mà người dùng thực sự phụ thuộc vào. Thời lượng tìm kiếm đơn lẻ nên được giữ là một thước đo thành phần, với các sự kiện bắt đầu và kết thúc được định nghĩa rõ ràng.

Ghi lại thời điểm ứng dụng chấp nhận nhiệm vụ, bắt đầu một thao tác tìm kiếm, nhận được các ứng viên có thể sử dụng, thu thập tài liệu cần thiết và đưa ra quyết định cuối cùng. Với một quy trình làm việc có liên quan phê duyệt của con người, hãy phân biệt thời gian xử lý tự động với thời gian chờ trong hàng đợi rà soát. Người dùng có thể quan tâm đến cả hai, nhưng chúng chẩn đoán các ràng buộc khác nhau.
Ghi lại đồng bộ các mốc thời gian và bảo toàn ngữ nghĩa sự kiện cùng với biểu diễn dấu thời gian. Một thời điểm hoàn thành không có sự kiện bắt đầu được xác định có thể pha trộn thời gian xếp hàng, thời gian người dùng tạm dừng và thời gian thực thi. So sánh con số đó giữa các bản phát hành sẽ không tách biệt được một cải tiến trong tìm kiếm.

Đối với một công cụ tìm kiếm web cho agent, cũng cần quan sát tần suất việc tìm kiếm nhiều hơn làm thay đổi trạng thái bằng chứng của câu trả lời. Các thao tác bổ sung có thể tạo ra tài liệu hữu ích, hoặc chúng có thể chỉ quay lại các ứng viên quen thuộc. Đây là một câu hỏi về hiệu quả ở cấp độ ứng dụng. Hãy coi đó là một so sánh quan sát cần điều tra, thay vì giả định rằng nhiều thao tác hơn luôn thể hiện nghiên cứu sâu hơn.

Đưa Các Nhiệm Vụ Chưa Giải Quyết Vào So Sánh Giữa Các Bản Phát Hành

Một phép so sánh giữa các bản phát hành cần bảo toàn khối lượng công việc dự định, bao gồm cả những trường hợp không đạt được câu trả lời được chấp nhận. Nếu không, một hệ thống có thể cải thiện điểm số hiển thị của mình bằng cách rút khỏi các câu hỏi khó.

Hãy dùng một bộ đánh giá cố định để so sánh một thay đổi đề xuất với ứng dụng hiện tại, rồi kiểm tra phân bố kết quả. Nếu số câu trả lời được hỗ trợ tăng lên đồng thời số nhiệm vụ chưa giải quyết cũng tăng, hãy xem xét nhóm người dùng hoặc họ câu hỏi nào đã dịch chuyển. Một giá trị trung bình đơn lẻ có thể che giấu việc một cải tiến mang lại lợi ích cho một trường hợp sử dụng trong khi gây hại cho trường hợp khác.

Giữ riêng các họ câu hỏi mới được đưa vào cho đến khi tiêu chuẩn đánh giá của chúng được thiết lập. Việc thêm một hạng mục khám phá dễ có thể nâng tỷ lệ chấp nhận tổng thể mà không cải thiện các câu hỏi chính sách khó mà sản phẩm đã hứa sẽ trả lời. Tương tự, thêm một quy tắc đánh giá nghiêm ngặt hơn có thể làm giảm điểm số trong khi lại khiến ứng dụng trung thực hơn.

Hãy quy định cách xử lý các nhiệm vụ bị người dùng ngắt quãng hoặc bị chặn bởi chính sách. Chúng nên vẫn hiển thị, nhưng mẫu số đúng còn tùy thuộc vào câu hỏi đang được đo lường. Một chỉ số thu nhận (acquisition metric) và một chỉ số người dùng-hoàn thành (user-completion metric) có thể chính đáng sử dụng các tập đối tượng khác nhau nếu định nghĩa của chúng giải thích được lý do.

Sử Dụng Bất Đồng Trong Đánh Giá Để Cải Thiện Tiêu Chí

Bất đồng giữa các đánh giá viên là bằng chứng cho thấy quy tắc đo lường cần được chú ý. Hãy bảo toàn các bất đồng về khả năng áp dụng của nguồn, phạm vi yêu cầu và tính trọng yếu thay vì vội vàng lấy trung bình để xóa đi.

Hãy yêu cầu các đánh giá viên giải thích đoạn nội dung hoặc điều kiện nhiệm vụ đứng sau một bất đồng. Nếu một người coi một điều kiện theo vùng miền là cốt yếu còn người khác bỏ qua nó, nhóm sản phẩm cần quyết định người dùng đã được hứa hẹn điều gì. Giải pháp có thể là một quy tắc chấp nhận rõ ràng hơn chứ không phải là một nhà cung cấp tìm kiếm khác.

Xây dựng một thư viện ví dụ đã được phân xử nhỏ từ tài liệu được cho phép. Mỗi ví dụ nên thể hiện câu hỏi, đoạn nguồn liên quan, yêu cầu được đề xuất và lý do cho phán quyết. Giữ trọng tâm vào những phân biệt đã từng gây nhầm lẫn. Khi đó các đánh giá viên có một tài liệu tham chiếu thực tế khi các nhiệm vụ lạ xuất hiện.

Quy trình này cũng tạo ra các câu hỏi mua sắm (procurement) tốt hơn. Nhóm của bạn có thể hỏi liệu một dịch vụ có cung cấp đủ ngữ cảnh để xem xét mức độ liên quan của ứng viên và lựa chọn nguồn hay không. Mức giá Scrapeless hiện tại có thể được đánh giá dựa trên yêu cầu vận hành đó, với công việc thu nhận và đánh giá được lập ngân sách riêng. Tránh việc biến một kết quả thuận lợi về mức độ liên quan của ứng viên thành một đảm bảo không được đo lường về độ chính xác của câu trả lời cuối cùng.

Xây Dựng Bảng Điều Khiển Gắn Với Một Người Chịu Trách Nhiệm

Một bảng điều khiển nghiên cứu hữu ích kết nối mỗi lỗi với một giai đoạn và một nhóm chịu trách nhiệm. Mỗi thước đo được hiển thị nên gợi ra một cuộc điều tra thay vì chỉ đơn thuần thưởng cho một con số lớn hơn.

Mức độ liên quan của ứng viên thấp cho thấy vấn đề ở khâu hình thành truy vấn, ngữ cảnh thu thập hoặc độ phù hợp của cơ chế khám phá. Ứng viên phù hợp nhưng lựa chọn nguồn yếu cho thấy vấn đề ở chính sách ứng dụng. Văn bản nguồn mạnh nhưng tuyên bố không được hỗ trợ cho thấy vấn đề ở suy luận hoặc khâu rà soát câu trả lời. Hàng đợi đánh giá ngày càng phình to cho thấy vấn đề về năng lực hoặc lời hứa về nhiệm vụ quá rộng.

Tổng quan giải pháp Tìm kiếm Google kết nối việc thu thập tìm kiếm lặp lại với các quyết định kinh doanh. Hãy áp dụng cùng kỷ luật đó nội bộ: quyết định hành động nào mỗi chỉ số nghiên cứu có thể cho phép. Một bảng điều khiển không nên tự động thay đổi các tuyên bố công khai, mở rộng quyền tìm kiếm hoặc tuyên bố một nguồn là đáng tin cậy nếu không có một quy trình ra quyết định được xác định rõ.
Đối với việc lập kế hoạch kiến trúc, tìm kiếm các tác nhân được sử dụng bởi các ứng dụng AI có thể giúp phân biệt giai đoạn khám phá với các bề mặt thu thập khác. Giữ cho các giai đoạn đó có thể nhận diện được trong đo lường ngay cả khi chúng dùng chung một nhà cung cấp hoặc xuất hiện trong cùng một giao diện tác nhân. Người đánh giá của bạn cần biết họ đang đánh giá phần nào của hệ thống.

Kết luận: Đo lường Những Quyết Định Mà Công Cụ Cho Phép

Một công cụ tìm kiếm web cho tác nhân nên được đánh giá thông qua một chuỗi rõ ràng từ nhiệm vụ đến các phương án, bằng chứng thu thập được và các khẳng định được hỗ trợ. Xác định đơn vị đo, bảo vệ mẫu chuẩn (denominator) và giữ lại các trường hợp chưa được giải quyết vốn cho thấy giới hạn của ứng dụng.

Scrapeless cung cấp cho các nhóm một bề mặt khám phá có cấu trúc mà họ có thể đánh giá trong chuỗi đó. Bước hữu ích tiếp theo là viết từ điển chỉ số cho một họ nhiệm vụ hẹp, phân xử các ví dụ mơ hồ và sử dụng các định nghĩa thu được trong quá trình mua sắm hoặc đánh giá phát hành. Điểm số khi đó mô tả một cam kết vận hành mà nhóm của bạn hiểu rõ.

Sẵn Sàng Lên Kế Hoạch Ứng Dụng Nghiên Cứu Tìm Kiếm Của Bạn?

Chia sẻ các câu hỏi thực tiễn với nhà phát triển trên Discord và Telegram.

Khám phá Scrapeless cho quy trình nghiên cứu của bạn với một họ câu hỏi được xác định rõ và một chuẩn bằng chứng mà nhóm của bạn có thể đánh giá.

Câu hỏi thường gặp

Hỏi: Chỉ số tốt nhất cho một công cụ tìm kiếm web của tác nhân là gì?

Một công cụ tìm kiếm web của tác nhân cần nhiều thước đo cụ thể theo từng giai đoạn hơn là một điểm số phổ quát. Độ liên quan của ứng viên đánh giá giai đoạn khám phá, trong khi mức độ bao phủ của các khẳng định được hỗ trợ và kết quả nhiệm vụ được chấp nhận đánh giá các trách nhiệm ứng dụng ở giai đoạn sau.

Hỏi: Một trích dẫn có chứng minh rằng câu trả lời được hỗ trợ không?

Một trích dẫn chỉ hỗ trợ câu trả lời khi tài liệu nguồn của nó chứng minh được khẳng định liên quan trong phạm vi được yêu cầu. Đếm số liên kết không thể thiết lập được mối quan hệ đó.

Hỏi: Các nhiệm vụ chưa được giải quyết có nên được tính là thất bại không?

Các nhiệm vụ chưa được giải quyết nên được giữ hiển thị cùng với lý do của chúng và được tính vào theo dân số đủ điều kiện được nêu trong chỉ số. Chúng có thể phản ánh bằng chứng không đủ, giới hạn thu thập hoặc ranh giới chính sách hơn là một lỗi trong độ liên quan của tìm kiếm.

Hỏi: Các URL khác nhau có thể được tính là nguồn độc lập không?

Các URL khác nhau có thể đại diện cho cùng một bằng chứng cơ bản. Hãy xem xét nguồn gốc và mối quan hệ nội dung trước khi coi chúng là sự chứng thực độc lập.

Hỏi: Một nhóm có thể so sánh các bản phát hành ứng dụng một cách công bằng như thế nào?

Một nhóm nên so sánh các bản phát hành trên một tập nhiệm vụ ổn định với cùng quy tắc đánh giá, cùng hạng mục kết quả và cùng ranh giới hạch toán. Xem xét các thay đổi theo họ nhiệm vụ trước khi diễn giải một giá trị trung bình tổng thể.