AutoRAG 2.0：検索結果を「司書の回答」に変えるTypeScriptエージェント

検索ツールが返すパス一覧という問題

grepでもベクトル検索でも、返ってくるのはファイルパスと一致行のリストである。そこから先、ファイルを開き、前後の文脈を読み、何が関係あるかを判断し、答えを組み立て、次回のために何が効いたかを覚えておく作業は人間側に残る。READMEはこの状態を「ツールはただ指し示すだけ」と表現している。AutoRAG 2.0が解こうとしているのは、この指し示しと回答の間の落差である。対象読者は、手元にPDF、Wiki、ノート、論文、ナレッジベースが散在していて、その全体に対して「Q3レポートの主要な findings は何だったか」のような問いを投げたい人になる。検索インフラを自分で設計したい人ではなく、検索結果を読む時間を減らしたい人が想定されている。

Piエージェントを司書に組み替えるという設計

AutoRAG 2.0は独自の検索エンジンではなく、Pi（earendil-works/pi-mono）のエージェントループを司書向けに設定したカスタマイズ版だとREADMEは説明している。ループの内容は、候補の取得、ソースファイルの直接読解、証拠の判断、構造化された回答の整理である。ここで重要なのは役割分担の考え方で、AutoRAG自身は検索に特化したエージェントであり、他のモデル役割を統括するコーディネータではない。設定するモデルは1つだけで、そのモデルが取得から整理までのループ全体を所有する。モデルとプロバイダはユーザーが認証済みのランタイムから供給され、AutoRAGは独自のプロバイダ既定値を同梱しない。マルチエージェント構成を前提にしていないぶん、構成要素は少ないが、1つのモデルの能力とレイテンシがそのまま体験の上限になる。

MinSyncとCDCチャンク、RetrievalMethodRegistry

ローカル検索の実体はMinSyncである。MinSyncは1つの共有CDCチャンクライフサイクル上で、字句検索のBM25、意味検索のベクトル、両者を組み合わせたハイブリッドを提供し、RetrievalMethodRegistryを通じて配線される。MinSyncが有効なとき、この3方式は既定で有効になる。ローカルインデックス自体を切るなら"minSync": false、字句検索だけを切るなら"bm25": falseを設定する。MinSyncは初回利用時に検証済みリリースを<workspace>/.autorag/binへ自動インストールし（autoInstall: true）、バイナリを自分で管理する場合にのみ"autoInstall": falseにする。埋め込みはローカルのEmbeddingGemmaをOllama経由で使う構成が示されており、リモート埋め込みエンドポイントはautorag init --embedder-*フラグでminSync.embedderを設定する。ローカル埋め込みのコンテキスト窓が小さい場合はminSync.maxChunkSize（または--minsync-max-chunk-size）を下げる。MinSyncは.autorag配下に解析済みmarkdownミラーを索引する点も見落とせない。検索対象は原本そのものではなく、そのミラーである。

候補提示と本文読解を分ける理由

取得ツールが返せるのは候補パスまでで、同じエージェントが組み込みのbashツールを通じて設定済みソースディレクトリを直接開く。回答はSearchDocumentsResponseとして構造化され、内部マッピングには実ソース（ファイルパスまたはデータソースID）が保持される。この分離はフィードバックと整理のために効く。スコアの正規化と重複排除はResultMergerが担当し、複数の取得方式から出た結果を1つの集合にまとめてから司書が読む。データソース側のアーカイブや索引のライフサイクルは各データソースが持ち、AutoRAGはそれらを移送せずにその場で連携する。READMEが挙げる連携先はkatok、discrawl、qmd、msgvault、rcloneなどで、結果にはkakao:<chat>/<sender>/<chunk>のようなソース固有の識別子が付き、スコープ検査つきでアクセスされる。中央インデックスへの強制取り込みも、第三者サーバーに文書の複製を置くこともしない、というのがここでの主張である。

PDF抽出が薄いときだけ再試行するゲート

既定のPDFパーサは複数ページPDFに対して簡易な品質検査を行う。ローカルのmarkdownが異常に薄い場合、具体的には3ページ以上で、検出ページあたり40文字未満または全体800文字未満のとき、OpenDataLoaderのdocling-fastハイブリッドバックエンドへhybridMode: "auto"、タイムアウト30秒で再試行する。密なPDFは再試行されず、単一ページPDFや画像の第一経路としてハイブリッドが使われることもない。このゲートはパーサ側が所有し、parserOptionsのthinExtractでminPages、minChars、minCharsPerPage、timeoutMs、hybrid、hybridModeを調整できる。READMEに載っているのはnew AutoRAGAgent({ searchPaths: ["/path/to/documents"], parserOptions: { thinExtract: { ... } } })という形の例である。数値が固定の閾値である以上、40文字per pageという線のすぐ上にいるスキャン文書は再試行されずに素通しになる。この境界は自分で測るしかない。

自己進化メモリが意味するものと、その限界

AutoRAGは検索のたびに学習する自己進化メモリを持つと説明されている。どの取得方式がどの種類の問いに効くか、どの文書領域が生産的か、呼び出し側が何を有用と見たか（明示的フィードバック経由）を蓄積する。新品のAutoRAGは何でも試し、使い込んだAutoRAGはどこを見るべきかを知っている、という対比がREADMEの主張である。ただしこれは静的な設定ではなく実利用からの学習であり、学習の質はフィードバックがどれだけ与えられるかに依存する。フィードバックを返さない運用では、この差は生まれない。文書群が頻繁に入れ替わる環境でも、蓄積された「どこを見るか」の知識は陳腐化する。自己進化という語から自動で精度が上がる印象を持ちやすいが、材料はあくまで実際の利用履歴である。

legacy版との関係と、どちらを選ぶかの分岐

このリポジトリが現在ホストするのはAutoRAG 2.0であり、元のPythonベースのAutoRAG（データに対して最適なRAGパイプラインを自動で見つけるRAG AutoMLツール）はlegacy/ディレクトリに移った。legacy版は放棄されておらず、バグ修正、依存更新、pip install AutoRAGによるPyPIリリースが保守モードで続く。既存ユーザーは以前とまったく同じように使い続けられ、issueもこのリポジトリに立てる。新機能開発は2.0系に集中する。つまり両者は競合ではなく、目的が違う。パイプライン構成の自動探索と評価が欲しいならlegacy版、手元の文書群に対する司書的な検索体験が欲しいなら2.0系である。代替として、生のgrepやベクトルDBを自分で組み合わせる構成も依然として成立する。違いは、取得方式の選択と結果の統合と読解を誰が担うかにある。AutoRAG 2.0はそれを1つのモデルのループに寄せ、grep構成はパス一覧を返して人間に読解を残す。

導入時に確認する設定とライセンスの不明点

セットアップの中心はautorag initで、--embedder-*フラグでminSync.embedderを、--minsync-max-chunk-sizeでminSync.maxChunkSizeを指定する。MinSyncのバイナリは初回に<workspace>/.autorag/binへ自動インストールされるため、そのパスへの書き込み権限と、自動インストールを許容するかどうかを先に決めておく。エアギャップ環境やバイナリを自前管理する規約がある場合はautoInstall: falseにして手動配置が必要になる。ライセンスはNOASSERTIONとしか与えられておらず、MITやApache-2.0のような識別子は確認できない。ライセンス条件はリポジトリのライセンスファイルを直接開いて確認する以外に方法がない。ここで法的な判断を代行することはできないが、社内導入の稟議にライセンス識別子が必要なら、この不明点は最初に潰しておくべき項目になる。

編集部の結論

採用を検討すべきなのは、PDFやノート、社内Wikiなど手元の文書群を外部インデックスへ移送せずに検索したい人、そして検索結果のパス一覧ではなく番号付きの整理済み回答を欲しい人である。逆に、RAGパイプラインの自動最適化そのものが目的なら、このリポジトリのlegacy/にあるPython版AutoRAGをpip install AutoRAGで使い続けるべきで、2.0系はその用途の後継ではない。導入前に確認するのは、MinSyncの自動インストール先が<workspace>/.autorag/binになること、minSync.embedderの設定方法、そして既存のCLI所有ストア（katok、discrawl、qmd、msgvault、rcloneなど）が自分の環境に存在するかどうかである。LICENSEはNOASSERTIONとしか情報がなく、ライセンス条件は自分でリポジトリのライセンスファイルを開いて確認する以外にない。

公式情報源

1. Issues
2. Marker-Inc-Korea/AutoRAG on GitHub
3. Project website
4. README
5. Releases