Phương pháp đo lường tìm kiếm AI

Tóm tắt — Một kết quả tìm kiếm AI là một mẫu quan sát, không phải thứ hạng. Hãy lưu chính xác câu hỏi, nơi câu hỏi được đặt, model hoặc sản phẩm đã trả lời, thời điểm chạy và các liên kết xuất hiện. Lặp lại cùng một phép thử nhiều lần. Loại các lượt lỗi khỏi mẫu số, đồng thời không coi lượt bot truy cập, lượt nhắc thương hiệu, trích dẫn, lượt nhấp và chuyển đổi là cùng một sự kiện.

Bản ghi quan trọng hơn điểm số

“AI visibility score” (bản dịch) «điểm mức hiển thị AI» rất khó diễn giải nếu bạn không biết nội dung nào đã được kiểm thử. Cùng một prompt có thể tạo ra câu trả lời khác nhau theo ngày, model, quốc gia, tài khoản hoặc giữa các lượt chạy lặp lại. Vì vậy, một bản ghi hữu ích phải bắt đầu từ từng quan sát:

• prompt chính xác và phiên bản của prompt;
• sản phẩm, API hoặc giao diện báo cáo chính thức;
• model được yêu cầu và model thực tế được dùng, nếu biết;
• trạng thái retrieval web: bật, tắt hoặc không khả dụng;
• quốc gia, locale, thiết bị và trạng thái tài khoản khi có liên quan;
• ngày, nhóm mẫu và số thứ tự lượt lặp;
• câu trả lời hoặc hash bằng chứng được phép lưu;
• mọi lượt nhắc và trích dẫn quan sát được;
• đoạn văn có vẻ hỗ trợ từng trích dẫn, nếu được hiển thị;
• phiên bản phương pháp và bộ trích xuất.

Nếu một lượt chạy bị lỗi, bị từ chối hoặc không hiển thị dữ liệu được yêu cầu, hãy giữ lại bản ghi đó. Gắn nhãn chưa được đánh giá thay vì đổi kết quả thành 0.

Năm sự kiện phải được tách riêng

1. Được lấy: crawler đã xác minh hoặc tác nhân do người dùng chỉ định đã yêu cầu một URL.
2. Được truy xuất hoặc lựa chọn: trang xuất hiện trong tập retrieval có thể quan sát.
3. Được nhắc đến: câu trả lời nêu tên thực thể.
4. Được trích dẫn: câu trả lời hiển thị URL nguồn.
5. Được truy cập hoặc tạo chuyển đổi: một người theo liên kết và hoàn thành hành động được đo lường.

Nhật ký máy chủ có thể chứng minh sự kiện đầu tiên khi danh tính bên gửi yêu cầu được xác minh đúng cách. Thông thường, nhật ký không thể chứng minh bốn sự kiện còn lại. Bản chụp câu trả lời có thể chứng minh lượt nhắc hoặc trích dẫn hiển thị, nhưng không thể cho biết mọi nguồn mà hệ thống đã truy xuất hoặc sử dụng nội bộ.

Lặp lại phép thử trước khi đề xuất thay đổi

Chạy các prompt tương thích ít nhất ba lần trước khi gắn nhãn độ ổn định; năm lần là mặc định tốt hơn. Trình bày kết quả dưới dạng phân số chính xác, chẳng hạn 3/5 câu trả lời đủ điều kiện đã trích dẫn trang, thay vì chỉ ghi “60% visible.” (bản dịch) «hiển thị trong 60% lượt.»

Khi một trích dẫn xuất hiện một lần rồi biến mất hai lần, cách diễn giải ban đầu đúng là kết quả có biến động. Điều đó không tự động đồng nghĩa với vấn đề lập chỉ mục hoặc hình phạt.

Hãy thử Phòng thí nghiệm bằng chứng tìm kiếm AI với gói ví dụ đi kèm để xem cách tách riêng mẫu số đủ điều kiện, độ bền của trích dẫn, mức bao phủ đoạn văn và xung đột dữ kiện.

Tóm tắt — Hãy dùng hợp đồng quan sát chỉ cho phép ghi nối tiếp và một sổ đăng ký prompt có phiên bản. Chỉ so sánh các nhóm tương thích về prompt, giao diện, retrieval, locale và phương pháp. Báo cáo kết quả nhị phân cùng N và khoảng bất định. Lưu bằng chứng thô tách biệt với bộ phân loại suy ra và các chỉnh sửa của con người. Khung quản trị rủi ro AI của NIST cung cấp một khung quản trị bổ trợ cho việc lưu hồ sơ này. Khi có thể, hãy đánh giá biện pháp can thiệp bằng nhóm đối chứng, nhưng vẫn chỉ xem kết quả quan sát có kiểm soát là bằng chứng định hướng.

Cấu trúc của một quan sát

Quan sát chuẩn phải gồm bốn lớp:

Thu thập

Ghi rõ loại nguồn:

• sản phẩm dành cho người dùng;
• API model chính chủ;
• API chính chủ có tìm kiếm web;
• nhà cung cấp bên thứ ba;
• báo cáo quản trị website chính thức;
• nhật ký máy chủ đã xác minh;
• nội dung người dùng tải lên.

Một lệnh gọi API chính chủ có tìm kiếm là bằng chứng hữu ích về chính lần thực thi API đó. Nó không trực tiếp đo lường một sản phẩm dành cho người dùng có tên tương tự. Hãy giữ ranh giới này trong dữ liệu lưu trữ, nhãn giao diện, bản xuất và số liệu tổng hợp.

Bối cảnh thử nghiệm

Lưu ID prompt ổn định, phiên bản prompt bất biến, hash prompt, giao diện, chế độ retrieval, locale, quốc gia, thiết bị, trạng thái tài khoản, nhóm mẫu và số thứ tự mẫu. Dùng một nhóm chuẩn cố định để theo dõi xu hướng và một nhóm thăm dò riêng để phát hiện mẫu prompt mới.

Khi prompt thay đổi, hãy tạo phiên bản mới. Không sửa các quan sát lịch sử để khiến chúng trông có vẻ tương thích.

Bằng chứng

Giữ bằng chứng câu trả lời thô hoặc đã băm, các URL được trích dẫn và truy xuất đã chuẩn hóa, vị trí lượt nhắc, vị trí trích dẫn nếu được hiển thị, truy vấn grounding nếu được hiển thị, cùng đoạn hỗ trợ hoặc hash đoạn văn. Chuẩn hóa tham số theo dõi và fragment URL nhưng không loại bỏ URL gốc.

Đối với trích dẫn, một bản ghi nguồn hữu ích gồm:

raw URL → normalized URL → observed canonical or redirect successor
        → answer citation position → supporting passage → observed HTTP status

Chuỗi nguồn gốc này ngăn chuyển hướng, tham số, bản sao phân phối lại và quá trình di chuyển làm tăng sai số lượng nguồn. Hướng dẫn chuẩn hóa URL của Google mô tả các tín hiệu hợp nhất URL liên quan và giới hạn của chúng.

Diễn giải

Mỗi lượt nhắc, sắc thái, thực thể, dữ kiện và lý do thất thoát được trích xuất phải kèm:

• phiên bản bộ phân loại hoặc bộ trích xuất;
• trạng thái quan sát được, suy ra, phỏng đoán hoặc chưa được đánh giá;
• mức tin cậy và lý do;
• mọi chỉnh sửa sau đó của con người.

Một chỉnh sửa không xóa phân loại ban đầu. Nó trở thành mẫu hiệu chuẩn để đánh giá phiên bản bộ phân loại tiếp theo.

Các phép so sánh tương thích

Trước khi tính xu hướng, hãy yêu cầu các giá trị tương thích cho:

• ID và phiên bản prompt;
• giao diện;
• chế độ retrieval;
• locale;
• phiên bản phương pháp và bộ trích xuất.

Hãy chú thích hoặc ngắt chuỗi khi model hoặc checkpoint thực tế thay đổi. Nếu không, một bản cập nhật của nhà cung cấp có thể bị hiểu nhầm là thay đổi hiệu suất nội dung.

Đối với kết quả nhị phân, hãy báo cáo tử số, mẫu số đủ điều kiện, ước lượng điểm và khoảng bất định. Loại các lượt từ chối, lỗi nhà cung cấp và bằng chứng không khả dụng khỏi mẫu số, nhưng vẫn hiển thị số lượng của chúng trong phần chất lượng lượt chạy.

Ví dụ từ các nền tảng công khai

Các ví dụ này cho thấy vì sao cần hợp đồng riêng cho từng nguồn; chúng không nhằm ép các nền tảng vào một hệ thống xếp hạng chung:

• Mô tả công khai của Google về báo cáo AI tạo sinh trong Search Console liệt kê lượt hiển thị, trang, quốc gia, thiết bị và ngày. Hãy lưu chúng dưới dạng các trường mức hiển thị đã được ghi nhận; không chuyển đổi chúng thành trích dẫn hoặc thứ hạng câu trả lời. Báo cáo được công bố dưới dạng triển khai giới hạn vào tháng 6/2026. Thông báo chính thức
• Mô tả công khai của Microsoft về AI Performance trong Bing Webmaster Tools gồm hoạt động trích dẫn, trang được trích dẫn và mẫu truy vấn grounding. Microsoft nói rõ rằng các trích dẫn này không biểu thị vị trí, thẩm quyền, thứ hạng hay vai trò của một trang trong câu trả lời. Thông báo chính thức

Bộ chuyển đổi cho từng nguồn phải giữ nguyên ngữ nghĩa đó và đánh dấu các trường không được ghi nhận là không khả dụng.

Thử nghiệm thay đổi nội dung

Tạo bản ghi can thiệp trước khi đánh giá một chỉnh sửa:

• giả thuyết;
• URL chịu tác động và URL đối chứng;
• ID prompt;
• thời điểm triển khai;
• thời điểm tái crawl quan sát được;
• chỉ số kỳ vọng;
• khoảng thời gian trước và sau.

Kết quả trước/sau không có đối chứng chỉ mang tính định hướng. Một nhóm đối chứng tương thích cho phép xem xét theo phương pháp sai biệt kép, nhưng kết quả vẫn là quan sát trừ khi cách phân nhóm và điều kiện bên ngoài đủ cơ sở cho ngôn ngữ nhân quả mạnh hơn.

Yêu cầu phát hiện duy trì qua nhiều lượt chạy lặp lại trước khi chuyển nó thành đề xuất nội dung. Đề xuất phải liên kết ngược tới các quan sát đã tạo ra nó.

Theo dõi dữ kiện và mâu thuẫn

Duy trì sổ dữ kiện do con người đánh giá, gồm thực thể, thuộc tính, giá trị kỳ vọng, biến thể chấp nhận được, nguồn sơ cấp, ngày hiệu lực, độ nhạy và lần xác minh gần nhất của con người. So sánh các tuyên bố quan sát được trong câu trả lời với sổ này.

Khi các model không đồng thuận, hãy báo cáo đã quan sát thấy xung đột. Không tuyên bố bên nào đúng cho đến khi các giá trị được kiểm tra với bằng chứng hiện hành. Dữ kiện về giá, pháp lý, y tế, tài chính và bảo mật cần khoảng xác minh ngắn hơn cùng cổng đánh giá chặt hơn.

Bằng chứng về crawler

Cách kiểm soát crawler khác nhau theo mục đích yêu cầu. OpenAI, Anthropic và Perplexity ghi nhận các vai trò riêng cho phát triển model, tìm kiếm/lập chỉ mục hoặc hoạt động lấy dữ liệu do người dùng chỉ định. Hãy xác minh danh tính bằng danh sách IP do đơn vị vận hành công bố, DNS ngược theo tài liệu hoặc cơ chế chính thức khác nếu có; chỉ chuỗi user-agent không đủ chứng minh danh tính.

• Tài liệu crawler của OpenAI
• Tài liệu crawler của Anthropic
• Tài liệu crawler của Perplexity

Ngay cả một yêu cầu đã xác minh cũng chỉ chứng minh chính yêu cầu đó. Không nâng nó thành bằng chứng về việc được dùng trong câu trả lời, được trích dẫn, nhận traffic hoặc tạo chuyển đổi. Tài liệu bot của OpenAI, hướng dẫn crawler của Anthropic và tài liệu crawler của Perplexity mô tả ranh giới truy cập và danh tính riêng của từng nhà cung cấp.

Các cách làm sai

• Một điểm số chung che giấu bất đồng giữa các giao diện.
• Một lượt chạy prompt duy nhất được gắn nhãn share of voice.
• Coi bằng chứng không khả dụng là 0.
• So sánh kết quả API với sản phẩm dành cho người dùng như thể chúng giống hệt nhau.
• Gọi trích dẫn là “thứ hạng”.
• Gọi một trích dẫn trả về 404 là ảo giác trước khi kiểm tra chuyển hướng và di chuyển.
• Viết lại prompt, quan sát hoặc chỉnh sửa lịch sử.
• Áp dụng hồi tố thay đổi bộ phân loại mà không giữ phiên bản của nó.
• Tuyên bố một chỉnh sửa nội dung gây ra mức tăng khi chưa có thử nghiệm phù hợp.
• Khuyến nghị llms.txt, markup AI đặc biệt hoặc các chunk rất nhỏ như yêu cầu chung của Google. Hướng dẫn hiện hành của Google nói rằng các yếu tố này không bắt buộc đối với tính năng Search tạo sinh. Hướng dẫn chính thức

Nhật ký thay đổi