■ 1. RLMの定義と本質
- 再帰的言語モデルの位置づけ:
- 最も注目を集めている大規模言語モデルエージェント・アルゴリズム
- 実際のモデルはOpenAIのChatGPTやgpt-ossやDeepSeekなど既存のLLMを使用する
- 再帰とはLLMの呼び出し方を指す
- RLMの本質:
- LLMを一発回答の生成器として使うのではなく複数の推論ステップを持つ手続きとして編成する
- 自己修正しながら目的の成果物へ収束させる
- 重要なのは再帰という言葉の響きよりも実装上の設計原則
■ 2. RLMの3つの構成要素
- オーケストレーターLLMとワーカーLLMの役割分担:
- オーケストレーター: 大局的な戦略を立てる役割でどの資料を読むべきかや抽出すべきスキーマは何かや矛盾が出たらどの観点で再検証するかを担う
- ワーカー: 局所的な作業を担当しこの段落から顧客要望を候補抽出するやこの候補の根拠となる引用箇所を特定するなど粒度の小さいタスクを大量に捌く
- 同じLLMで役割を分担することが可能でgpt-ossは非常によく働く
- 分業が効く理由:
- LLMの失敗が往々にして大局と細部の混線で起きる
- 戦略を考えながら同時に細部を埋めるともっともらしい整合を優先し検証が甘くなる
- 戦略と実務を分けることで作業の責務が明確になり失敗の検知と修正がしやすくなる
- 非自然言語的な中間表現:
- Pythonコードなど機械的に検査可能な表現を途中に置く
- 抽出結果をJSONにしPythonでスキーマ検証を行う
- 重複や欠落や型不一致や相互参照の矛盾をコードで弾く
- 候補の根拠引用が本当に原文に存在するかを文字列一致や範囲照合で検証する
- 中間表現の効果:
- モデルが賢くなったから精度が上がるのではない
- LLMが苦手な厳密さをコードと型と制約で肩代わりしLLMには意味の解釈を担当させる
- LLMを推論エンジンとして使いつつ検証と制約は計算機の得意技に寄せるアーキテクチャ
- 検証から差分修正から再実行のループ:
- 最初の抽出はあくまで暫定解にすぎない
- Pythonで検査してエラーが出たらそのエラーを次の入力条件としてオーケストレーターに返し再度ワーカーにタスクを割り当てる
- やり直しを精神論ではなくプロトコルとして設計する
- プロトコル設計の例:
- フィールドが埋まらない場合は未確定を許す
- 未確定のまま残した理由を分類して残す
- 矛盾が出たら根拠引用を必須にして再抽出する
- モデルがそれっぽい完成品を捏造する余地が減りシステム全体として信頼性が上がる
■ 3. RLMの全体像と従来手法との比較
- RLMの定義:
- 戦略立案担当と局所作業担当に分解する
- Python等で検証可能な中間表現を挟む
- 誤りを差分として回収し再帰ループで収束させる方式
- 従来手法の問題点:
- LLMに抽出させて人間が目視で直す運用がスケールしなかった
- 失敗が最後に露呈し修正が属人的だった
- RLMの優位性:
- 失敗を途中で機械的に検出し修正を自動で次工程に流す
- 非構造化から構造化のような業務で予想以上に効く
- コアの考え方:
- 賢い一発回答ではなく検証可能な中間表現と再実行プロトコルによって正しさへ収束する工程を作る
■ 4. KnowledgeSTATIONでの実装例
- 実装結果:
- RLMによる非構造化データから構造化されたデータを取り出す機能を追加した
- 予想外にうまくいった
- 機能の詳細:
- 過去の著作や議事録や講義録など雑多な情報を貯めた知識ベースに注目するデータと出力して欲しいデータを渡す
- 技術的な話題に注目し技術と発明者とその効果と関連する技術を指定すると自動的にデータを検索して構造化する
- RLMがどのように動作して情報をかき集めまとめているのかという過程も可視化されている
- 間違ったデータが出てきてもどこで間違ったのか理解しやすいメリットがある
- 出力例:
- GPUやELIZAやAlexNetやニューラル機械翻訳やChatGPTなど技術に関する構造化データが抽出された
- トークン上限8000など純粋に技術そのものとは言えないものも出てくるが索引などに引用する場合は納得できる
- 構造化されたデータはExcel形式でダウンロードできる
■ 5. RLMの特徴的なメリット
- 非構造化データのノイズの活用:
- RLMがうまく回り始めると非構造化データのノイズがむしろ追加情報源になる
- 議事録の脱線や雑談や言い淀みや感情的な言葉が優先度の根拠やリスクシグナルとして意味を持つ
- それ今日中にやらないとまずいという一言が期限の強制力を示す
- 顧客が同じ要望を三度言うならそれは単なる繰り返しではなく強い痛みの表現
- RLMは再帰の過程でこうした文脈特徴を拾い上げ構造化スキーマに落とし込める
■ 6. 課題
- 計算コストの増加:
- 再帰はループを回すほどトークンも増え遅延も増える
- 検証関数の設計依存:
- 再帰の品質は何を矛盾とみなすかや根拠は十分かやスキーマ制約を満たすかの設計に依存する
- 情報の欠落:
- ドメインによってはそもそも根拠がテキストに存在しないことがある
- 会議で決まったはずなのに議事録に書かれていない場合などが該当する
- 未確定を無理に埋めず追加の情報取得フローに接続する必要がある
- エージェントは万能の魔法使いではなく情報の欠落を検知して次の行動へつなげる工程管理でもある
■ 7. 今後の展望
- LLM活用の主戦場の変化:
- 文章生成ではなく非構造化データを意思決定可能な構造へ変換することになる
- 人間の組織が抱えるボトルネックは情報の不足ではなく情報の形式
- 見つけられないや比較できないや集計できないや追跡できないという問題がある
- RLMはここに正面から切り込むための基本部品になり得る
- ローカル動作の利点:
- 完全にローカルで動作するという点も見逃せない
- クラウドAIのAPI利用料金や制限に悩まされることなく黙々とデータを構造化していく
- エージェンティックAIの新局面:
- RLMによってエージェンティックAIは新しい局面に到達できる可能性がある