ローカルLLMで年鑑EPUBを安全・正確に分析するシステムを作って学んだこと
きっかけ
手元にある各種数値辞典データを、自分の PC 内（完全ローカル環境）だけで質問・分析に使いたいと考えました。
満たしたかった条件は、次の2点です。
- 本文やデータを外部に一切送信しないこと
- 提示される出典と数値が常に正確であること
学んだこと
- 出典の正確さ 単に検索がうまくヒットするだけでは不十分でした。原文の位置（CFI）、印刷版のページ番号、観測年、単位、さらには表の脚注に至るまで、データ側で厳密に保持しておく必要があります。
- 数値の扱い（LLM に計算させない） 数値の計算は LLM に任せず、SQL などで直接計算した値を原文と自動照合する仕組みにしました。こうすることで初めて、データの食い違いに気づくことができました。
- 事前評価の大切さ 開発初期に 57 問の評価セットを用意したことで、修正による改善や精度の後退をすぐに検知できました。なお、LLM には出力のばらつきがあるため、「1回全問正解した」だけでは精度の保証にはならない点にも注意が必要です。
- 処理速度のボトルネック GPU（Vulkan）を用いて検索処理そのものを高速化するよりも、SQL テンプレートの活用や出典の直接紐付けによって「LLM を呼び出す回数自体を減らす」アプローチのほうが、はるかに高い効果を得られました。
自分なりの理解
LLM アプリケーションの信頼性は、モデル自体の賢さよりも、それを取り巻く仕組み（アーキテクチャ） で決まると感じています。
LLM の役割は「取得した原文と計算済みの値を、自然な言葉にまとめること」だけに絞るのが賢明です。事実の参照元や数値計算といったクリティカルな部分は、プログラム側で検証可能な領域に留めておきます。この切り分けができていれば、出力に誤りがあった際も「どこで問題が起きたのか」を正確に追跡できます。
実践へのつなげ方
今回の学びから、今後の開発や業務では以下を徹底していこうと考えています。
- 社内文書や論文を扱う際：LLM で回答を生成するときは、引用元の正確な位置と計算プロセスのログを必ず残す。
- 改善に着手する前：少数であっても、まずは基準となる評価セットを作成する。
- 高速化を行う際：勘に頼らず、各プロセスの所要時間を計測してからボトルネックに手を入れる。
次に試すこと
まずは v1.0 を日常的に使ってみます。その中でうまく答えられなかった質問をメモしておき、順次評価セットへ追加していく予定です。