Tutorial: mengevaluasi aplikasi RAG

Panduan yang dapat dijalankan untuk aplikasi retrieval-augmented, dalam dua jalur: aplikasi kotak hitam yang sudah ada yang retrieval, konteks, dan sitasinya Anda rekam dari luar, dan aplikasi bertahap yang dijalankan Oloproof tahap demi tahap sehingga oloproof diagnose dapat mengeksekusi ulang kasus yang gagal di bawah perubahan terkendali. Keduanya berjalan secara lokal tanpa kredensial penyedia.

Konsep di balik setiap langkah (tahap, label relevansi, konteks emas, empat label kegagalan) ada di halaman Evaluasi RAG; istilah kasus, evaluator, metrik, interval, dan gerbang ada di Konsep inti. Halaman ini adalah jalur praktik melalui semuanya.

Jalur mana yang milik Anda

Mulailah dengan A jika Anda ragu. Jalur ini tidak memerlukan perubahan pada aplikasi, dan berpindah ke B kemudian tetap mempertahankan dataset, evaluator, dan kebijakan.

Prasyarat

• Python 3.11 atau yang lebih baru, dan Oloproof terpasang (pip install oloproof).
• Proyek contoh, yang disertakan dalam paket: blackbox_rag untuk jalur A dan support_rag untuk jalur B. Salin salah satunya ke direktori baru dan bekerjalah di sana:

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

Setiap perintah di bawah dijalankan dari dalam direktori salinan. Eksekusi, penilaian, dan diagnosis disimpan di .oloproof/ di sana.

Jalur A: aplikasi yang sudah ada sebagai kotak hitam

File-filenya

Apa yang dikembalikan aplikasi

support_api berperilaku seperti aplikasi yang sudah Anda miliki: aplikasi ini mencari, menyusun prompt dari sumber terbaik yang muat dalam anggaran kata, menjawab, dan mengutip. Responsnya sudah membawa apa yang dilakukannya:

{
  "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"}]
}

Nama field aplikasi Anda akan berbeda. Yang penting adalah aplikasi itu dapat memberi tahu Anda, per pertanyaan, sumber berperingkat yang di-retrieve-nya, sumber yang mencapai model, dan sumber yang dikutipnya. Jika tidak bisa, tambahkan hal-hal itu ke respons atau log-nya lebih dulu: Oloproof mengukur apa yang direkam dan tidak pernah menyimpulkan retrieval dari sebuah jawaban.

Adapternya

run memanggil aplikasi tanpa perubahan dan memetakan respons ke tiga artefak bertipe, rekaman yang dibaca evaluator retrieval dan sitasi:

@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 merekam posisi sebagaimana diberikan dan tidak pernah mengurutkan ulang. Artefak yang cacat menghentikan eksekusi dengan kode keluar 2 alih-alih disimpan. case adalah objek input kasus, sehingga case["question"] adalah pertanyaan dari dataset.

Untuk menggunakan aplikasi Anda sendiri, ganti isi support_api dengan panggilan ke aplikasi itu (panggilan SDK, permintaan HTTP) dan pertahankan run. Arahkan system.callable di oloproof.yaml ke sana sebagai module:function.

Varian HTTP

Sistem HTTP tidak dapat memanggil perekam, sehingga responsnya yang membawa bukti, sudah dalam tiga bentuk di atas, dan konfigurasi menyebutkan letaknya:

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 menyajikan persis itu. Jalankan, lalu eksekusi terhadapnya:

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

Input kasus dikirim sebagai body JSON. output_path memilih keluaran dari respons, dan setiap entri artifacts merekam path bertitik sebagai jenis itu; field yang hilang atau cacat menghentikan eksekusi dengan kode keluar 2. Hasilnya identik dengan jalur callable di bawah. Di layanan Anda sendiri, objek bukti biasanya berupa field debug yang Anda aktifkan untuk lalu lintas evaluasi.

Apa yang dideklarasikan sebuah kasus

{"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 mencantumkan passage yang menjawab pertanyaan. Metrik retrieval membacanya. Kasus tanpanya, seperti office_hours, dikecualikan dari metrik itu dengan no_relevance_labels: kasus itu keluar dari penyebut alih-alih dihitung sebagai lolos atau gagal.
• expected.gold_context adalah teks passage itu sendiri. Jalur A tidak pernah memakainya; jalur B menggantikan konteks hasil retrieval dengannya selama diagnosis.

Kasus tanpa label adalah hal biasa dalam praktik, karena memberi label relevansi butuh usaha. Kasus itu tetap dihitung untuk pemeriksaan jawaban dan sitasi.

Memilih evaluator

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 memeriksa bahwa jawaban memuat teks yang diharapkan. Itulah pemeriksaan tugas: apakah pengguna mendapat jawaban yang benar. Gunakan pencocokan persis atau juri rubrik jika susunan katanya bervariasi.
• hit_rate dan recall pada k: 2 mengukur retrieval pada kedalaman yang benar-benar dimasukkan aplikasi ke prompt. Metrik retrieval pada kedalaman yang tidak pernah dilihat model menggambarkan indeksnya, bukan aplikasinya.
• citation_validity memeriksa bahwa setiap id yang dikutip menyebut passage yang mencapai model; require_citations: true juga menggagalkan jawaban yang tidak mengutip apa pun.
• groundedness_judge dan citation_support_judge (opsional) menanyakan kepada model apakah jawaban didukung oleh konteks. Keduanya memerlukan penyedia, model, dan kredensial di variabel lingkungan, serta memakan biaya per kasus; lihat Juri untuk apa yang harus dilampaui juri sebelum boleh menjadi gerbang.

Irisan relevant_position dan context_truncated tidak tersedia di sini: keduanya membandingkan posisi dengan top-k aplikasi, yang hanya dideklarasikan oleh sistem bertahap. Memintanya menghentikan eksekusi dengan slice 'relevant_position' compares relevant positions with top_k, so it needs a staged system.

Kebijakan rilis

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

Aturan min hanya lolos ketika seluruh interval melampaui batas bawah, gagal ketika seluruh interval berada di bawahnya, dan INSUFFICIENT_EVIDENCE selain itu. Aturan observed_count memutuskan berdasarkan kasus yang benar-benar dijalankan, tanpa interval: "tidak ada sitasi yang tidak valid di suite ini". Lihat Gerbang.

Jalankan

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

Cara membacanya:

• Gate: BLOCK (exit 1): sebuah aturan FAIL. Keluar 1 berarti FAIL; keluar 3 berarti gerbang memblokir tanpa FAIL (di sini akan berupa INSUFFICIENT_EVIDENCE); keluar 0 berarti tidak ada yang diblokir kebijakan. [DECIDED/COMPLETE] adalah status eksekusi: setiap kasus berjalan.
• citations-valid FAIL: satu jawaban tidak mengutip apa pun, dan require_citations menghitungnya sebagai tidak valid.
• answer-floor berstatus INSUFFICIENT_EVIDENCE, bukan PASS, meskipun 73.3% di atas 70%: dengan 15 kasus interval turun hingga 44.8%, sehingga bukti tidak dapat menunjukkan bahwa batas bawah terpenuhi.
• hit_rate_at_2 berbunyi 2 excluded: dua kasus tanpa label. Penyebutnya 13, bukan 15.
• Tabel Slices yang mengikutinya bersifat eksploratif dan tidak pernah menjadi gerbang; irisan di bawah min_slice_support tidak menampilkan interval.

Periksa kegagalannya

Id eksekusi ada di baris pertama keluaran eksekusi.

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 mencetak input, nilai yang diharapkan, keluaran, dan setiap penilaian satu kasus. Artefak yang direkam ada di bundel yang diekspor:

oloproof export RUN_ID

Setiap baris .oloproof/bundles/RUN_ID/cases.jsonl adalah rekaman satu kasus; field artifacts-nya memuat apa yang direkam. Untuk money_back, field itu berbunyi:

{"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": []}]}

Membaca keempat kegagalan hanya dari bukti yang direkam:

Tabel itu adalah pembacaan Anda atas rekaman. Itu adalah asosiasi antara kegagalan dan sebuah tahap, bukan penyebab yang terbukti: tidak ada yang mengeksekusi ulang kasus dengan tahap itu diubah.

Apa yang dilakukan diagnose pada kotak hitam

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

Setiap kasus berstatus UNRESOLVED dengan alasan intervention_unsupported. Oloproof tidak dapat memberi kotak hitam passage emas sebagai pengganti retrieval-nya sendiri, sehingga Oloproof tidak berpura-pura. Intervensi terkendali memerlukan jalur B.

Buat perubahan kandidat dan bandingkan

Rekaman menyatakan money_back gagal di retrieval. Perubahan kandidat memperluas pertanyaan dengan sinonim sebelum mencari. Di app.py:

EXPAND_QUERY = True

Mengubah kode mengubah versi sistem yang direkam untuk eksekusi. Jalankan lagi, lalu bandingkan kandidat dengan baseline:

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

Eksekusi kandidat saja: citations-valid sekarang PASS, hit_rate_at_2 berbunyi 100.0% [75.2%, 100.0%], dan gerbang tetap memblokir dengan keluar 3 karena answer-floor dan retrieval-floor masih INSUFFICIENT_EVIDENCE. Perbandingannya:

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)

Perubahan itu memperbaiki kasus yang ditargetkannya (satu jawaban lagi, +6.7 poin atas 15 kasus berpasangan). Perbandingan tetap tidak dapat menetapkan bahwa kandidat tidak lebih buruk daripada baseline melebihi margin: 15 kasus berpasangan menyisakan interval selebar sekitar 67 poin. Baris perencanaan menyebutkan berapa banyak lagi kasus berpasangan yang akan memutuskannya jika selisihnya bertahan. Suite yang lebih besar, bukan margin yang berbeda, adalah tindakan berikutnya. Lihat Membandingkan dua eksekusi dan Aturan perbandingan.

Jalur B: aplikasi bertahap dengan diagnosis

File-file bertahap

Jalur B menjalankan contoh support_rag, yang dijelaskan di halaman Evaluasi RAG. Salin:

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

Perbedaannya dari jalur A adalah siapa yang menyusun konteks. Di sini Oloproof memanggil retrieve, mempertahankan top_k kandidat pertama, membuang passage yang melewati token_budget, dan meneruskan sisanya ke generate. Karena Oloproof memisahkan tahap-tahapnya, Oloproof dapat meng-cache-nya secara terpisah dan mengeksekusi ulang generasi dengan konteks yang berbeda. Untuk menyesuaikan aplikasi Anda sendiri, ganti isi retrieve (panggil indeks Anda, kembalikan Retrieval(candidates=[Passage(...)]) dalam urutan retriever Anda) dan generate (panggil model Anda dengan passage yang diberikan). Tetapkan index_version ke sesuatu yang berubah ketika indeks Anda berubah: nilai itu bagian dari identitas retrieval, dan nilai yang usang memakai ulang retrieval yang di-cache terhadap indeks yang tidak lagi mengembalikannya.

Konfigurasi yang sama juga memungkinkan irisan relevant_position dan context_truncated, serta evaluator ndcg atas seluruh kedalaman retrieval.

Jalankan suite bertahap

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

Baris Stages adalah cache milik sistem bertahap itu sendiri. Keluar 3: tidak ada yang FAIL, tetapi dua aturan tidak memiliki bukti untuk PASS.

Diagnosis dengan konteks emas, di samping kontrol

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…

Dua eksekusi anak dibuat dari kasus yang gagal: satu dengan gold_context kasus sebagai pengganti konteks hasil retrieval, dan satu kontrol yang mengeksekusi ulang kasus tanpa perubahan. Kontrol itulah yang membuat pembacaan aman: kasus yang lolos pada eksekusi ulang biasa itu tidak stabil, bukan terdiagnosis. diagnose keluar dengan 0 apa pun temuannya; perintah ini tidak memutuskan apa pun tentang rilis.

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

Membaca labelnya

Setiap label adalah asosiasi antara kegagalan dan sebuah tahap di bawah satu intervensi pada kasus-kasus ini. Itu bukan penyebab yang terbukti: "Implicated" dan "Candidate experiment" adalah kata-kata terkuat yang dipakai keluaran, dan hitungannya hanya menggambarkan kasus yang dipilih ("no population claim"). seat_count adalah pengingat yang baik: kasus itu gagal dengan passage yang benar karena basis pengetahuan mengatakan "five" dan kasus mengharapkan "5", yang tidak dapat diperbaiki oleh perubahan retrieval apa pun.

Kasus dengan dan tanpa passage emas

Hanya kasus gagal yang mendeklarasikan expected.gold_context yang dapat dieksekusi ulang. Hapus passage emas dari seat_count dan money_back (dan label relevansi dari money_back) dan perintah yang sama melaporkan:

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

Kasus yang dikecualikan dicantumkan, tidak dibuang diam-diam. Perhatikan juga apa akibat penghapusan label relevansi terhadap eksekusi itu sendiri: hit_rate_at_2 naik menjadi 100.0% (12 / 12 diamati, 1 dikecualikan), karena satu kasus yang terlewat oleh retrieval tidak lagi diukur. Kasus tanpa label keluar dari penyebut; kasus itu tidak dihitung sebagai lolos, dan metrik atas lebih sedikit kasus dapat tampak lebih baik daripada aplikasinya. Beri label pada kasus yang sulit lebih dulu.

Uji perbaikan sebelum melakukannya: top-k dan reranker

Dua intervensi lagi memutar ulang retrieval yang direkam dengan pengaturan berbeda, sehingga retriever tidak dipanggil lagi:

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

Reranker adalah fungsi (input, candidates) -> candidates yang Anda tulis. Simpan sebagai rerank.py di samping 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

Tidak satu pun memulihkan apa pun, sesuai yang diprediksi label konteks emas: tidak ada kegagalan di sini yang berupa passage yang berperingkat tepat di bawah batas. Setiap replay membawa label konteks emas ke depan, sehingga diagnosis-diagnosisnya terbaca bersama.

Jalankan eksperimen yang disebut diagnosis, dan bandingkan

Naikkan token_budget menjadi 120 di oloproof.yaml, lalu:

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

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

Setiap retrieval dipakai ulang, karena top_k dan anggaran berada di luar identitas retrieval; hanya enam kasus yang konteksnya berubah yang dibuat ulang.

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)

Eksperimen itu tidak membantu: tidak satu kasus pun mengubah putusannya, sehingga hipotesis yang ditawarkan diagnosis tidak didukung untuk kasus-kasus ini. Itu hasil yang berguna. Eksperimen berikutnya adalah chunk yang lebih kecil, atau prompt dari kedua kasus penyusunan konteks; seat_count perlu diperbaiki ekspektasinya.

Pemecahan masalah

Keterbatasan

• Oloproof memanggil aplikasi Anda; Oloproof tidak meng-hosting, mengisolasi, atau mengatur ulangnya. Indeks, cache, dan state apa pun yang disimpannya adalah milik Anda.
• Pada kotak hitam, intervensi tidak tersedia: diagnose memberi label UNRESOLVED pada setiap kasus dan tidak mengeksekusi ulang apa pun.
• Intervensinya adalah konteks emas, top-k, dan reranker. Tidak ada intervensi chunking, embedding, atau prompt.
• Label diagnosis menggambarkan kasus gagal yang dipilih di bawah satu intervensi di samping kontrol. Label itu mengaitkan kegagalan dengan sebuah tahap; label itu tidak membuktikan penyebab, dan tidak membuat klaim tentang kasus yang tidak dipilih.
• Metrik retrieval memerlukan label relevansi, dan diagnosis memerlukan passage emas; Oloproof tidak membuat keduanya.
• Contoh deterministik menggantikan retriever dan model sungguhan. Model langsung di generate atau evaluator juri memanggil penyedia, memerlukan kredensial, dan memakan biaya per kasus.
• Apa yang berfungsi di mana, SDK dibandingkan YAML dibandingkan browser, ada di Apa yang berfungsi hari ini.