L1 & L2AIに「多く語らせる」より「正確に語らせる」

ある顧客が、カスタマーサポートのチャットボットに「このノンフライヤーの保証期間はどれくらいですか？」と聞きました。ボットの答えは「2年です」。ところがアフターサービスの規定には、本体の保証は1年、ヒーター部分だけが2年と書いてあります。答えに使われた言葉はどれも文書の中に見つかるのに、つなげると間違っている。

導入記事で書いたとおり、システムが「答える」だけでよく、タスクの境界がはっきりしていて、3秒以内に返事をしなければならないなら、L1とL2が正解であることが多いものです。ただ、アーキテクチャを正しく選んでも、答えが自動的に正しくなるわけではありません。この記事では、5つの層のうち最初の2つを扱います。

• L1（基礎的なレスポンダー）：LLMは受動的に生成するだけで、流れはすべて外部のコードが制御します。代表的な構成はPrompt + RAG Definition 検索拡張生成（Retrieval-Augmented Generation）。AIが答える前に、指定したナレッジベースから資料を探し、その資料をもとに答えを作る仕組みです。根拠のない作り話をさせないためのものです。 です。
• L2（ルーター・ディスパッチャー）：LLMが意図を見分け、リクエストをあらかじめ決めておいた経路に振り分けます。代表的な構成はIntent Classification + Routerです。

この2つがいちばんつまずきやすいのは、検索が外れること、そしてルーティングが予測できないことです。以下では、まず原因と対策を分けて見て、次に画面の側でどう支えるかを考え、最後にこの2つの天井、つまりL3に進むべきなのはどんなときかを書きます。

正確な定義：L1とL2がすること、しないこと

改善の話に入る前に、2つの層ができることの境界をはっきりさせておきます。ここがずれていると、その後のアーキテクチャの判断も、出発点からずれてしまいます。

L1が担うのは、受動的な生成（Context-based Generation）です。できるのは、与えられたコンテキストの範囲内で答えを作ること。このコンテキストは、モデルが学習で得た知識のこともありますが、企業ではたいてい外部の検索（RAG）から持ってきます。

境界として押さえておきたいのは、L1は業務システムの外部状態を一切変えないということです。データベースに書き込まず、ワークフローを起動せず、副作用のあるAPIも呼びません。L1は読み取り専用の情報処理の層で、できることは「読む、比べる、まとめる、見せる」に限られます。

L2が担うのは、静的なルーティング（Static Routing）です。L1の上に、意図を見分ける層を一枚足したものです。ユーザーの意図を判断し、リクエストをあらかじめ定義した実行経路に振り分けます。経路は固定されています。返品の申し込みならA、配送状況の確認ならB、価格の問い合わせならCのAPIを呼ぶ、という具合です。

L2の計画する力は、静的（Static）です。if-elseの分岐は扱えますが、「途中の結果を見て、次の手順をその場で考える」「実行のやり方をその場で変える」といったことが必要になった時点で、L2は役に立たなくなります。これは実装の欠陥というより、L2がそういう位置づけで設計されているからです。

よくある誤り：層の取り違え

アーキテクチャの改善に入る前に、よく見かける誤りをひとつ先に指摘しておきます。

graph LR
  A[最初はL1で作る] --> B[精度が足りないと気づく]
  B --> C[RAGの改善をひたすら重ねる]
  C --> D[それでも結果が思わしくない]
  D --> E[一気にマルチエージェント（L4）へ飛ぶ]

この流れの問題は、層を飛ばすこと自体より、L1の基本設計がまだ正しくできていないうちに、L1を見限ってしまうことにあります。マルチエージェントを早く入れすぎると、本来ならはっきり見つけられたはずの誤りが、複雑なオーケストレーションの中で大きくなり、しかも見えにくくなります。Anthropicのエンジニアリングチームは、多くの顧客の事例をまとめたうえで、はっきりこう勧めています。問題を解決できるいちばん簡単な方法を見つけ、本当に必要になったときだけ複雑さを足すこと¹。

精度が求められる場面の多くでは、その「いちばん簡単な方法」は、正しく設計されたL1かL2です。それより複雑なAgentシステムは要りません。

L1のアーキテクチャ：検索精度が崩れる3つのパターン

RAGは、L1の中心にある仕組みです。モデルの知識が古くなる問題は解決してくれますが、精度が求められる業務では、3つのところで決まって失敗します。どこに手を入れればよいかは、この3つを理解して初めて分かります。

失敗パターン1：分割が意味のまとまりを壊す

RAGの標準的な流れでは、文書をいくつもの チャンク Definition RAGシステムがナレッジベースを作るときは、長い文書をまず小さな断片に切り分けてからインデックスに入れます。この作業を【チャンク分割】（Chunking）、一つひとつの断片をチャンク（chunk）と呼びます。検索のときにシステムが探すのは、いちばん関係の深いチャンクで、文書をまるごと探すわけではありません。 に切り分け、ベクトル化してインデックスに入れておき、問い合わせのたびに似ているチャンクを取り出してモデルに渡します。問題は「切る」という作業そのものにあります。

テキストを決まったトークン数で切ると、アフターサービス規定のひとつの条項が、いくつかのチャンクに分かれてしまうことがあります。冒頭のノンフライヤーがまさにそうでした。「本体の保証は1年」と「ヒーター部分の保証は2年」が、別々のチャンクに入っていたのです。どちらも単独では正しく、合わせて初めて完全な意味になります。けれどもRAGシステムが取り出す段階で見えているのは断片だけで、チャンクをまたぐこのつながりは見えません。

ある問答システムの比較実験（質問30問）では、ほかの条件を同じにしたRAGの流れで、固定トークンでの分割をAdaptive Chunkingに替えたところ、「少なくとも部分的に正確」な回答の割合が50%から87%に、検索の再現率が0.40から0.88に上がりました²。サンプルは小さいものの、この差が示しているのは、精度が求められる場面では、切り方そのものが結果をはっきり左右する設計判断だということです。適当に決めておけばよい設定項目とは違います。

実際に取れる改善の方向は3つあります。意味の切れ目で切る「セマンティック分割」、文章を一つひとつ独立した「事実の文」に分ける「命題単位の分割」、そして小さな断片の上に章ごとの要約の層を設ける「階層インデックス」です。階層インデックスでは、目次をめくるようにまず章を特定し、それから中身を読み込みます³。

失敗パターン2：業界の言葉づかいとのずれが、ベクトル空間を狂わせる

ベクトル検索は、意味の近い文章ほどベクトル空間の中で近くに置かれる、という考え方で動いています。ただ、この「意味が近い」を決めているのは埋め込み（Embedding）モデルで、ほとんどの汎用の埋め込みモデルは、一般的な文章で学習されています。

ECでいえば、「価格保証」と「配送補償」がその例です。前者は、購入後に値下がりしたときに差額を返す仕組み。後者は、配送会社が、申告された荷物の価格に応じて補償する仕組みです。どちらも「ほしょう」で終わる紛らわしい言葉ですが、意味はまったく違います。汎用のベクトルモデルは、この2つを同じものとして扱いがちです。顧客が「この注文は価格保証の対象になりますか？」と聞いても、システムが取り出すのは配送補償の条項かもしれません。

これは、埋め込みモデルと業務分野のあいだで言葉の意味がずれているために起きる、RAGの構造的な死角です。対策としては、分野のラベル付きデータで埋め込みモデルをファインチューニング（Fine-tune）し、ベクトルの表し方を業務の言葉づかいに近づける方法があります。Prompt Engineering Guideも、専門分野で使う場合は埋め込みモデルのファインチューニングが必要になることがある、と述べています⁴。

失敗パターン3：複数段の推論は、一回の検索では届かない

前の2つは、切り方と埋め込みの質を改善すれば和らげられます。三つ目は、RAGのアーキテクチャそのものの限界にかかわります。

一回の検索だけでは答えられない種類の質問があります。文書や章をまたいで、組み合わせて推論する必要があるものです。たとえば「今年のアフターサービス規定は、去年と比べてどの条項が実質的に変わりましたか？」。

これに答えるには、①去年の該当条項を見つけ、②今年の該当条項を見つけ、③両者の違いを理解し、④その違いが「実質的」かどうかを判断する必要があります。何段階にもつながった推論で、標準的なRAGの一回きりの「検索して生成する」流れでは、構造上こなせません。

この失敗パターンは、記事の終わりでもう一度取り上げます。L1のアーキテクチャの天井に、そのままつながっているからです。

L1の改善策：ハイブリッド検索と、出典をたどれる設計

3つの失敗パターンが分かれば、どこを改善すればよいかも見えてきます。次の2つは、精度が求められる場面で効果が確かめられてきた方向です。ただし、どちらもRAGを置き換えるものではありません。RAGを補って強めるもので、候補をすばやく集める中心の仕組みは、いまもベクトル検索です。

戦略1：ハイブリッド検索（Hybrid Retrieval）

ハイブリッド検索は、性格の違う2つの検索を組み合わせる考え方です。

• キーワード検索 Definition スパース検索とも呼ばれます （BM25）：キーワードが一致するかどうかで探します。昔ながらの検索エンジンに近く、意味の近い文章よりも、同じ言葉を含む文書を見つけます。専門用語や正確な数字（商品の型番やSKU番号など）を取りこぼしにくいのが強みです。
• 密ベクトル検索（Dense Retrieval）：ベクトルの意味の近さで探します。意味は近いのに言い回しがばらばらな質問に強い方法です。

精度が求められる場面で勧められるのは、密ベクトル検索で意味の近い候補をすばやく集め、BM25や構造化されたインデックスで用語や数値を正確に確かめる、という分担です。Anthropicが2024年に行った実験が参考になります。各チャンクに、原文の中でのそのチャンクの文脈を書き足し、そのうえでベクトル検索とBM25を組み合わせると、上位20件の結果に関連する内容が入らない割合は5.7%から2.9%に下がりました。さらにリランキング（並べ替え）を一段加えると、1.9%まで下がりました⁵。ここには「文脈を書き足す」という工程が加わっているので、下がった分をすべてハイブリッド検索の手柄にはできません。それでも、彼らの結論のひとつははっきりしています。ベクトル検索にBM25を加えたほうが、ベクトル検索だけより良い、というものです。

商品の仕様表やアフターサービス規定のような、構造のある長い文書を扱うなら、チャンクの上に階層インデックス（Hierarchical Index）を作る方法もあります。各ノードに内容の要約を持たせ、検索ではまず章を絞り込み、それから中身を正確に読む。断片の中を手探りで探すより、人が文書を読むときのやり方に近いものです³。

戦略2：出典をたどれる設計（Source Traceability）

実際の使われ方を見ていると、見落とされがちなことがあります。ユーザーが知りたいのは答えだけでなく、その答えがどこから来たのかです。

アフターサービス、価格、補償のように、もめごとになりやすい場面では、AIの答えは最初の一歩にすぎません。カスタマーサポートの担当者や顧客は、そのあと元の条項を確かめ、言い回しが正確かを見て、それから採用するかを決めます。システムが答えの一つひとつを文書の章や条項番号にきちんと結びつけられなければ、人が自分で探すしかありません。手間がかかるだけでは済まず、答えが間違っていれば、もめごとの種になります。

だから出典をたどれる設計は、L1システムに最初から必要な条件です。

• 生成した結論には、出典の文書名、章、ページを必ず付ける（できれば段落や表の番号まで）。
• 同じ結論に複数の出典があるときは、出典同士が食い違っていないかを示す。
• 裏付けとなる出典が見つからないときは、推測で埋めずに、生成を断る。

ここで、L1システムは「答えを出すモデル」から、確かめることのできる情報の入り口に変わります。この立ち位置の変化が、ユーザーの信頼を築く最初の一歩です。

L2のアーキテクチャ：ルーティングの確実さをどう作るか

L1が扱うのが「正しい情報をどう見つけるか」だとすれば、L2が扱うのは、正しいリクエストを正しい経路で処理することです。

L2の難しさは「確実さ」にあります。ただ、この言葉は工学的にきちんと定義しておかないと、誤解を招きます。

確実さの3つの側面

• 再現性（Reproducibility）：同じ入力なら、いつ問い合わせても同じ文書やデータソースにたどり着くこと。これを支えるのはインデックスの安定性とバージョン管理で、LLMの側では決まりません。
• ルーティングの一貫性（Routing Consistency）：同じ意図なら、いつも同じ論理経路を通ること。これを支えるのは分類器の安定性と、明示的に書かれたルーティングのルールです。
• 出力の構造化（Output Structuring）：LLMの出力は、 temperature Definition temperatureはLLMの出力のばらつきを調整するパラメータです。0にすると理屈の上ではもっとも確定的な出力になり、1にすると創造的になる一方で不安定にもなります。ただしtemperature=0でも、モデルのバージョンが違えば言い回しが変わることがあります。 を0にしても、モデルのバージョンが変われば揺れることがあります。確実さを生むのは、出力をあらかじめ決めた構造の中に収めること（JSONスキーマ、選択肢の列挙、書式のテンプレートなど。たとえばAIの結論を「はい／いいえ／不明」の3つに限り、自由な文章は出させない）と、その後ろに置くルールによる検証の層です。モデルがいつも一字一句同じ文章を出してくれることに期待しても、確実さは得られません。

L2ルーティングの2層構造

工学的に見ると、L2のルーティングは、並んだ2つの戦略というより、2段のパイプラインです。

1段目は意図分類器（Intent Classifier）です。ユーザーの入力を、あらかじめ決めた意図のカテゴリーに当てはめます。ここでの設計の原則は、軽くて結果のぶれない分類モデルを使い、意図の判断を、回答を生成するのと同じLLMには任せないことです。

分類の粒度は、たとえば次のようになります。

• 自由な問い合わせ（「この2つのノンフライヤーは何が違いますか？」など）→ L1の検索の流れへ
• 決まった形式の照会（「先月の注文を書き出して」など）→ 対応するAPIを直接呼ぶ
• 範囲外のリクエスト（他人の注文の照会など）→ 止めて、ユーザーに確認を促す
• センシティブなリクエスト（補償を求める苦情、身体の安全にかかわる商品の質問など）→ 必ず有人対応に回す

2段目は、分類の結果にもとづくルーティングです。意図の判断が終わってから、経路の実行に入ります。この段の原則は、間違いの許されない業務の経路はハードコード（Hard-coded）したルールで決め、LLMの判断には任せないことです。

たとえば顧客が、商品を安全に使うための説明（電気毛布を一晩中つけっぱなしにしてよいか、など）を聞いてきたら、L2のルーティングは、汎用の検索の流れには入れず、人が確認済みの取扱説明書とアフターサービスの文書に直接向けるべきです。この種の情報には確かな裏付けが求められ、「だいたい合っている」検索結果は許されません。

graph TD
  Input([ユーザーの入力]) --> Classifier[意図分類器]
  Classifier -- "意図のスコア/分類" --> Router[ルーティングのルール層]
  
  Router -- "A" --> L1[L1の検索フローを呼ぶ]
  Router -- "B" --> API[APIを直接呼ぶ]
  Router -- "C" --> Audit[人による審査の待ち行列へ]
  Router -- "拒否" --> Reject[ユーザーに情報の追加を求める案内を返す]

答えないこと：いちばん過小評価されている能力

L2の制御でいちばん効くのは、「どう答えるか」を決めることより、いつ答えないかを決めることです。

研究の世界では、この能力を「Abstention」（回答の差し控え）と呼びます。Wenらは、TACLに掲載した、LLMの回答の差し控えに関する体系的なサーベイの中で、これを「LLMが答えを出すのを断る振る舞い」と定義し、ハルシネーションを減らし安全性を高める可能性があるとしています⁶。返金、補償、商品の安全といった問題では、自信過剰の間違った答えのほうが、「お答えできません」の一言よりはるかに高くつくことが多いのです。

工学的には、L2の断る力は、次の3つを重ねて作れます。

一つ目は、ルールによる遮断（Rule-based Blocking）です。はっきり分かっている境界の条件をハードコードします。たとえば質問が他人の注文にかかわるときや、データがカバーしていない期間を対象にしているときは、その場で止め、決まった案内文を返します（「このシステムで照会できるのは直近12か月の注文です。ご指定の期間は対象外のため、期間をご確認ください」）。

これはいちばん確実で、コストもいちばん低い断り方です。ルールで書き尽くせる境界には、これが合っています。

二つ目は、検索の信頼度のしきい値（Retrieval Score Threshold）です。RAGの流れでは、検索のたびに類似度スコア（Similarity Score）が出ます。いちばんスコアの高い結果でも設定したしきい値に届かないなら、システムは信頼できる裏付けを見つけられなかったということです。そのときは、質の低い検索結果で無理に答えをこしらえず、生成を断るべきです。

retrieval_results = retrieve(query)
if retrieval_results[0].score < CONFIDENCE_THRESHOLD:
    return "ナレッジベースに、このご質問に直接関係する資料が見つかりませんでした。
            ご質問の内容をご確認いただくか、有人サポートにお問い合わせください"
else:
    return generate(query, retrieval_results)

三つ目は、境界を見分ける分類器（「この質問はシステムの対応範囲を超えている」と見分けるためのもの）です。ルールでは書き尽くせないものの、意味から見分けられる境界のリクエストには、「この質問はシステムの対応範囲の内側か」を判断する専用の分類器を訓練します。モデルそのものに制約をかける手もあります。IBMの実験では、範囲外の質問の例が十分に多様なら、モデルを教師ありファインチューニング（SFT）するのがもっとも効果的で、例の多様性が限られるときは、モデル内部の表現のレベルで止めるCircuit Breakersという方法がよく効き、両方を重ねると多くの場合どちらの利点も得られる、と報告されています⁷。

UI/UX：入力を絞り、不確実さの出どころを減らす

アーキテクチャで作った確実さは、画面の操作の設計で支える必要があります。技術に詳しくない業務の担当者にとって、UIの役目は入力のあいまいさを減らすことです。システムにユーザーの意図を当てさせるより、画面のほうでユーザーが意図をはっきり伝えられるように導くほうが確実です。

実際に取り入れやすい設計のパターンを3つ挙げます。

パターン1：意図に応じたフォーム型の対話

意図分類器が、「返品の申し込み」「領収書の発行」のように、型の決まった意図を見分けたときに使います。

システムのほうから入力欄を出し、ユーザーには文章を書いてもらうかわりに、注文、返品の理由、返金の方法をプルダウンから選んでもらいます。

フォームの各項目は、ルーティングのルールにあるパラメータの枠（スロット、Slot）にそのまま対応します。ユーザーがフォームを送信した時点で、意図の判断とパラメータの取り出しは終わっています。バックエンドはそのままL1の検索かAPIの呼び出しに進めばよく、LLMに意図を推測させる段階を通す必要はありません。

向いているのは、タスクの形がほぼ決まっていて、ユーザーの多くが技術に詳しくなく、システムが決まったパラメータの範囲内で動けばよい場面です。

パターン2：業界用語のファセット型ガイド（Faceted Search Guidance）

ユーザーが自由に文章を打ち始めたら、システムはその場で、関係しそうな用語の種類を見分けます。

入力欄の横に用語の候補を出し、入力の途中で標準の用語を選んでもらいます。表記の揺れた、標準から外れた言い方のまま送られてくるのを防ぐためです。

用語のそろった入力なら、意図分類器が迷う余地は大きく減り、L1の検索段階でのベクトル検索の精度も上がります（標準の用語は、自由な言い回しよりもベクトルの表し方が安定しているからです）。

向いているのは、用語や番号が多く（商品の型番、SKU、アフターサービス規定の条項番号など）、標準の言い方がどこまで身についているかがユーザーによってまちまちな場面です。

パターン3：断るときの設計（Refusal UX）

システムが答えないと決めたとき、それをユーザーにどう見せるかで、ユーザーがシステムをどこまで信頼するかが変わります。

まずいのは、「お答えできません」とだけ表示して、次に何をすればよいかを示さないことです。

断るときの応答には、3つの要素が要ります。①断る理由をはっきり言う（あいまいな「お答えできません」の代わりに、「この照会は、現在のデータの対象範囲を超えています」と書く）。②入力を直すように導く（「直近12か月以内の注文を選ぶか、下の質問の種類からひとつ選んでください」）。③人に引き継ぐ道を用意する（「お手伝いが必要な場合は、有人サポートにご連絡ください」）。

この設計の考え方はこうです。断ることは、失敗と同じではありません。自分の境界を正しく見分けられるシステムであること自体が、信頼できることの証になります。

L1/L2の天井：この2つでは解けない3種類の問題

ここまでの改善策は、どれもL1とL2のアーキテクチャの枠内での話です。けれども、L1やL2の設計をどれほど作り込んでも、構造的に失敗してしまう業務の場面が3種類あります。実装の出来の問題とは違い、層の定義そのものが持つ境界です。

この3つを理解しておくことが、「L3を入れる必要があるか」を判断するよりどころになります。

天井1：マルチホップ推論（Multi-hop Reasoning）

運営担当者がこう尋ねます。「今年のアフターサービス規定は、去年と比べてどの条項が変わりましたか？　うちの家電カテゴリーにはどう影響しますか？」

L1がつまずくのは、複数の文書と2つの年度をまたいで、比べながら推論する必要があるからです。まず両年度の該当条項を探し、違いを比べ、その違いがどれほど「実質的」かを判断し、さらに具体的なカテゴリーに当てはめる。少なくとも4つの推論の段階がつながったタスクです。

標準的なRAGの「一回検索して一回生成する」流れは、構造上、検索も生成も一回しかできません。途中の段階の出力をもとにもう一度検索することも、問題を小さな問いに分けて順に解くこともできません。RAGFlowのエンジニアリングの報告も、「マルチホップの質問」はRAGシステムで意味のギャップがはっきり出る典型的な場面のひとつで、従来の検索手法ではこうした場面での効果が限られる、と指摘しています⁸。

必要なのは、問題をサブタスクに分け、繰り返し実行する能力です。これはL3（ツール実行者）が担う能力です。

天井2：動的な計画（Dynamic Planning）

運営担当者が、ひとつの商品を3つの国のサイトに同時に出品しようとしています。国ごとにラベル、認証、返品の要件が違い、しかも互いに絡み合っています。ある国のために包装を変えると、別の国の認証に影響が出るかもしれません。

L2がつまずくのは、このタスクの処理の経路を前もって固定できないからです。システムはまず3か国の基本的な要件を把握し、それらがぶつかる点を見つけ、そのぶつかる点をもとに、次に何を調べるかを決める必要があります。言い換えれば、「N番目の手順で何をするか」が「N−1番目の手順の結果」で決まる。これはまさに、L2のハードコードされたルーティングでは扱えない、動的な計画が必要な場面です。

L2は「出品の問い合わせならAの経路へ」という静的なロジックは扱えますが、「検索結果を見てから、AとBのどちらへ進むかを決める」という動的なロジックは扱えません。

必要なのは、実行の途中で、途中の結果をもとにその後の手順を組み直す能力です。これもL3が担う能力です。

天井3：システムをまたぐ状態の調整（Cross-system State Management）

運営担当者が、あるセールの価格変更を、商品システム、会員システム、カスタマーサポートのナレッジベースの3か所に反映させたいとします。

L1とL2がつまずくのは、先に書いたとおり、L1は「業務システムの外部状態を変えない」と定義され、L2の実行経路はあらかじめ決められているからです。複数の外部システムを調整し、システム間の整合性を保ち、各システムの応答を見ながら次の操作をその場で決めるようなタスクは、どちらにも扱えません。

この種の場面では、外部のツールを呼び出すだけでは足りません。いくつかのツールのあいだで状態を保ち、部分的な失敗（たとえば商品システムは更新できたのに、カスタマーサポートのナレッジベースはタイムアウトして更新されなかった）に対処する必要があります。これらはL3（ツール実行者）が引き受ける問題です。複数のシステムをまたぐだけなら、まだL4は要りません。

この3つを並べると、L1とL2の限界がはっきりします。手順をまたいだ動的な推論、システムをまたいだ状態の調整、途中の結果にもとづく経路の組み直し。タスクにこのどれかが必要になったところで、L1とL2のアーキテクチャでは対応しきれなくなります。 L3が必要になる理由もここにあります。次回で詳しく見ていきます。

ビジネスの判断：いつL1/L2にとどまり、いつ上に進むか

実際の業務の判断では、次の目安が、いまの場面にL1/L2を超えるものが必要かどうかを見極める助けになります。

次の条件がすべて当てはまるなら、L1/L2が正しい選択です。

• タスクに、はっきりした正解・不正解の基準がある（主観的な判断に頼らない）
• システムは情報を出すだけでよく、外部システムの状態を変える必要がない
• 一回ごとの照会が独立していて、手順をまたいで途中の結果を積み上げる必要がない
• 3秒以内に応答する必要がある

次の兆しがひとつでも出てきたら、L3を入れるかどうかを真剣に検討すべきです。

• ユーザーの質問に答えるには、複数の文書を組み合わせて推論する必要がある
• 1回目の検索結果を見て、2回目に何を調べるかを決める必要がある
• 有効な答えを出すには、外部のAPIを呼び、その戻り値を見て判断する必要がある
• 「考えてから、もう一度考える」必要のある複雑な場面がある（答えを自分で検証するなど）

精度の問題は、モデルの大きさより先に、検索の経路で解決すべきです。 L1の答えが正確でないなら、最初にやるべきことは、チャンク分割の方針、埋め込みの質、検索で取り出すロジックを見直すことです。もっと大きなモデルに替えたり、いきなりL3に飛んだりするのは、その後の話です。

おわりに：多く語るより、正確に語る

冒頭のノンフライヤーに戻ります。ボットが「2年」と答えた原因は、モデルの外にありました。2つの条項が切り離され、検索がその2つをそろえて取り出せず、システムも出典を添えて人が確かめられるようにしていなかった。L1とL2の手間の多くは、こうしたところにかかります。正しく切り、正しく探し、出典を示し、断るべきときには断ることです。

こうして作ったシステムは、あまり賢そうには見えません。それでも振る舞いが安定していて境界がはっきりしているので、ユーザーは毎回その答えを確かめなくてすみます。出典のある答えを返すたびに信頼が少しずつ積み上がり、根拠のないまま無理に答えるたびに、それが削られていきます。

予測できるということは、境界があるということでもあります。問題をいくつかの手順に分ける必要があるとき、次の手順が前の手順の結果で決まるとき、あるいは実際にいくつかのシステムを書き換える必要があるとき、L1とL2では受け止めきれません。次回は、次に何をするかをモデルが決めるようになる層、L3について書きます。