agentic search five phase refactor - Liplus-Project/liplus-language GitHub Wiki
agentic-search 5-phase refactor — skill encapsulation と内部知識の比較基線化
判断
retrieval orchestration を 5 段階で再編する。中核の構造判断は次の 3 点。
- 内部知識の役割 =
fallback(外部が無理なら内部で答える)からcomparison baseline (比較基線)(外部 source と差分照合する物差し)へ再配置。 - 外側構造 = 単一
agentic-searchskill にカプセル化。Phase 3 で task-research-strategy / task-retrieval-orchestration / model-web-search-judgment の retrieval 責務をこの skill に集約する。 - 内側プロトコル = Tier 1(内部仮説 + 外部 1 件下見)/ Tier 2(不一致が出た時のみ多角度展開)。Phase 2 で導入。
phase 構成は Phase 1(merge 済)→ Phase 2-4 を観測を挟みながら順次 → Phase 5 で既存 evolution-loop 運用に統合(calibration 専用 skill は新設しない)。
背景
Phase 1 の merge (PR #1223) で内部知識を「fallback (劣化代替)」から「comparison baseline (比較の物差し)」へ再配置した。これは局所修正でなく、retrieval 全体の再編の起点として設計されている。
並行して、業界の agentic-search pattern(Self-RAG / CRAG / Adaptive RAG / ReAct / 階層型 retriever)と既存 Li+ skill 群(task-research-strategy / task-retrieval-orchestration / model-web-search-judgment)が独立に同領域へ到達していたことを cross-check で確認した。両者の収束点 = 「内部知識を比較基線として置き、外部 source との不一致を anomaly 信号として展開する」アーキテクチャ。
agentic capability は base-model 側に飲み込まれていく方向 (deep research / web search 機能の組込み化) のため、Li+ spec 側に残すべき責務は次の 4 点に純化される:
- governance(権威の階層 = 一次情報 > spec literal > 観測 > 推論)
- mode gate(質問 / 作業 mode の分離による retrieval 規律)
- 消費規律(multi-angle parallel retrieve、cross-check 三状態分岐)
- skill 呼び出し条件(いつ agentic-search を起動するか)
retrieval 実行手順そのものは base-model に委ねる方向に再構成する。
制約
- Phase 1 は merge 済。後段の Phase 2-5 はこの基盤を前提に成立する。
- 既存 skill(
task-research-strategy/task-retrieval-orchestration/model-web-search-judgment)の責務再分配は Phase 3 で行う。Phase 3 完了までは現行 3 skill 並走運用を維持する。 - Phase 5 は新 skill 新設でなく既存
evolution-loopへの統合に倒す(skill 数を抑える設計判断)。
結論
採用案 = 5 phase の段階的再編 + 内部知識の comparison baseline 役割再定義 + 単一 agentic-search skill への外側集約。
却下案 1 = 内部知識を完全に捨てて「外部 source 一択」に倒す案。 理由: 内部知識を比較基線として残すことで、freshness 判定 algorithm への依存が dissolve する。古びた内部知識でも anomaly detector として機能する設計が成立する(fresh / stale 二値判定を spec で持たなくてよい)。
却下案 2 = retrieval 手順を spec 側に詳細記述し続ける案。 理由: agentic capability が base-model に飲み込まれていく方向で、retrieval 実行手順を spec 化し続けると base-model 進化に追随する保守コストが累積する。spec 側は governance + 消費規律 + mode gate + 呼び出し条件の 4 点に純化する方が長期で安定する。
却下案 3 = Phase 5 で calibration 専用 skill を新設する案。 理由: calibration は既存 evolution-loop の observe → evaluate → distill → reflect → improve の枠で扱える。新 skill 新設は skill 数のインフレを招く。
運用上の観測(Phase 1 merge より)
gh issue develop {parent} で作成した branch を sub-issue 単位で merge すると、branch ↔ issue リンク経由で GitHub が parent issue まで auto-close する。Phase 1 では merge 直後に gh issue reopen 1217 で復旧した。
Phase 2-5 で同じ pattern を踏む可能性が高い。ops 側で次のいずれかの構造判断がいずれ必要:
- sub-issue 専用 branch を切る運用に倒す
- parent issue は merge 後に reopen する前提を ops 仕様に明示する
本判断構造の射程外(rules/operations/operations.md 側で扱う)として、観測としてのみ記録する。
関連
- 親 issue: #1217 Agentic search refactor: skill-encapsulated + tiered comparison architecture(open)
- sub-issues:
- #1218 Phase 1: Replace internal knowledge role with comparison baseline(closed)
- #1219 Phase 2: Stage Block 2 into Tier 1 preview + Tier 2 deep-dive(open)
- #1220 Phase 3: Encapsulate retrieval orchestration into agentic-search skill(open)
- #1221 Phase 4: Add mode gate (question/work) and domain tagging(open)
- #1222 Phase 5: Calibration via existing evolution-loop operations(open)
- Phase 1 PR: #1223 skills(retrieval): Phase 1 - internal as comparison baseline(merged)
- Phase 1 merge commit:
5c8fac5 - 影響を受ける skill 群:
メンテナンス
この判断記録は、以下の場合に削除する:
- Phase 2-5 が全て完了し、再編後の retrieval architecture が requirements spec(docs/3.-Task.md 等)に統合された時
- agentic-search skill 案が採用されず、別アーキテクチャへ pivot した時(その場合 supersede リンク付きで新エントリを作る)
- base-model 側の agentic capability 進化により、本判断の前提(spec 側を governance + 消費規律に純化する設計)が無効化された時