Hướng dẫn: đánh giá một ứng dụng RAG

Một bài hướng dẫn có thể chạy được cho một ứng dụng tăng cường truy xuất, theo hai lộ trình: một ứng dụng hộp đen có sẵn mà bạn ghi lại việc truy xuất, ngữ cảnh và trích dẫn của nó từ bên ngoài, và một ứng dụng phân tầng mà Oloproof chạy từng tầng một để oloproof diagnose có thể thực thi lại các trường hợp thất bại dưới những thay đổi có kiểm soát. Cả hai đều chạy cục bộ mà không cần thông tin xác thực của nhà cung cấp.

Các khái niệm đằng sau mỗi bước (tầng, nhãn liên quan, ngữ cảnh chuẩn, bốn nhãn thất bại) nằm ở trang Đánh giá RAG; các thuật ngữ trường hợp, bộ đánh giá, chỉ số, khoảng và cổng nằm ở Khái niệm cốt lõi. Trang này là lộ trình thực hành đi qua chúng.

Lộ trình nào là của bạn

Hãy bắt đầu với A nếu bạn chưa chắc. Nó không cần thay đổi ứng dụng, và chuyển sang B sau này vẫn giữ nguyên tập dữ liệu, các bộ đánh giá và chính sách.

Điều kiện tiên quyết

• Python 3.11 trở lên, và Oloproof đã được cài (pip install oloproof).
• Các dự án ví dụ, đi kèm với gói: blackbox_rag cho lộ trình A và support_rag cho lộ trình B. Sao chép một dự án vào một thư mục mới và làm việc ở đó:

oloproof init --example blackbox_rag my-rag
cd my-rag

Mọi lệnh bên dưới chạy từ bên trong thư mục đã sao chép. Các lần chạy, phán quyết và chẩn đoán được lưu trong .oloproof/ ở đó.

Lộ trình A: một ứng dụng có sẵn như một hộp đen

Các tệp

Ứng dụng trả về gì

support_api hoạt động như một ứng dụng bạn đã có: nó tìm kiếm, xây một prompt từ các nguồn tốt nhất vừa với một ngân sách từ, trả lời và trích dẫn. Phản hồi của nó đã mang theo những gì nó đã làm:

{
  "answer": "Team plans include five seats.",
  "cited": ["kb-03"],
  "sources": [{"id": "kb-03", "score": 3.0, "text": "Team plans include five seats. ..."}],
  "prompt_sources": [{"id": "kb-03", "score": 3.0, "text": "...", "rank": 1, "tokens": 17}],
  "skipped": [{"id": "kb-05", "rank": 3, "why": "top_k"}]
}

Tên các trường trong ứng dụng của bạn sẽ khác. Điều quan trọng là nó có thể cho bạn biết, theo từng câu hỏi, các nguồn đã xếp hạng mà nó truy xuất, những nguồn đã tới được mô hình, và những nguồn nó đã trích dẫn. Nếu không thể, hãy thêm những thứ đó vào phản hồi hoặc log của nó trước: Oloproof đo những gì được ghi lại và không bao giờ suy ra việc truy xuất từ một câu trả lời.

Adapter

run gọi ứng dụng mà không thay đổi và ánh xạ phản hồi lên ba artifact có kiểu, những bản ghi mà các bộ đánh giá truy xuất và trích dẫn đọc:

@system(
    name="support-rag-blackbox",
    version="tutorial",
    records=("retrieval/v1", "context/v1", "citations/v1"),
)
def run(case):
    response = support_api(str(case["question"]))
    recorder = current_case()
    recorder.retrieval(
        Retrieval(
            query=case["question"],
            depth=SEARCH_DEPTH,
            candidates=tuple(
                Passage(doc_id=s["id"], score=s["score"], text=s["text"])
                for s in response["sources"]
            ),
        )
    )
    recorder.context(
        Context(
            items=tuple(
                ContextItem(doc_id=i["id"], position=i["rank"], tokens=i["tokens"], text=i["text"])
                for i in response["prompt_sources"]
            ),
            dropped=tuple(
                DroppedItem(doc_id=i["id"], position=i["rank"], reason=i["why"])
                for i in response["skipped"]
            ),
            token_budget=PROMPT_WORD_BUDGET,
        )
    )
    recorder.citations(response["cited"])
    return {"answer": response["answer"], "citations": response["cited"]}

Oloproof ghi lại vị trí như được đưa và không bao giờ xếp hạng lại. Một artifact sai dạng làm dừng lần chạy với mã thoát 2 thay vì được lưu. case là đối tượng input của trường hợp, nên case["question"] là câu hỏi từ tập dữ liệu.

Để dùng ứng dụng của chính bạn, hãy thay thân của support_api bằng một lời gọi tới nó (một lời gọi SDK, một yêu cầu HTTP) và giữ nguyên run. Trỏ system.callable trong oloproof.yaml tới nó dưới dạng module:function.

Biến thể HTTP

Một hệ thống HTTP không thể gọi bộ ghi, nên phản hồi của nó mang bằng chứng thay vào đó, đã ở sẵn ba hình dạng nêu trên, và cấu hình nêu vị trí của chúng:

system:
  name: support-rag-http
  version: tutorial
  http:
    url: http://127.0.0.1:8766/answer
    output_path: result
    artifacts:
      retrieval/v1: evidence.retrieval
      context/v1: evidence.context
      citations/v1: evidence.citations

server.py phục vụ đúng như vậy. Khởi động nó, rồi chạy trên nó:

python server.py 8766
oloproof run --config oloproof.http.yaml

Đầu vào của trường hợp được gửi làm thân JSON. output_path lấy đầu ra ra khỏi phản hồi, và mỗi mục artifacts ghi lại một đường dẫn có dấu chấm thành loại đó; một trường bị thiếu hoặc sai dạng làm dừng lần chạy với mã thoát 2. Kết quả giống hệt lộ trình callable bên dưới. Trong dịch vụ của chính bạn, đối tượng bằng chứng thường là một trường gỡ lỗi mà bạn bật cho lưu lượng đánh giá.

Một trường hợp khai báo gì

{"id":"seat_count","input":{"question":"How many seats does a team plan include?"},"expected":{"answer":"5 seats","relevant":[{"doc_id":"kb-03"}],"gold_context":[{"doc_id":"kb-03","text":"Team plans include five seats. ..."}]},"metadata":{"topic":"billing"}}
{"id":"office_hours","input":{"question":"What are the support office hours?"},"expected":{"answer":"09:00"},"metadata":{"topic":"account"}}

• expected.relevant liệt kê các đoạn văn trả lời câu hỏi. Các chỉ số truy xuất đọc nó. Một trường hợp không có nó, như office_hours, bị loại khỏi các chỉ số đó với no_relevance_labels: nó rời khỏi mẫu số thay vì được tính là đạt hay thất bại.
• expected.gold_context là chính văn bản của đoạn văn. Lộ trình A không bao giờ dùng nó; lộ trình B thay nó vào chỗ ngữ cảnh đã truy xuất trong khi chẩn đoán.

Các trường hợp không có nhãn là chuyện bình thường trên thực tế, vì gán nhãn liên quan tốn công. Chúng vẫn được tính cho các kiểm tra câu trả lời và trích dẫn.

Chọn các bộ đánh giá

evaluators:
  - {type: contains, criterion: answer_correct, field: answer, expected_field: answer}
  - {type: hit_rate, k: 2}
  - {type: recall, k: 2}
  - {type: citation_validity, require_citations: true}
slices: [metadata.topic]
min_slice_support: 4

• contains kiểm tra câu trả lời có chứa văn bản kỳ vọng. Đó là kiểm tra tác vụ: người dùng có nhận được câu trả lời đúng không. Hãy dùng một giám khảo chính xác hoặc rubric thay vào đó khi cách diễn đạt thay đổi.
• hit_rate và recall ở k: 2 đo việc truy xuất ở độ sâu mà ứng dụng thực sự đưa vào prompt. Một chỉ số truy xuất ở độ sâu mà mô hình không bao giờ thấy mô tả chỉ mục, không phải ứng dụng.
• citation_validity kiểm tra mọi id được trích dẫn đều nêu một đoạn văn đã tới được mô hình; require_citations: true cũng đánh trượt một câu trả lời không trích dẫn gì.
• groundedness_judge và citation_support_judge (tùy chọn) hỏi một mô hình xem câu trả lời có được ngữ cảnh hỗ trợ không. Chúng cần một nhà cung cấp, một mô hình và thông tin xác thực trong một biến môi trường, và tốn tiền cho mỗi trường hợp; xem Giám khảo để biết một giám khảo phải vượt qua gì trước khi được làm cổng.

Các lát cắt relevant_position và context_truncated không khả dụng ở đây: chúng so sánh vị trí với top-k của ứng dụng, thứ mà chỉ một hệ thống phân tầng khai báo. Yêu cầu chúng sẽ làm dừng lần chạy với slice 'relevant_position' compares relevant positions with top_k, so it needs a staged system.

Chính sách phát hành

version: 1
confidence_level: 0.95
block_on: [FAIL, INSUFFICIENT_EVIDENCE, MANUAL_REVIEW]
rules:
  - id: answer-floor
    metric: answer_correct
    min: 0.70
  - id: retrieval-floor
    metric: hit_rate_at_2
    min: 0.80
  - id: citations-valid
    metric: citations_valid
    kind: observed_count
    max_failures: 0

Một quy tắc min chỉ đạt khi toàn bộ khoảng vượt qua mức sàn, thất bại khi toàn bộ khoảng nằm dưới nó, và là INSUFFICIENT_EVIDENCE trong trường hợp còn lại. Một quy tắc observed_count quyết định trên các trường hợp thực sự đã chạy, không có khoảng: "không có trích dẫn không hợp lệ nào trong bộ kiểm thử này". Xem Cổng.

Chạy

oloproof run

Run run_01M4FCBPE0G550CKCVGXCNEM2P [DECIDED/COMPLETE]
Gate: BLOCK (exit 1)
│ answer-floor    │ answer_correct  │ INSUFFICIENT_EVIDENCE │ interval_overlaps_threshold    │
│ retrieval-floor │ hit_rate_at_2   │ INSUFFICIENT_EVIDENCE │ interval_overlaps_threshold    │
│ citations-valid │ citations_valid │ FAIL                  │ observed_failures_exceed_limit │

│ answer_correct  │ 73.3%    │ [44.8%, 92.3%] │ 11 / 15 observed · 0 missing · 0 excluded │
│ hit_rate_at_2   │ 92.3%    │ [63.9%, 99.9%] │ 12 / 13 observed · 0 missing · 2 excluded │
│ recall_at_2     │ 92.3%    │ [63.9%, 99.9%] │ 12 / 13 observed · 0 missing · 2 excluded │
│ citations_valid │ 93.3%    │ [68.0%, 99.9%] │ 14 / 15 observed · 0 missing · 0 excluded │
Cache: execution 0 hit/15 miss; judgment 0 hit/56 miss

Cách đọc:

• Gate: BLOCK (exit 1): một quy tắc đã FAIL. Mã thoát 1 nghĩa là có một FAIL; mã thoát 3 nghĩa là cổng chặn mà không có FAIL (ở đây sẽ là INSUFFICIENT_EVIDENCE); mã thoát 0 nghĩa là không có gì mà chính sách chặn. [DECIDED/COMPLETE] là trạng thái thực thi: mọi trường hợp đều đã chạy.
• citations-valid FAIL: một câu trả lời không trích dẫn gì, và require_citations tính điều đó là không hợp lệ.
• answer-floor là INSUFFICIENT_EVIDENCE, không phải PASS, dù 73,3% cao hơn 70%: với 15 trường hợp, khoảng kéo xuống tới 44,8%, nên bằng chứng không thể cho thấy mức sàn được đáp ứng.
• hit_rate_at_2 ghi 2 excluded: hai trường hợp không có nhãn. Mẫu số của nó là 13, không phải 15.
• Bảng Slices theo sau mang tính khám phá và không bao giờ làm cổng; một lát cắt dưới min_slice_support không hiển thị khoảng.

Xem xét các thất bại

Mã lần chạy nằm ở dòng đầu tiên trong đầu ra của lần chạy.

oloproof inspect RUN_ID --failures

4 of 15 cases failed, errored or did not finish

refund_review
  output: {"answer": "Every refund request on an annual plan is logged in the audit trail, and the same request is listed again on the day it was reviewed and approved."…
  answer_correct: failed

money_back
  output: {"answer": "I could not find that in the knowledge base.", "citations": []}
  answer_correct: failed
  hit_rate_at_2: failed
  recall_at_2: failed
  citations_valid: failed

security_review
  output: {"answer": "Security reviews during Enterprise onboarding include an access review and a written summary for the customer, and every review is scheduled with t…
  answer_correct: failed

seat_count
  output: {"answer": "Team plans include five seats.", "citations": ["kb-03"]}
  answer_correct: failed

oloproof inspect RUN_ID --case refund_review in ra đầu vào, các giá trị kỳ vọng, đầu ra và mọi phán quyết của một trường hợp. Các artifact được ghi lại nằm trong gói đã xuất:

oloproof export RUN_ID

Mỗi dòng của .oloproof/bundles/RUN_ID/cases.jsonl là bản ghi của một trường hợp; trường artifacts của nó chứa những gì đã được ghi lại. Với money_back, trường đó ghi:

{"retrieval/v1": [{"candidates": [], "depth": 6, "query": "Where do I claim money back on a yearly subscription?"}], "context/v1": [{"dropped": [], "items": [], "source": "retrieval", "token_budget": 40}], "citations/v1": [{"ids": []}]}

Đọc bốn thất bại chỉ từ bằng chứng đã ghi:

Bảng đó là cách bạn đọc bản ghi. Đó là một mối liên hệ giữa một thất bại và một tầng, không phải một nguyên nhân đã được chứng minh: không có gì thực thi lại trường hợp với tầng đó được thay đổi.

Diagnose làm gì trên một hộp đen

oloproof diagnose RUN_ID --intervention gold-context --criterion answer_correct

Selected: 4 failed cases with gold context (observed; no population claim)
UNRESOLVED: 4 of 4, the system is not staged, so no case was re-executed
Diagnosis sha256:8809e100ab2ec1dad8ffeacc136cd510300081a0edf01ec11f881c543ed104bc
Cases: oloproof inspect sha256:8809e100ab2ec1dad8ffeacc136cd510300081a0edf01ec11f881c543ed104bc

Mọi trường hợp đều UNRESOLVED với lý do intervention_unsupported. Oloproof không thể đưa cho một hộp đen đoạn văn chuẩn thay cho việc truy xuất của chính nó, nên nó không giả vờ làm vậy. Các can thiệp có kiểm soát cần lộ trình B.

Thực hiện một thay đổi ứng viên và so sánh

Bản ghi nói money_back thất bại ở bước truy xuất. Thay đổi ứng viên mở rộng câu hỏi bằng từ đồng nghĩa trước khi tìm kiếm. Trong app.py:

EXPAND_QUERY = True

Thay đổi mã sẽ thay đổi phiên bản hệ thống được ghi cho lần chạy. Chạy lại, rồi so sánh ứng viên với đường cơ sở:

oloproof run
oloproof compare CANDIDATE_RUN_ID BASELINE_RUN_ID --policy compare.yaml

Riêng lần chạy ứng viên: citations-valid giờ PASS, hit_rate_at_2 ghi 100.0% [75.2%, 100.0%], và cổng vẫn chặn với mã thoát 3 vì answer-floor và retrieval-floor vẫn là INSUFFICIENT_EVIDENCE. Phép so sánh:

Comparison sha256:2feb024c… of run_01M4FCCJYCVVYA8NB4XZDV6YMB against run_01M4FCCHVBG9WHDP7G5HFX7RDT · 15 paired cases
answer_correct: +6.7 points [-26.5, +40.8] · 15 paired · 0 missing · 0 excluded
hit_rate_at_2: +7.7 points [-29.8, +45.5] · 13 paired · 0 missing · 2 excluded
  excluded 2: no_relevance_labels
recall_at_2: +7.7 points [-29.8, +45.5] · 13 paired · 0 missing · 2 excluded
  excluded 2: no_relevance_labels
citations_valid: +6.7 points [-26.5, +40.8] · 15 paired · 0 missing · 0 excluded
20 exploratory slice differences not shown; add --slices to list them
Decisions
  answers-not-worse  answer_correct  non-inferiority, margin 5.0 points  INSUFFICIENT_EVIDENCE  interval_overlaps_margin
    about 38 more paired cases would decide it, if the difference holds (53 in total at 7% discordance)
  citations-not-worse  citations_valid  non-inferiority, margin 2.0 points  INSUFFICIENT_EVIDENCE  interval_overlaps_margin
    about 68 more paired cases would decide it, if the difference holds (83 in total at 7% discordance)
Gate: BLOCK (exit 3)

Thay đổi đã sửa được trường hợp nó nhắm tới (thêm một câu trả lời, +6,7 điểm trên 15 trường hợp ghép cặp). Phép so sánh vẫn không thể xác lập rằng ứng viên không tệ hơn đường cơ sở quá biên: 15 trường hợp ghép cặp để lại một khoảng rộng khoảng 67 điểm. Dòng lập kế hoạch cho biết cần thêm bao nhiêu trường hợp ghép cặp để quyết định nếu khác biệt giữ nguyên. Một bộ kiểm thử lớn hơn, không phải một biên khác, là hành động tiếp theo. Xem So sánh hai lần chạy và Quy tắc so sánh.

Lộ trình B: một ứng dụng phân tầng với chẩn đoán

Các tệp phân tầng

Lộ trình B chạy ví dụ support_rag, được mô tả ở trang Đánh giá RAG. Sao chép nó:

oloproof init --example support_rag my-staged-rag
cd my-staged-rag

Khác biệt so với lộ trình A là ai lắp ráp ngữ cảnh. Ở đây Oloproof gọi retrieve, giữ top_k ứng viên đầu tiên, bỏ các đoạn văn vượt quá token_budget, và chuyển phần còn lại cho generate. Vì nó giữ các tầng tách biệt, nó có thể lưu đệm chúng riêng và thực thi lại bước sinh với một ngữ cảnh khác. Để điều chỉnh ứng dụng của chính bạn, hãy thay thân của retrieve (gọi chỉ mục của bạn, trả về Retrieval(candidates=[Passage(...)]) theo thứ tự của bộ truy xuất) và generate (gọi mô hình của bạn với các đoạn văn được đưa). Đặt index_version thành một giá trị thay đổi khi chỉ mục của bạn thay đổi: nó là một phần danh tính của việc truy xuất, và một giá trị cũ sẽ tái sử dụng các lần truy xuất đã lưu đệm trên một chỉ mục không còn trả về chúng.

Cùng cấu hình đó cũng cho phép các lát cắt relevant_position và context_truncated, và một bộ đánh giá ndcg trên toàn bộ độ sâu truy xuất.

Chạy bộ kiểm thử phân tầng

oloproof run

Gate: BLOCK (exit 3)
│ answer-floor    │ answer_correct  │ INSUFFICIENT_EVIDENCE │ interval_overlaps_threshold    │
│ retrieval-floor │ hit_rate_at_2   │ INSUFFICIENT_EVIDENCE │ interval_overlaps_threshold    │
│ citations-valid │ citations_valid │ PASS                  │ observed_failures_within_limit │
│ answer_correct  │ 69.2%    │ [38.5%, 91.0%]  │ 9 / 13 observed · 0 missing · 0 excluded     │
│ hit_rate_at_2   │ 92.3%    │ [63.9%, 99.9%]  │ 12 / 13 observed · 0 missing · 0 excluded    │
│ recall_at_2     │ 92.3%    │ [63.9%, 99.9%]  │ 12 / 13 observed · 0 missing · 0 excluded    │
│ ndcg_at_6       │ 0.866    │ [0.506, 0.990]  │ mean of 13 observed · 0 missing · 0 excluded │
│ citations_valid │ 100.0%   │ [75.2%, 100.0%] │ 13 / 13 observed · 0 missing · 0 excluded    │
Cache: execution 0 hit/13 miss; judgment 0 hit/65 miss
Stages: retrieve 0 hit/13 miss; generate 0 hit/13 miss

Dòng Stages là bộ nhớ đệm riêng của hệ thống phân tầng. Mã thoát 3: không có gì FAIL, nhưng hai quy tắc thiếu bằng chứng để PASS.

Chẩn đoán với ngữ cảnh chuẩn, bên cạnh một nhóm đối chứng

oloproof diagnose RUN_ID --intervention gold-context --criterion answer_correct

Selected: 4 failed cases with gold context (observed; no population claim)
Control: 0 of 4 passed when re-executed without the intervention
Recovered under gold context: 3 of 4
RETRIEVAL_MISS: 1 of 4, recovered; no relevant evidence was retrieved
CONTEXT_ASSEMBLY_LOSS: 2 of 4, recovered; relevant evidence within top-k was left out of the context
GENERATION_FAILURE: 1 of 4, still failed with the gold context
Implicated: context budget, in 2 of the 3 recovered failures.
Candidate experiment: a larger token budget. This is a hypothesis to test, not an established cause.
Candidate experiment: smaller chunks. This is a hypothesis to test, not an established cause.
Diagnosis sha256:50a6124f…
Child runs: gold context run_…, control run_…
Cases: oloproof inspect sha256:50a6124f…

Hai lần chạy con được tạo từ các trường hợp thất bại: một lần với gold_context của trường hợp thay cho ngữ cảnh đã truy xuất, và một nhóm đối chứng thực thi lại chúng mà không thay đổi. Nhóm đối chứng là điều làm cho cách đọc an toàn: một trường hợp đạt khi chạy lại đơn thuần là không ổn định, chứ chưa được chẩn đoán. diagnose thoát với 0 dù nó tìm thấy gì; nó không quyết định gì về bản phát hành.

oloproof inspect DIAGNOSIS_ID

money_back: RETRIEVAL_MISS, relevant_not_retrieved, strength intervention_recovery, best relevant position none
refund_review: CONTEXT_ASSEMBLY_LOSS, relevant_dropped_from_context, strength intervention_recovery, best relevant position 2
seat_count: GENERATION_FAILURE, fails_with_gold_context, strength intervention_non_recovery, best relevant position 1
security_review: CONTEXT_ASSEMBLY_LOSS, relevant_dropped_from_context, strength intervention_recovery, best relevant position 2

Đọc các nhãn

Mọi nhãn đều là một mối liên hệ giữa một thất bại và một tầng dưới một can thiệp trên các trường hợp này. Đó không phải một nguyên nhân đã được chứng minh: "Implicated" và "Candidate experiment" là những từ mạnh nhất mà đầu ra dùng, và các số đếm chỉ mô tả các trường hợp đã chọn ("no population claim"). seat_count là một lời nhắc tốt: nó thất bại với đúng đoạn văn vì cơ sở tri thức nói "five" còn trường hợp kỳ vọng "5", điều mà không thay đổi truy xuất nào sửa được.

Các trường hợp có và không có đoạn văn chuẩn

Chỉ các trường hợp thất bại có khai báo expected.gold_context mới có thể được thực thi lại. Bỏ đoạn văn chuẩn khỏi seat_count và money_back (và nhãn liên quan khỏi money_back) thì cùng lệnh đó báo:

Selected: 2 failed cases with gold context (observed; no population claim)
Excluded: 2 failed cases, no_gold_context - declare the passages that would have answered the case in its `expected.gold_context`, as a list of `{doc_id, text}` objects; an intervention needs them to tell a retrieval failure from a generation one
Control: 0 of 2 passed when re-executed without the intervention
Recovered under gold context: 2 of 2
CONTEXT_ASSEMBLY_LOSS: 2 of 2, recovered; relevant evidence within top-k was left out of the context

Các trường hợp bị loại được liệt kê, không bị âm thầm bỏ đi. Cũng lưu ý việc bỏ một nhãn liên quan tác động thế nào tới chính lần chạy: hit_rate_at_2 tăng lên 100.0% (12 / 12 observed, 1 excluded), vì trường hợp duy nhất mà việc truy xuất bỏ sót không còn được đo. Các trường hợp không có nhãn rời khỏi mẫu số; chúng không được tính là đạt, và một chỉ số trên ít trường hợp hơn có thể trông tốt hơn thực tế của ứng dụng. Hãy gán nhãn cho các trường hợp khó trước.

Thử một bản sửa trước khi thực hiện: top-k và một reranker

Hai can thiệp nữa phát lại việc truy xuất đã ghi với một thiết lập khác, nên bộ truy xuất không bị gọi lại:

oloproof diagnose RUN_ID --intervention top-k --top-k 4 --criterion answer_correct

Recovered under top-k 4: 0 of 4
Confirmed under top-k 4: 0 of 0 RANKED_OUT cases also recovered
Labels from gold context (diagnosis sha256:50a6124f…): 3 of 4 recovered

Một reranker là một hàm (input, candidates) -> candidates do bạn viết. Lưu nó thành rerank.py bên cạnh app.py:

"""A candidate reranker: shorter passages first, so more of them fit the token budget."""

from oloproof import Passage


def shortest_first(input: dict, candidates: list[Passage]) -> list[Passage]:
    return sorted(candidates, key=lambda passage: len((passage.text or "").split()))

oloproof diagnose RUN_ID --intervention reranker --reranker rerank:shortest_first --criterion answer_correct

Recovered under reranker rerank:shortest_first: 0 of 4
Confirmed under reranker rerank:shortest_first: 0 of 0 RANKED_OUT cases also recovered

Không cái nào phục hồi được gì, đúng như các nhãn ngữ cảnh chuẩn đã dự đoán: không thất bại nào ở đây là một đoạn văn xếp hạng ngay dưới ngưỡng cắt. Mỗi lần phát lại mang các nhãn ngữ cảnh chuẩn đi tiếp, nên các chẩn đoán được đọc cùng nhau.

Chạy thử nghiệm mà chẩn đoán đã nêu, và so sánh

Nâng token_budget lên 120 trong oloproof.yaml, rồi:

oloproof run
oloproof compare CANDIDATE_RUN_ID BASELINE_RUN_ID --policy compare.yaml

Stages: retrieve 13 hit/0 miss; generate 7 hit/6 miss

Mọi lần truy xuất đều được tái sử dụng, vì top_k và ngân sách nằm ngoài danh tính của việc truy xuất; chỉ sáu trường hợp có ngữ cảnh thay đổi được sinh lại.

answer_correct: +0.0 points [-33.6, +33.6] · 13 paired · 0 missing · 0 excluded
Decisions
  answers-not-worse  answer_correct  non-inferiority, margin 5.0 points  INSUFFICIENT_EVIDENCE  interval_overlaps_margin
  citations-not-worse  citations_valid  non-inferiority, margin 2.0 points  INSUFFICIENT_EVIDENCE  interval_overlaps_margin
Gate: BLOCK (exit 3)

Thử nghiệm không giúp được gì: không một trường hợp nào thay đổi phán quyết, nên giả thuyết mà chẩn đoán đưa ra không được hỗ trợ với các trường hợp này. Đó là một kết quả hữu ích. Thử nghiệm tiếp theo là các đoạn nhỏ hơn, hoặc prompt của hai trường hợp lắp ráp ngữ cảnh; seat_count cần sửa lại kỳ vọng của nó.

Khắc phục sự cố

Giới hạn

• Oloproof gọi ứng dụng của bạn; nó không lưu trữ, cô lập hay đặt lại ứng dụng. Chỉ mục, bộ nhớ đệm và mọi trạng thái mà nó giữ là của bạn.
• Trên một hộp đen, các can thiệp không khả dụng: diagnose gán nhãn UNRESOLVED cho mọi trường hợp và không thực thi lại gì cả.
• Các can thiệp là ngữ cảnh chuẩn, top-k và một reranker. Không có can thiệp về chia đoạn, embedding hay prompt.
• Các nhãn chẩn đoán mô tả các trường hợp thất bại đã chọn dưới một can thiệp bên cạnh một nhóm đối chứng. Chúng liên hệ một thất bại với một tầng; chúng không chứng minh một nguyên nhân, và không khẳng định gì về các trường hợp không được chọn.
• Các chỉ số truy xuất cần nhãn liên quan, và việc chẩn đoán cần các đoạn văn chuẩn; Oloproof không tạo ra cái nào trong số đó.
• Các ví dụ tất định đứng thay cho một bộ truy xuất và một mô hình thật. Một mô hình thật trong generate hoặc một bộ đánh giá giám khảo sẽ gọi một nhà cung cấp, cần thông tin xác thực và tốn tiền cho mỗi trường hợp.
• Cái gì hoạt động ở đâu, SDK so với YAML so với trình duyệt, có ở Những gì hoạt động hôm nay.