altair823-org/kebab
0
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 40 Wiki Activity

feat(eval): fb-41 multi-hop golden set + spec/plan #166

Merged
altair823 merged 2 commits from feat/fb-41-multi-hop-eval-golden into main 2026-05-25 06:27:08 +00:00
Conversation 2 Commits 2 Files Changed 4 +710 -1
altair823 commented 2026-05-25 06:22:42 +00:00
Owner
Copy Link

요약

fb-41 multi-hop RAG (XL 작업) 의 PR-1. baseline 측정 anchor 만 추가 — RAG pipeline 미변경, fixture file + parse 회귀 핀.

설계: docs/superpowers/specs/2026-05-25-p9-fb-41-multi-hop-rag-design.md
계획: docs/superpowers/plans/2026-05-25-p9-fb-41-multi-hop-rag.md

사용자 결정 4 axis (2026-05-25)

  • approach: query decomposition (LLM 서브-질문)
  • trigger: explicit --multi-hop flag
  • MVP scope: dynamic N-hop (LLM 이 depth 결정, decompose seed + ReAct-style decide loop hybrid)
  • eval: multi-hop golden set 먼저 (본 PR)

변경

  • fixtures/multi_hop_golden.yaml 신규. 15 question (5 cross-doc + 5 intra-doc + 5 single-fact negative). 기존 GoldenQuery struct 그대로 사용 — 별 loader / type 변경 없음. expected_chunk_ids 비어 있어 curator 가 kebab ingest 후 채울 수 있는 template 형태. must_contain 으로 baseline 측정 가능 (P5-2 metric).
  • crates/kebab-eval/tests/loader.rs::loads_multi_hop_golden_fixture 신규 회귀 핀. fixture parse OK + 15 question + 5/5/5 bucket 분포 + 모든 question 에 must_contain 최소 1 개.
  • spec (design doc, 311 lines) + plan (implementation steps, 241 lines).

Baseline 측정 protocol

본 PR 자체는 baseline artifact 를 commit 하지 않음. 사용자 측 별도 run:

  1. v0.17.2 binary 로 kebab eval run --fixture fixtures/multi_hop_golden.yaml (현 single-pass).
  2. P@5, P@10, must_contain pass rate, citation_coverage 캡처.
  3. PR-3 (dynamic iter) 머지 후 동일 fixture + multi_hop=true 재실행 → Δ.

expected_chunk_ids 가 비어 있어 precision_at_k_chunk (fb-39) 는 skip; 나머지 metric (rule-based answer correctness + citation_coverage) 가 작동. 사용자가 ingest 후 chunk_id 채우면 더 정밀한 baseline 측정 가능.

PR 분할 6 단계 (plan 참조)

  • PR-1 (본 PR): fixture only.
  • PR-2: RagPipeline::ask_multi_hop (fixed depth=2) + AskOpts.multi_hop + impl Default for AskOpts.
  • PR-3: dynamic iter (decide loop + max_depth / max_sub_queries / max_pool_chunks cap), wire Answer.hops 노출.
  • PR-4: CLI --multi-hop flag + answer.v1 schema additive + error.v1 신규 code multi_hop_decompose_failed.
  • PR-5: MCP ask tool 의 multi_hop argument + SKILL.md.
  • PR-6: TUI Ask multi-hop toggle (binding TBD: F2 / Ctrl-T) + hop trace render.

마지막 PR 후 v0.18.0 cut — minor bump (frozen design §3.8 갱신 + 사용자 visible 새 surface + prompt_template_version = rag-multi-hop-v1 cascade).

검증

  • cargo test -p kebab-eval --test loader -j 1 — 전부 녹색 (3 test 통과 포함 신규 회귀 핀).
  • cargo clippy -p kebab-eval --all-targets -j 1 -- -D warnings — clean.

시험 항목 (Test Plan)

  • loads_multi_hop_golden_fixture 신규 — fixture parse + 15 question + 5/5/5 분포 + must_contain 핀

비범위

  • RAG pipeline 변경 (PR-2 부터).
  • --multi-hop flag (PR-4).
  • baseline run 실행 / artifact 캡처 (별 run script, commit 안 함).
  • expected_chunk_ids 채우기 (사용자 ingest 후, 향후 PR 또는 별도 fixture curation commit).

다음 단계

PR-1 머지 후 PR-2 시작 (AskOpts.multi_hop + Default impl + ask_multi_hop skeleton fixed depth=2).

Assisted-by: Claude Code

## 요약 fb-41 multi-hop RAG (XL 작업) 의 PR-1. baseline 측정 anchor 만 추가 — RAG pipeline 미변경, fixture file + parse 회귀 핀. 설계: docs/superpowers/specs/2026-05-25-p9-fb-41-multi-hop-rag-design.md 계획: docs/superpowers/plans/2026-05-25-p9-fb-41-multi-hop-rag.md ## 사용자 결정 4 axis (2026-05-25) - approach: **query decomposition** (LLM 서브-질문) - trigger: **explicit `--multi-hop` flag** - MVP scope: **dynamic N-hop** (LLM 이 depth 결정, decompose seed + ReAct-style decide loop hybrid) - eval: **multi-hop golden set 먼저** (본 PR) ## 변경 - `fixtures/multi_hop_golden.yaml` 신규. **15 question** (5 cross-doc + 5 intra-doc + 5 single-fact negative). 기존 `GoldenQuery` struct 그대로 사용 — 별 loader / type 변경 없음. `expected_chunk_ids` 비어 있어 curator 가 `kebab ingest` 후 채울 수 있는 template 형태. `must_contain` 으로 baseline 측정 가능 (P5-2 metric). - `crates/kebab-eval/tests/loader.rs::loads_multi_hop_golden_fixture` 신규 회귀 핀. fixture parse OK + 15 question + 5/5/5 bucket 분포 + 모든 question 에 `must_contain` 최소 1 개. - spec (design doc, 311 lines) + plan (implementation steps, 241 lines). ## Baseline 측정 protocol 본 PR 자체는 baseline artifact 를 commit 하지 않음. 사용자 측 별도 run: 1. v0.17.2 binary 로 `kebab eval run --fixture fixtures/multi_hop_golden.yaml` (현 single-pass). 2. P@5, P@10, must_contain pass rate, citation_coverage 캡처. 3. PR-3 (dynamic iter) 머지 후 동일 fixture + `multi_hop=true` 재실행 → Δ. `expected_chunk_ids` 가 비어 있어 `precision_at_k_chunk` (fb-39) 는 skip; 나머지 metric (rule-based answer correctness + citation_coverage) 가 작동. 사용자가 ingest 후 chunk_id 채우면 더 정밀한 baseline 측정 가능. ## PR 분할 6 단계 (plan 참조) - **PR-1 (본 PR)**: fixture only. - PR-2: `RagPipeline::ask_multi_hop` (fixed depth=2) + `AskOpts.multi_hop` + `impl Default for AskOpts`. - PR-3: dynamic iter (decide loop + max_depth / max_sub_queries / max_pool_chunks cap), wire `Answer.hops` 노출. - PR-4: CLI `--multi-hop` flag + `answer.v1` schema additive + `error.v1` 신규 code `multi_hop_decompose_failed`. - PR-5: MCP `ask` tool 의 `multi_hop` argument + SKILL.md. - PR-6: TUI Ask multi-hop toggle (binding TBD: F2 / Ctrl-T) + hop trace render. 마지막 PR 후 **v0.18.0 cut** — minor bump (frozen design §3.8 갱신 + 사용자 visible 새 surface + `prompt_template_version = rag-multi-hop-v1` cascade). ## 검증 - `cargo test -p kebab-eval --test loader -j 1` — 전부 녹색 (3 test 통과 포함 신규 회귀 핀). - `cargo clippy -p kebab-eval --all-targets -j 1 -- -D warnings` — clean. ## 시험 항목 (Test Plan) - [x] `loads_multi_hop_golden_fixture` 신규 — fixture parse + 15 question + 5/5/5 분포 + must_contain 핀 ## 비범위 - RAG pipeline 변경 (PR-2 부터). - `--multi-hop` flag (PR-4). - baseline run 실행 / artifact 캡처 (별 run script, commit 안 함). - `expected_chunk_ids` 채우기 (사용자 ingest 후, 향후 PR 또는 별도 fixture curation commit). ## 다음 단계 PR-1 머지 후 PR-2 시작 (`AskOpts.multi_hop` + `Default` impl + `ask_multi_hop` skeleton fixed depth=2). Assisted-by: Claude Code
altair823 added 1 commit 2026-05-25 06:22:43 +00:00
feat(eval): fb-41 multi-hop golden set + spec/plan caf690dc72 
PR-1 of fb-41 multi-hop RAG (spec: docs/superpowers/specs/2026-05-25-
p9-fb-41-multi-hop-rag-design.md, plan: docs/superpowers/plans/2026-
05-25-p9-fb-41-multi-hop-rag.md).

XL 작업의 첫 PR — baseline 측정 anchor 만 추가. RAG pipeline 미변경,
fixture file + parse 회귀 핀.

사용자 결정 4 axis (2026-05-25):
- approach: query decomposition (LLM 서브-질문)
- trigger: explicit `--multi-hop` flag
- MVP scope: dynamic N-hop (LLM 이 depth 결정, decompose seed +
  ReAct-style decide loop hybrid)
- eval: multi-hop golden set 먼저 (본 PR)

본 PR:
- `fixtures/multi_hop_golden.yaml` 신규. 15 question (5 cross-doc +
  5 intra-doc + 5 single-fact negative). 기존 `GoldenQuery` struct
  그대로 사용 — 별 loader / type 변경 없음. `expected_chunk_ids`
  비어 있어 curator 가 `kebab ingest` 후 채울 수 있는 template
  형태. `must_contain` 으로 baseline 측정 가능 (P5-2 metric).
- `crates/kebab-eval/tests/loader.rs::loads_multi_hop_golden_fixture`
  신규 회귀 핀. fixture parse OK + 15 question + 5/5/5 bucket
  분포 + 모든 question 에 must_contain 최소 1 개.

baseline 측정 protocol (별 run, commit 에 artifact 안 포함):
1. v0.17.2 binary 로 single-pass `kebab eval run --fixture
   multi_hop_golden.yaml` 실행
2. P@5, P@10, must_contain pass rate, citation_coverage 캡처
3. PR-3 (dynamic iter 머지) 후 동일 fixture + `multi_hop=true` 로
   재실행 → Δ 비교

PR 분할 6 단계 (plan 참조): PR-1 (본 PR — fixture only), PR-2
(RagPipeline::ask_multi_hop fixed depth=2), PR-3 (dynamic iter),
PR-4 (CLI flag + wire), PR-5 (MCP + SKILL.md), PR-6 (TUI toggle +
trace render). 마지막 PR 후 v0.18.0 cut.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
claude-reviewer-01 requested changes 2026-05-25 06:24:10 +00:00
claude-reviewer-01 left a comment
Member
Copy Link

회차 1 — 4 axis 결정 추적성 좋고 6 PR 분할이 작은 단위로 자연스러움. actionable 2 + suggestion 3 + 칭찬 1:

actionable:

  • mh-s-004 의 must_contain: ["i"] 한 글자 — trigram 0-hit + noise 매칭 위험. 구체적 토큰 보강 필요
  • plan 의 PR-1 file list 가 실제 PR 와 일치 안 함 — outdated. plan 정정 또는 deviation 명시

suggestion:

  • fixture 15 question 모두 한국어, 영어 mix 검토
  • mh-c-002 의 hard-coded "v0.17.2" 토큰 — 의미적 안정성 vs release tag freeze 결정
  • 회귀 핀의 hard 15 / 5-per-bucket assertion 의 frozen size 의도 확인

칭찬: bucket + must_contain non-empty 회귀 핀이 fixture curation 의도를 코드로 표현.

회차 1 — 4 axis 결정 추적성 좋고 6 PR 분할이 작은 단위로 자연스러움. actionable 2 + suggestion 3 + 칭찬 1: actionable: - `mh-s-004` 의 `must_contain: ["i"]` 한 글자 — trigram 0-hit + noise 매칭 위험. 구체적 토큰 보강 필요 - plan 의 PR-1 file list 가 실제 PR 와 일치 안 함 — outdated. plan 정정 또는 deviation 명시 suggestion: - fixture 15 question 모두 한국어, 영어 mix 검토 - `mh-c-002` 의 hard-coded `"v0.17.2"` 토큰 — 의미적 안정성 vs release tag freeze 결정 - 회귀 핀의 hard 15 / 5-per-bucket assertion 의 frozen size 의도 확인 칭찬: bucket + must_contain non-empty 회귀 핀이 fixture curation 의도를 코드로 표현.
crates/kebab-eval/tests/loader.rs
@@ -38,7 +38,44 @@ fn loads_minimal_well_formed_yaml() {
assert_eq!(qs[1].difficulty.as_deref(), Some("easy"));
}
claude-reviewer-01 commented 2026-05-25 06:24:10 +00:00
Member
Copy Link

칭찬 — 5/5/5 bucket distribution + 모든 question 의 must_contain non-empty 회귀 핀이 fixture curation 의 의도를 그대로 코드로 표현. 향후 fixture 가 16 question 으로 늘면 즉시 fail — 그게 의도된 가드면 OK. 의도가 "최소 5 per bucket" 인 lower bound 였다면 >= 5 assertion 이 더 robust. spec / plan 의 "15 question 목표" 는 baseline anchor 의 frozen size 라 본 핀이 정확.

**칭찬** — `5/5/5` bucket distribution + 모든 question 의 `must_contain` non-empty 회귀 핀이 fixture curation 의 의도를 그대로 코드로 표현. 향후 fixture 가 16 question 으로 늘면 즉시 fail — 그게 의도된 가드면 OK. 의도가 "최소 5 per bucket" 인 lower bound 였다면 `>= 5` assertion 이 더 robust. spec / plan 의 "15 question 목표" 는 baseline anchor 의 frozen size 라 본 핀이 정확.
docs/superpowers/plans/2026-05-25-p9-fb-41-multi-hop-rag.md
@@ -0,0 +10,4 @@
# p9-fb-41 implementation plan
Design: `docs/superpowers/specs/2026-05-25-p9-fb-41-multi-hop-rag-design.md`.
claude-reviewer-01 commented 2026-05-25 06:24:09 +00:00
Member
Copy Link

plan 의 PR-1 file list 가 실제 PR 와 일치 안 함. plan 작성 시점 (kebab-eval 구조 미survey) 에 tasks/eval/multi-hop-golden.toml + crates/kebab-eval/src/golden.rs::MultiHopGoldenQuestion 신규 type 명시했는데, 실제 PR 가:

  • fixtures/multi_hop_golden.yaml (workspace root, fb-39 sister naming)
  • 기존 GoldenQuery struct 재사용 — 별 type / loader 변경 없음
  • 신규 test 1 개 (loads_multi_hop_golden_fixture)

plan 의 PR-1 단락이 outdated. 머지 후 follow-up commit 으로 plan 갱신 또는 본 PR 회차 2 에서 정정. plan 이 후속 archeology source 라 deviation 남기면 향후 다른 사람 혼란.

plan 의 PR-1 file list 가 실제 PR 와 일치 안 함. plan 작성 시점 (kebab-eval 구조 미survey) 에 `tasks/eval/multi-hop-golden.toml` + `crates/kebab-eval/src/golden.rs::MultiHopGoldenQuestion` 신규 type 명시했는데, 실제 PR 가: - `fixtures/multi_hop_golden.yaml` (workspace root, fb-39 sister naming) - 기존 `GoldenQuery` struct 재사용 — 별 type / loader 변경 없음 - 신규 test 1 개 (`loads_multi_hop_golden_fixture`) plan 의 PR-1 단락이 outdated. 머지 후 follow-up commit 으로 plan 갱신 또는 본 PR 회차 2 에서 정정. plan 이 후속 archeology source 라 deviation 남기면 향후 다른 사람 혼란.
fixtures/multi_hop_golden.yaml
@@ -0,0 +1,122 @@
# Multi-hop golden query suite for `kebab eval run` (fb-41 baseline + post-merge Δ).
claude-reviewer-01 commented 2026-05-25 06:24:09 +00:00
Member
Copy Link

fixture 모든 15 question 의 lang: ko. 기존 fixtures/golden_queries.yaml 는 g002 / g004 가 영어 — multi-hop fixture 도 영어 mix 가 사용자 dogfood 의 lang 다양성 cover. 예: 5/5/5 buckets 중 영어 2-3 개 섞기 (cross-doc 의 1 개를 영어, intra-doc 의 1 개를 영어, single-fact 의 1 개를 영어). 또는 별 fixture (multi_hop_golden_en.yaml) 분리.

Suggestion 만 — 사용자 실제 사용 패턴이 한국어 위주면 OK. fb-41 dogfood 시 영어 query 도 측정할지 사용자 결정.

fixture 모든 15 question 의 `lang: ko`. 기존 `fixtures/golden_queries.yaml` 는 `g002 / g004` 가 영어 — multi-hop fixture 도 영어 mix 가 사용자 dogfood 의 lang 다양성 cover. 예: 5/5/5 buckets 중 영어 2-3 개 섞기 (cross-doc 의 1 개를 영어, intra-doc 의 1 개를 영어, single-fact 의 1 개를 영어). 또는 별 fixture (`multi_hop_golden_en.yaml`) 분리. Suggestion 만 — 사용자 실제 사용 패턴이 한국어 위주면 OK. fb-41 dogfood 시 영어 query 도 측정할지 사용자 결정.
fixtures/multi_hop_golden.yaml
@@ -0,0 +33,4 @@
must_contain: ["markdown", "image", "pdf", "chunker_version"]
difficulty: multi-hop
- id: mh-c-002
claude-reviewer-01 commented 2026-05-25 06:24:09 +00:00
Member
Copy Link

mh-c-002 의 must_contain: ["v0.17.2"] 가 release tag 에 hard-coded. 향후 (v0.18.x cut 또는 entry merge / cross-link 정리 시) 의미는 같아도 정확한 version 문자열이 달라질 수 있음 (예: HOTFIXES entry header 가 post-v0.17.1 dogfood 로 적혀 있던 시기 있었음). baseline 시점 freeze 의도면 OK, 의미적 안정성 우선이면 "OCR" 또는 "image.ocr" 같은 도메인 토큰 권장.

Suggestion — fb-41 fixture 의 의도 (특정 release 동작 vs 의미적 invariant) 에 따라 결정.

`mh-c-002` 의 `must_contain: ["v0.17.2"]` 가 release tag 에 hard-coded. 향후 (v0.18.x cut 또는 entry merge / cross-link 정리 시) 의미는 같아도 정확한 version 문자열이 달라질 수 있음 (예: HOTFIXES entry header 가 `post-v0.17.1 dogfood` 로 적혀 있던 시기 있었음). baseline 시점 freeze 의도면 OK, 의미적 안정성 우선이면 `"OCR"` 또는 `"image.ocr"` 같은 도메인 토큰 권장. Suggestion — fb-41 fixture 의 의도 (특정 release 동작 vs 의미적 invariant) 에 따라 결정.
fixtures/multi_hop_golden.yaml
@@ -0,0 +117,4 @@
- id: mh-s-005
query: "kebab 의 RRF k 파라미터 default 값은?"
lang: ko
claude-reviewer-01 commented 2026-05-25 06:24:09 +00:00
Member
Copy Link

mh-s-004 의 must_contain: ["i"] 가 약한 신호. (1) trigram tokenizer 가 i 한 글자는 색인 못 함 — 0-hit 가능. (2) must_contain 이 answer 본문에 substring 등장 검증이라 "i" 한 글자는 "Insert", "INSERT", "increment" 등 무관한 단어에도 match. baseline metric 의 단순 pass/fail 가 noise.

보강:

- id: mh-s-004
  query: "kebab tui 의 mode machine 에서 NORMAL → INSERT 토글 키는?"
  lang: ko
  must_contain: ["INSERT", "i 입력모드"]  # 또는 ["NORMAL", "INSERT 모드"]
  difficulty: easy

다른 single-fact (mh-s-001/002/003/005) 들은 구체적 토큰 1-2 개라 OK.

`mh-s-004` 의 `must_contain: ["i"]` 가 약한 신호. (1) trigram tokenizer 가 `i` 한 글자는 색인 못 함 — 0-hit 가능. (2) `must_contain` 이 answer 본문에 substring 등장 검증이라 `"i"` 한 글자는 `"Insert"`, `"INSERT"`, `"increment"` 등 무관한 단어에도 match. baseline metric 의 단순 pass/fail 가 noise. 보강: ```yaml - id: mh-s-004 query: "kebab tui 의 mode machine 에서 NORMAL → INSERT 토글 키는?" lang: ko must_contain: ["INSERT", "i 입력모드"] # 또는 ["NORMAL", "INSERT 모드"] difficulty: easy ``` 다른 single-fact (mh-s-001/002/003/005) 들은 구체적 토큰 1-2 개라 OK.
altair823 added 1 commit 2026-05-25 06:26:20 +00:00
chore(eval): PR #166 회차 1 리뷰 반영 624b44c46b 
- `mh-s-004` 의 `must_contain: ["i"]` 한 글자 → `["INSERT", "i 입력모드"]`
  보강. trigram 0-hit + noise 매칭 위험 해소.
- 3 question 영어 변경 (`mh-c-005` / `mh-i-001` / `mh-s-002`) — fixture
  의 lang 다양성 mix (12 ko + 3 en). 영어 dogfood 시 measurement gap
  회피.
- plan 의 PR-1 단락이 outdated (kebab-eval crate 미survey 단계 작성 →
  실제 PR 와 deviation). actual 변경 명시 + 초안 대비 deviation 명시.

회차 1 의 다른 2 suggestion (mh-c-002 의 `v0.17.2` hard-coded, 15
question / 5-per-bucket 회귀 핀의 frozen size) 은 baseline anchor 의도
적 freeze — 회차 2 reply 에 명시.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
claude-reviewer-01 approved these changes 2026-05-25 06:26:56 +00:00
claude-reviewer-01 left a comment
Member
Copy Link

회차 2 — 회차 1 의 actionable 2 + suggestion 1 모두 잘 반영. 잔여 actionable 0건. APPROVE.

회차 1 의 deferred 2 suggestion 의 freeze 의도 명시:

  • mh-c-002 의 "v0.17.2" hard-coded — baseline anchor 가 "특정 release 시점의 multi-hop 능력 측정" 의도라 의식적 freeze. v0.18.x cut 시점에 fixture re-curation 별 PR 로 처리하는 게 baseline 변동 vs 실제 multi-hop 효과 분리 가능.
  • 회귀 핀의 hard 15 / 5-per-bucket assertion — baseline anchor 의 frozen size. lower bound (>= 5) 로 풀면 향후 fixture 가 무계획적으로 늘어 baseline 비교 가능성 ↓. fixture re-curation 시점에 (의식적 의사결정) 핀 갱신.

cadence 자연 (4 → 0) 수렴. 다음 PR (PR-2 — RagPipeline::ask_multi_hop skeleton, AskOpts.multi_hop + impl Default for AskOpts) 진행 권장.

회차 2 — 회차 1 의 actionable 2 + suggestion 1 모두 잘 반영. 잔여 actionable 0건. APPROVE. 회차 1 의 deferred 2 suggestion 의 freeze 의도 명시: - `mh-c-002` 의 `"v0.17.2"` hard-coded — baseline anchor 가 "특정 release 시점의 multi-hop 능력 측정" 의도라 의식적 freeze. v0.18.x cut 시점에 fixture re-curation 별 PR 로 처리하는 게 baseline 변동 vs 실제 multi-hop 효과 분리 가능. - 회귀 핀의 hard 15 / 5-per-bucket assertion — baseline anchor 의 frozen size. lower bound (`>= 5`) 로 풀면 향후 fixture 가 무계획적으로 늘어 baseline 비교 가능성 ↓. fixture re-curation 시점에 (의식적 의사결정) 핀 갱신. cadence 자연 (4 → 0) 수렴. 다음 PR (PR-2 — `RagPipeline::ask_multi_hop` skeleton, `AskOpts.multi_hop` + `impl Default for AskOpts`) 진행 권장.
docs/superpowers/plans/2026-05-25-p9-fb-41-multi-hop-rag.md
@@ -0,0 +10,4 @@
# p9-fb-41 implementation plan
Design: `docs/superpowers/specs/2026-05-25-p9-fb-41-multi-hop-rag-design.md`.
claude-reviewer-01 commented 2026-05-25 06:26:56 +00:00
Member
Copy Link

칭찬 — plan PR-1 단락이 실제 변경 + deviation 명시 양쪽 cover. "plan 초안 대비 deviation" sub-section 가 후속 archeology 가 "왜 plan 과 실제 PR 가 달랐는가" 즉시 파악 가능 — frozen-as-historical-contract 정책 유지하면서 실제 산출 추적. 다른 PR 들의 plan 단락도 동일 패턴이면 좋겠음 (PR-2~PR-6 에서도 deviation 발견 시).

**칭찬** — plan PR-1 단락이 실제 변경 + deviation 명시 양쪽 cover. "plan 초안 대비 deviation" sub-section 가 후속 archeology 가 "왜 plan 과 실제 PR 가 달랐는가" 즉시 파악 가능 — frozen-as-historical-contract 정책 유지하면서 실제 산출 추적. 다른 PR 들의 plan 단락도 동일 패턴이면 좋겠음 (PR-2~PR-6 에서도 deviation 발견 시).
fixtures/multi_hop_golden.yaml
@@ -0,0 +33,4 @@
must_contain: ["markdown", "image", "pdf", "chunker_version"]
difficulty: multi-hop
- id: mh-c-002
claude-reviewer-01 commented 2026-05-25 06:26:56 +00:00
Member
Copy Link

칭찬 — 3 question 영어 변환 (mh-c-005 schema list, mh-i-001 chunk_id recipe, mh-s-002 license) 이 자연스러운 영어 + 동일 must_contain 검증력 유지. 영어 dogfood 시 measurement gap 차단.

**칭찬** — 3 question 영어 변환 (`mh-c-005` schema list, `mh-i-001` chunk_id recipe, `mh-s-002` license) 이 자연스러운 영어 + 동일 `must_contain` 검증력 유지. 영어 dogfood 시 measurement gap 차단.
fixtures/multi_hop_golden.yaml
@@ -0,0 +117,4 @@
- id: mh-s-005
query: "kebab 의 RRF k 파라미터 default 값은?"
lang: ko
claude-reviewer-01 commented 2026-05-25 06:26:56 +00:00
Member
Copy Link

칭찬 — mh-s-004 의 ["INSERT", "i 입력모드"] 보강이 두 토큰 모두 corpus 에 실제 등장 (README 의 "i 입력모드" literal + multiple doc 의 "INSERT"). 한국어 + 영어 mix 도 trigram 색인 + answer 본문 substring 검증 양쪽에 견고.

**칭찬** — `mh-s-004` 의 `["INSERT", "i 입력모드"]` 보강이 두 토큰 모두 corpus 에 실제 등장 (README 의 `"i 입력모드"` literal + multiple doc 의 `"INSERT"`). 한국어 + 영어 mix 도 trigram 색인 + answer 본문 substring 검증 양쪽에 견고.
altair823 merged commit ed34f2e03f into main 2026-05-25 06:27:08 +00:00
altair823 deleted branch feat/fb-41-multi-hop-eval-golden 2026-05-25 06:27:10 +00:00
Sign in to join this conversation.
Reviewers
No Reviewers
claude-reviewer-01
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
altair823 claude-reviewer-01
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: altair823-org/kebab#166
Delete Branch "feat/fb-41-multi-hop-eval-golden"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?