ノートと資料の関係をローカルLLMに判定させてみた

設計ルールを書いた知識ノートに、その実装やテストを結びつけようとしました。ノートの要約と検索で見つけた資料の抜粋をローカルLLMに渡し、「この資料はノートの設計を実装しているか」「その設計を検証するテストか」を判定させる試作です。

複数の資料をまとめて渡すと、最初のバッチが240秒以内に終わりませんでした。入力や出力を絞り、1件ずつ判定する設定で短い評価ケース9件を試すと、応答はすべて返りました。ただ、調整に使わなかった5件では精度が足りず、自動運用は見送りました。

最初のバッチが240秒で終わらなかった

初期設定では、1回に最大8件の資料を渡せるようにしていました。これを1件ずつ判定する形に変え、ほかの上限も次のように絞りました。中断に備えて、処理済みの項目を記録する仕組みも用意しています。

変更後のモデルはOllamaのqwen3.5:9bで、temperatureは0です。コンテキストはnum_ctx、出力上限はnum_predictで指定し、資料の件数・抜粋の文字数・待ち時間は呼び出し側で管理しました。

変更後の総入力は1回あたり2,264〜2,321文字、550〜563入力トークンでした。資料の抜粋だけでなく、指示文やメタ情報も含む長さです。表の420文字は資料1件の抜粋上限、65Kはモデル側のコンテキスト設定で、実際に65Kトークンを渡したわけではありません。

関係がある例、用語が重なるだけの例、古い内容と現在の内容が食い違う例などを、短い文にした固定ケースで評価しました。検索で得た実資料の全文を9件処理したものではありません。4件を条件調整に使い、設定を固定してから、調整に使っていない5件を判定しました。

調整用の1件は、用語が重なるだけの資料をどう扱うかを見るケースでした。以下は入力を日本語で要約したものです。

既存ノートの要約

処理が中断した後は、永続化された記録を確かめてから再開する。メモリ上の状態だけで成功や再実行の可否を決めない。

判定する資料の要約

同じプロジェクトのメモに同じ用語が出るが、依存関係や実装関係は示していない。

出力には、関係の有無・種類・向き・根拠となる資料のIDなどをJSONで返すようにしました。実際の応答から、一部を抜き出します。

{
  "meaningful": false,
  "relation": null,
  "topical_only": true,
  "outcome": "no_actionable_relationship"
}

このケースでは、話題や用語の重なりは認めつつ、実装関係や依存関係の候補にはしない判定が返りました。

調整用4件と評価用5件はすべて完了し、タイムアウトやJSON形式の崩れはありませんでした。評価用5件の判定時間は中央値14.9秒、95パーセンタイル16.7秒です。5件だけの値なので、処理時間のばらつきを広く示すものではありません。

適合率は検出した関係のうち正しかった割合、再現率は正解の関係を拾えた割合です。評価用ではどちらも採用基準を下回り、関係の種類を取り違えた判定も1件ありました。

初回バッチの入力全文と、実際に渡した資料の件数は特定できていません。変更後には別の短い評価ケースを使っているため、同じ入力に対して何倍速くなったかは、この記録からは出せません。資料件数、文章の長さ、コンテキスト、出力上限、待ち時間も同時に変えたので、どの変更が効いたかは切り分けていません。

繰り返し実行した場合のばらつきは未測定です。要約で省いた内容や曖昧さを含む実資料でも、処理が終わるか、関係を正しく判定できるかは確かめる必要があります。今回の9件だけでは、実運用に十分な品質かは判断できません。

この結果は、過去の試作を単一のローカル環境で評価したものです。当時のハードウェア、OS、Ollamaのバージョン、モデルファイルの正確な識別子は十分に特定できていません。同じモデルタグと設定値でも実行環境が一致するとは限らず、別の環境での速度や精度も未確認です。

9件とも応答は返ってきました。評価用の5件では関係を取り逃し、種類を取り違えた判定もあったので、ノートと資料の関係候補を定期的に作る自動運用は見送りました。