8月29日、Angela ShiおよびKezhan Shiが「RAG Is Not the Whole Toolkit: The NLP Techniques Real Problems Still Need」と題した記事を公開した。PDFパーサーが「do not redistribute（再配布禁止）」を「document redistribution（文書の再配布）」と誤読した実例、13モデルのベンチマークで「最大のモデルが勝つとは限らない」という結果、そしてほとんどの実務的NLP問題はLLMを呼ぶ前にミリ秒単位で解決できるという主張——本記事はこれらの知見をまとめたシリーズ「ボーナス編」の案内役として機能する。
「とりあえずRAG」が最も高くつく理由
サポートリクエストが届いた。何かが、それが何についての質問かを判定しなければならない。多くのエンジニアの手はLLMへのプロンプトに伸びる。それは動く。だから反射になった。しかしそれは、最も遅く、最も高価で、判断根拠を事後に説明できない方法でもある。
記事が提示するのは「6段のはしご」だ（「はしご」は本記事の整理による表現）。6段あり、最上段がLLM直接推論にあたる。
- 完全一致（リクエストにクリーンな識別子がある場合）
- スペル修正（1文字のミスが回答の妨げになっている場合）
- 専門家が設計した語彙によるキーワード検索
- 埋め込みベクトル検索（語彙でカバーされない表現に対応）
- RAG（文書コーパスからの検索生成）
- LLM直接推論
ほとんどのリクエストはこの下位4段のいずれかでミリ秒単位に解決できる。しかも各手法は「どのルールで判断したか」を明示できる。エンジニアリングとは、ケースを解決できる最も低いはしごを選ぶことだと記事は言う。
ボーナス記事群の構成：なぜRAGだけでは語れないか
この記事はシリーズの「ボーナス編」の案内役を担う。著者らは本編（Volume 1）の執筆中、RAGパイプラインの実装で繰り返し遭遇した問題が、本編の構成を壊さずには収録できないと判断した。それらを4つのカテゴリに整理している。
1. 横断的な実務課題
複数のパイプライン段（レイヤー）にまたがる問題群だ。特に読み応えがあるのが以下の2本。
B01：ノイジーテキスト（タイポ・OCRノイズ）
実務で発生するテキストノイズは大きく3種類に分類できる：ユーザーのタイポ、OCRの文字誤認、そして第三のノイズ（構造崩壊・文字化けなど）だ。Levenshtein距離（2文字列間の編集距離を測る指標）、BKツリー（編集距離を用いた近似文字列検索に特化したデータ構造）、Soundex（英語の発音に基づく音声符号化アルゴリズム）、SymSpellといった40年分の古典的スペル修正技術はこの3種のうちタイポの一つにしか対処しない。OCRノイズと第三のノイズは埋め込みとLLMが吸収する領域になる。記事が提唱する実践的な切り分けは「質問文はコーパス語彙に対してスペル修正、コーパス本体はノイズのまま保持、検索はそのノイズを吸収できる設計にする」というものだ。
B04：PDFの表（テーブル）を平坦化するな
多くのRAGパイプラインが静かに失敗する場所がテーブル処理だ。表を「1行1テキスト」に線形変換する方法は機能しない。理由は次元が交差するからだ（小さい列型テーブル、大きい列型テーブル、混合行テーブル、ヘッダのみ…）。記事が提唱するのは4段階の表現レベルと、5つの直交する診断軸によるテーブル分類だ。ほとんどの表は最もシンプルなレベルのまま処理でき、エスカレーションが必要なものだけコストを払う。
B03：「わかりません」を正当化する
「自信満々の誤答」はバグだが、「根拠のない無回答」もほぼ同じくらい悪い。記事の主張は、パイプラインの4つの各レイヤーがそれぞれ1つの証跡を提供すべきだというものだ。何を解析したか、どの語彙を検索したか、どのページを走査したか、なぜ何も一致しなかったか。これにより「わかりません」が監査可能になる。
B07：型に忠実なモック
「便宜上、戻り値の型を簡略化したモック」は本番バグを隠す。プロジェクト内で実際に発生したインシデントを元に、全てのモックは元のオブジェクトと完全に同じ型を持つべきという原則を提唱する。
2. 代替パイプライン構成
B02ではFAQコーパスを扱う。通常のRAGは「継承した混沌としたコーパス」を前提にするが、FAQでは逆転する。構造化されたエントリのためパースが自明になり、同じ質問が毎日同じFAQ行にヒットするため検索がキャッシュとして機能する。フィードバックループによってコーパスが実際のユーザー質問で育っていく仕組みも紹介される。
B06では、エージェント型のトークン節約策のほとんどが「アーキテクチャ選択の問題を回避するための工夫」に過ぎないと論じる。決定論的ディスパッチャー（各質問を名前付きハンドラにルーティングする構成）を最初から選べば、チャンクサイズのチューニングや多段クエリ書き換えなどのトリックの多くが不要になる。
3. 再現可能なベンチマーク
B05では同じ4レイヤーパイプラインに対し、OpenAI、Anthropic、Mistral、Llama、Phi、Qwenなど13モデルを差し替えてコスト・レイテンシ・信頼性を計測する。結論は「最大のモデルが勝つとは限らない」で、強力なディスパッチャーがあれば$20/Mトークンのモデルと無料の自己ホストモデルの差が縮まることを数字で示す。
B08では同一の合成CV（著作権フリー・再現可能）に対して4種類のPDFパーサーを比較した。結果の一つが強烈で、「do not redistribute（再配布禁止）」を「document redistribution（文書の再配布）」と誤読したパーサーが存在した。意味が正反対になるこの誤読は、パーサーの選定をベンチマークなしに行うリスクを端的に示している。
4. ローカルLLMスタック
クラウドが使えない環境（VNet内、データが外部に出せない環境）向けに、Ollamaを使ったセルフホスト構成を3本の記事で検証する。qwen2.5:7bは最終段のLLM確認ステップで整合したJSON出力を生成したが、qwen3:4bではスキーマが静かに欠落するという「推論モデル特有の落とし穴」も記録されている。現時点の結論は「単一GPUでカスケード全体をローカル実行できる。ただしステージごとに動作確認済みのモデルを使うこと」だ。
エンジニアへの示唆
この記事群が示す核心は、「RAGを使えばいい」という反射的な判断が技術的負債を生む、という点だ。問題を分解し、最も安価に解決できる手法を選び、各段が判断根拠を説明できる状態を保つ——これがエンタープライズ文書処理の設計原則として体系化されている。再現可能なベンチマークと実際のインシデントを根拠にしている点で、ベンダーのホワイトペーパーとは性質が異なる。
詳細はRAG Is Not the Whole Toolkit: The NLP Techniques Real Problems Still Needを参照していただきたい。
