Hướng dẫn

Ý kiến thứ hai về điểm số của một công cụ khác

Điểm eval của bạn đã tăng. Điều đó có thật không? Và bạn có thể tin giám khảo đã đo nó không? Nếu bạn đã đánh giá bằng một công cụ khác, hãy xuất các kết quả theo từng trường hợp của nó trước và sau một thay đổi, và Oloproof trả lời cả hai câu hỏi trên các kết quả đó mà không chạy lại bất cứ thứ gì.

Những gì nó đọc

Một tệp cho mỗi phiên bản hệ thống, CSV hoặc JSON Lines, với một hàng cho mỗi trường hợp và tiêu chí:

Cột	Nội dung
case_id	Id của trường hợp. Hai tệp chỉ ghép cặp trên một id mà cả hai đều chứa
criterion	Tên của chỉ số, trở thành chỉ số mà một quy tắc nêu tên
score	Một số trên thang đo của chỉ số, hoặc để trống nếu công cụ không chấm điểm trường hợp đó
passed	true hoặc false thay cho một điểm số, hoặc để trống
score_min, score_max	Thang đo chứa điểm số (0 và 1 đối với hầu hết các công cụ), bắt buộc khi có điểm số
judge, judge_version	Mô hình đã đánh giá, nếu có một mô hình đánh giá. Tùy chọn

Không có gì khác được đọc, và một tệp có bất kỳ cột nào khác sẽ bị từ chối: một tệp chứa id trường hợp và điểm số, không bao giờ chứa một câu hỏi, một câu trả lời hay bất kỳ nội dung nào khác. Các công thức chuyển đổi bên dưới biến kết quả của mỗi công cụ thành tệp này.

Chạy thử

oloproof init --example second-opinion second-opinion
cd second-opinion

Ví dụ chứa hai bản xuất về độ trung thành (faithfulness) của một trợ lý hỗ trợ khách hàng trên 150 câu hỏi, trước và sau một thay đổi prompt, theo cách giám khảo của một công cụ khác đã chấm chúng: một điểm số từ 0 đến 1, và kết quả đạt hoặc không đạt của nó ở ngưỡng 0.7. make_exports.py là mô phỏng đã ghi ra chúng. Điểm trung bình đã tăng khoảng 0.02.

oloproof scores import before.csv after.csv --policy release.yaml

faithfulness: +0.023 [-0.024, +0.068] · 150 paired · 0 missing · 0 excluded
faithfulness_passed: +5.3 points [-6.9, +18.0] · 150 paired · 0 missing · 0 excluded
Decisions
  score-went-up  faithfulness  superiority  INSUFFICIENT_EVIDENCE  evaluator_not_validated
  more-answers-pass  faithfulness_passed  superiority  INSUFFICIENT_EVIDENCE  evaluator_not_validated
Gate: BLOCK (exit 3)
score-went-up, more-answers-pass: the judge (or model or custom evaluator) behind these rules has not been measured against people yet, so it may not decide.

Mỗi tệp đã trở thành một lần chạy, và hai lần chạy được so sánh theo từng trường hợp. Câu trả lời có hai nửa.

Điều đó có thật không? Chưa. Điểm số đã tăng 0.023, nhưng khoảng trải từ thấp hơn 0.024 đến cao hơn 0.068: với 150 câu hỏi, một thay đổi nhỏ như vậy không thể phân biệt được với nhiễu. Tỷ lệ câu trả lời mà giám khảo cho đạt đã tăng 5.3 điểm, với một khoảng từ thấp hơn 6.9 điểm đến cao hơn 18.0 điểm.
Bạn có thể tin giám khảo không? Chưa ai kiểm tra nó. release.yaml chỉ cho phép một giám khảo quyết định một lần phát hành khi nhãn của con người đã đo nó (require_validated_evaluators: true), nên cả hai quy tắc dừng lại ở evaluator_not_validated trước khi đi tới khoảng.

Để chỉ xem nửa thứ nhất, như thể giám khảo đã được kiểm tra:

oloproof scores import before.csv after.csv --policy statistics-only.yaml

  score-went-up  faithfulness  superiority  INSUFFICIENT_EVIDENCE  interval_overlaps_zero
  more-answers-pass  faithfulness_passed  superiority  INSUFFICIENT_EVIDENCE  interval_overlaps_zero

Trong CI, thêm --summary markdown >> "$GITHUB_STEP_SUMMARY": pull request khi đó mở đầu bằng "Is it real?" và một dòng cho mỗi quy tắc, nói "not established" và lý do, còn mã thoát vẫn như cũ. Các dòng riêng của lệnh nhập đi ra standard error, nên bản tóm tắt chỉ nhận câu trả lời (CI).

Không có --policy, lệnh báo cáo so sánh và không quyết định gì. Với một tệp, nó báo cáo lần chạy đó, và --policy làm cổng cho lần chạy đó theo các quy tắc lần chạy của chính sách.

Kiểm tra giám khảo

Con người gán nhãn một mẫu ngẫu nhiên gồm các trường hợp của một lần chạy đã nhập, mà không thấy phán quyết của giám khảo, và Oloproof đo giám khảo so với các nhãn đó:

oloproof labels export RUN_ID --criterion faithfulness_passed --sample 60 --out sample.csv
oloproof labels import sample.csv
oloproof evaluators validate EVALUATOR_ID --by NAME

Mẫu hiển thị id của mỗi trường hợp và không có gì về phán quyết của giám khảo. Người gán nhãn đọc trường hợp trong công cụ đang lưu giữ nó, theo id của nó, và ghi pass hoặc fail vào passed. oloproof evaluators list cho biết id của bộ đánh giá. Khi đã được xác thực, các quy tắc đọc giám khảo đó sẽ quyết định chỉ dựa trên bằng chứng.

Nhãn là đạt hoặc không đạt, nên chúng kiểm tra phán quyết đạt hoặc không đạt của một giám khảo, không phải điểm số của nó. Hãy nhập phán quyết bên cạnh điểm số, như ví dụ làm với faithfulness_passed: đó là tiêu chí mà con người có thể xác thực.

Từ công cụ của bạn

Thư mục recipes/ của ví dụ chứa một tập lệnh ngắn cho mỗi công cụ. Mỗi tập lệnh đọc kết quả của công cụ đó và ghi ra tệp, chỉ giữ id và điểm số. Chạy một tập lệnh cho mỗi phiên bản, rồi nhập hai tệp.

Công cụ	Công thức chuyển đổi	Điều xác định một trường hợp qua hai lần chạy	Ghi chú
DeepEval	deepeval_results.py RESULTS_JSON OUT	name của test case	Lưu kết quả bằng DisplayConfig(results_folder=...) và đặt tên cho mọi LLMTestCase. Mỗi chỉ số cho điểm số của nó và kết quả đạt hoặc không đạt của nó dưới dạng <metric>_passed, cùng với mô hình giám khảo
Braintrust	braintrust_experiment.py PROJECT EXPERIMENT OUT	Bản ghi tập dữ liệu mà experiment đã chạy (origin.id)	Điểm số từ 0 đến 1; --judge nêu tên mô hình nếu một mô hình đã chấm tất cả
LangSmith	langsmith_experiment.py EXPERIMENT OUT --scale LOW HIGH	Ví dụ trong tập dữ liệu (reference_example_id)	Một điểm số true hoặc false trở thành đạt hoặc không đạt; một điểm số dạng số cần thang đo của nó
Langfuse	langfuse_experiment.py EXPERIMENT SINCE OUT	Mục trong tập dữ liệu (experiment_item_id)	Các experiment của Langfuse 5; điểm số dạng số trên phạm vi của cấu hình điểm số tương ứng, hoặc --scale

Các công thức chuyển đổi tuân theo SDK của mỗi công cụ như đã được phát hành vào ngày 16 tháng 10 năm 2026 (DeepEval 4.3.1, braintrust 0.46.1, langsmith 0.14.11, langfuse 5.0.2) và được kiểm thử trên các kết quả có cấu trúc đó, không phải trên một tài khoản thực. Một công cụ đổi tên một trường sẽ làm hỏng công thức chuyển đổi của nó, không phải lệnh nhập: tệp mà công thức ghi ra mới là hợp đồng.

Những gì một tệp phải làm đúng

Một trường hợp chỉ có trong một tệp sẽ bị coi là thiếu ở phía bên kia, được đếm và được giới hạn ở giá trị xấu nhất của nó; nó không bao giờ được ghép cặp với một trường hợp khác.
Một hàng thứ hai cho cùng một trường hợp và tiêu chí, một điểm số nằm ngoài score_min và score_max, một hàng có cả điểm số lẫn kết quả đạt hoặc không đạt, và một tiêu chí là điểm số trong một tệp nhưng là đạt hoặc không đạt trong tệp kia đều bị từ chối, và hàng đó được nêu tên.
Các tệp được so sánh phải thống nhất về thang đo và giám khảo của mỗi tiêu chí: điểm số từ hai giám khảo là hai dụng cụ đo, và chênh lệch giữa chúng một phần sẽ đến từ chính các dụng cụ đo.
Mỗi tệp là một phiên bản hệ thống được xác định bởi nội dung của nó. Nhập lại cùng một tệp sẽ dùng lại những gì đã được lưu; không có gì từng được thực thi, nên không lần chạy lại nào có thể tái tạo hay thay đổi một điểm số đã nhập.
--tool ghi lại nguồn gốc của điểm số, và --name đặt tên cho hệ thống của mỗi tệp; cả hai được giữ cùng với lần chạy.

Những gì chưa được xây dựng

Đọc trực tiếp định dạng xuất riêng của một công cụ: một công thức chuyển đổi biến nó thành tệp ở trên.
Tải các tệp lên trang được lưu trữ mà không cần cài đặt gì.
Xác thực điểm số của một giám khảo, thay vì các phán quyết đạt hoặc không đạt của nó.

So sánh một ứng viên với một đường cơ sở: những gì một so sánh ghép cặp đọc.
Quy tắc so sánh: vượt trội, không thua kém và tương đương.
Giám khảo: cách một giám khảo được đo so với con người trước khi được phép làm cổng.