Global Knowledge Distiller

PoC / 日次Window運用

Distillerは、MURASAME Global Knowledgeを探索・拡張する独立したPythonプロジェクトです。ブログの仕様を生成する専用機能ではなく、Seed Topicを差し替えて認証、分散システム、組込み、データ基盤、UI設計などを採掘します。

実行経路

Seed Topic
  → Prompt / Provenance
  → RunPod 48GB級GPU
  → LLM-jp 4 33B Thinking Q4_K_M
  → Raw Generation
  → JSON repair / schema validation
  → Parsed Candidate / Relation / next Topic
  → Global KG pending Proposal

RawとParsedを分けることで、修復前の出力や失敗を捨てません。Job ID、モデル、量子化、Prompt version、親Topic、反復をProvenanceとして残します。

RunPod前提

LLM-jp 4 33B Thinkingの公式GGUF Q4_K_Mを使用する。
48GB級GPUへ載せ、ローカルGPUを品質評価の本線にしない。
llm-jp forkのllama.cppを使い、Thinkingモデルのchat parsing互換を合わせる。
PodはWindowの開始時に起動・再利用し、終了時に停止する。Model cacheは停止Podまたは設定済みVolumeを利用する。
APIキーは環境変数からAPI呼び出しにだけ使い、Job JSON、Raw、Graph、ログへ保存しない。

日次3時間Window

数日観測する場合は、GPUを常時起動せず、1日1回だけ時間制限付きで回します。 SQLiteのTopic Queue、lease、Checkpointがあるため、次回は未処理Topicから再開します。

cd distiller
uv sync
uv run python distill.py window   --topic "分散システムの設計"   --duration 3h   --runpod   --resume   --db data/global-distiller.db   --output-dir data/distiller

systemd Timerで自動化する場合は、リポジトリの distiller/ops/ にあるService、Timer、起動スクリプトを使います。 Windowの完了条件は、推論成功だけではなく、Queueの進捗、Candidate数、Relation数、schema失敗、Bridge成功数を別々に記録することです。

継続処理の内訳(queue / lease / retry / resume)

Window Runnerは放置運用(unattended)を前提に設計されています。処理単位のTopicはSQLiteのQueueで管理され、 lease・再試行・再開のそれぞれが独立して回復します。

クラッシュ後の回収: 次回起動時に starting / running のまま残ったセッションを recovered に閉じ、処理中だったTopicをキューへ戻します。lease期限切れのTopicは、次回起動を待たず他セッションのclaim時にも回収されます。
再試行とbackoff: Topicの失敗は --max-topic-attempts(既定2)まで再試行し、再キュー時は線形backoff(既定60秒×試行回数)で即時再取得を防ぎます。上限を超えたTopicはdead-letter(failed)へ移り、最終エラーを保持します。
割り込みの区別: SIGTERM・Ctrl-Cで中断された処理中Topicは「失敗」ではなく、attemptsを消費しない再キューになります。systemdの通常停止でretry予算が目減りしません。
Graph bridgeの永続再試行: parsed/*.jsonl ごとのimport結果を記録し、失敗したimportは次セッション開始時に自動再試行します(--graph-retry-attempts、既定5回)。KG側は安定IDとProposal重複排除で冪等なため、再試行でGraphが重複しません。
空キュー: --replenish-on-empty でSeedに探索パス番号を付けた新規Topicを投入して継続します。補充しない場合、キューが空のセッションは queue_empty として正常終了(exit code 0)し、翌日のTimerを待ちます。

# queue・lease・dead-letter・Graph bridgeの状態(書き込みなし)
uv run python distill.py status --db data/global-distiller.db
uv run python distill.py status --db data/global-distiller.db --json

systemd timerによる常駐運転

日次Windowはsystemdのuser unitとTimerで運用します。雛形は distiller/ops/ の Service / Timer / 起動スクリプトで、秘密情報(RunPod APIキー等)はunitに埋め込まずEnvironmentFile の参照だけをレンダリングします。

# 1) 事前検証(読み取り専用)
bash ops/check-mvp.sh

# 2) unit / timer のレンダリング確認(ドライラン)
bash ops/install-mvp.sh

# 3) 適用と有効化
bash ops/install-mvp.sh --apply
systemctl --user start murasame-distiller-window.service

SIGTERM・再起動・クラッシュ時は ExecStopPost と次回起動時の回収処理がセッションを確定し、処理中Topicをキューへ戻します。日常の確認は systemctl --user list-timers murasame-distiller-window.timer とdistill.py status です。

Window終了後のhookはowner markerとlock pathnameを回収し、所有者でない呼び出しでは既存Windowのlockを削除しません。 RunPodの停止、DB回復、read-only最終監査までを同じ後始末経路で確認します。

Global KGへの自動Bridge

Parsed JSONL
  → murasame kg import-distiller
  → Concept / Evidence / Domain / Relation / Question
  → pending proposal
  → 人がレビュー
  → approve
  → Global KG confirmed

Parsed JSONLが得られた時点で、Window Runnerは murasame kg import-distiller を呼びます。ただし、取り込み結果は必ず proposed / unverified です。既存のKnowledge CardやVerified Knowledgeへ自動昇格しません。 stable IDで同じCandidateのpending proposalを無制限に重複させない設計です。

bun src/main.tsx kg import-distiller \
  data/distiller/parsed/<job>.jsonl \
  --db data/global-knowledge.db --json

auto-approveの意味

長時間の収集実験では --auto-approve(または MURASAME_DISTILLER_AUTO_APPROVE=1)を指定して、 Graph Proposalの承認まで自動化できます。ただし効く範囲はProposalの承認だけです。

承認されるのは kg_proposals の変更提案であり、Graph Node / Edgeは引き続き proposed / unverified の境界を保ちます(confirmedへの自動昇格ではありません)。
既存Knowledge Cardの cards テーブルへ自動昇格しません。通常ターンへ注入される検索対象が自動増えることもありません。
昇格には引き続きEvidence、評価、人の確認が必要です。既定(off)ではProposalは未承認のまま残ります。

自動進化の意味

探索

Seedと次Topicを継続的に処理する。

蓄積

Raw、Parsed、Provenance、Graph Proposalを残す。

確定

Evidence、評価、人の承認を通したものだけを昇格する。

探索を自動化することと、未検証のLLM出力を真実として共有することは別です。

継続判断のメトリクス

Window数、処理Topic数、Queue残量、Topicの重複率
Candidate数、Relation数、Missing Question数、重複・Conflict数
Raw生成数、schema validation成功率、修復率、推論速度、backend error
Graph Bridge成功数・失敗数、承認数、却下数、Card化後の評価結果
同じ質問への回答品質が、蒸留前後で改善したか

蒸留の継続可否はCandidateの件数だけで決めません。Graphに取り込める品質、重複の少なさ、評価後の利用価値まで追跡します。