AIP-C01 苦手克服: 1.5 FM拡張のための検索メカニズム設計

作成日: 2026-09-27

このタスクで問われること

試験ガイドのタスク 1.5「Design retrieval mechanisms for FM augmentation」です。出題はほぼ「検索結果の何が悪いか」を症状から読み、チャンキング・検索方式・リランキング・クエリ変換・埋め込みモデルのどのつまみを回すかを選ばせる形です。模試の誤答135問中14問がこのタスクに該当し、全タスク中2位でした。

押さえるべき仕組み

検索の品質は、取り込み時に決まる2つ（チャンキング、埋め込みモデル）と、照会時に決まる3つ（クエリ変換、検索方式、リランキング）で決まります。問題文の症状がどちらの側の問題かを先に切り分けると、選択肢の半分が消えます。

flowchart LR
  subgraph 取り込み時["取り込み時（データソース同期で反映）"]
    A[文書<br/>PDF・HTML・表] --> B[チャンキング<br/>固定・意味・階層]:::knob
    B --> C[埋め込みモデル<br/>言語・次元数]:::knob
    C --> D[ベクトルストア<br/>OpenSearch・pgvector]
  end
  subgraph 照会時["照会時（Retrieve / RetrieveAndGenerate）"]
    E[質問<br/>複合・略語入り] --> F[クエリ変換<br/>分解]:::knob
    F --> G[検索方式<br/>意味・ハイブリッド]:::knob
    G --> H[リランキング<br/>上位N件へ絞る]:::knob
    H --> I[FMで生成<br/>引用つき回答]
  end
  D --> G
  classDef knob fill:#e8f0fe,stroke:#3367d6,stroke-width:2px

色つきの箱＝設定で回すつまみ。誤答の多くは、症状に対してどのつまみを回すかの取り違えです。

階層チャンキングは何をするものか

手順書で「必要な一文は当たるが前後の手順が欠ける」という症状が出たら、階層チャンキングの出番です。小さい子チャンクで検索し、ヒットした子を親チャンクに置き換えてFMへ渡します。そのため numberOfResults は子チャンクの件数として扱われ、同じ親を持つ子はまとめられるので、返る件数は指定より少なくなることがあります。一文に正確に当てつつ、広い文脈を渡すのが階層の役割です。

セマンティックチャンキングと階層チャンキングの境界

セマンティックチャンキングは、隣り合う文の意味の距離で区切りを決めます。話題の切れ目で分かれるので固定サイズより自然ですが、できるチャンクは平坦で、親への置き換えはありません。論文の「方法論→結果→考察」のように、まとまりをまたいで文脈を保ちたい要件なら階層を選びます。組み込みの戦略で表現できない構造（見出しで記事を区切るHTMLなど）だけは、Lambda によるカスタムチャンキングを使います。

ハイブリッド検索は何を補うか

ベクトル検索は意味の近さに強い一方、略語・型番・専門用語の完全一致を取りこぼします。ハイブリッド検索はキーワード検索（BM25）とベクトル検索を1本のクエリで実行し、スコアを統合して両方の弱点を補います。ナレッジベースでは overrideSearchType に HYBRID を指定します。OpenSearch Service を直接使う場合は、ハイブリッドクエリと正規化プロセッサを組み合わせます。

リランキングとクエリ分解の境界

2つは直す症状が違います。リランキングは「関連文書は取れているが順位が低い」ときに、多めに取得した候補を cross-encoder で並べ直して上位N件だけ渡します。クエリ分解は「比較質問の片方がそもそも取れていない」ときに、質問をサブクエリへ分けて別々に検索します。クエリ分解は RetrieveAndGenerate の orchestrationConfiguration で指定する機能で、Retrieve にはありません。

埋め込みモデルは何で選ぶか

多言語の文書は、翻訳せず多言語対応の埋め込みモデルで原語のままベクトル化します。Titan Text Embeddings V2 は100以上の言語で事前学習されており、出力次元を選べます。Titan Multimodal Embeddings は画像検索向けで、テキスト中心の文書には向きません。埋め込みモデルを替えたら、文書側も同じモデルで再取り込みする必要があります。

数値メモ

項目	値
ナレッジベース検索の既定の返却件数	5件
Titan Text Embeddings V2 の出力次元	256 / 512 / 1024（既定 1024）
512次元の精度（1024次元比）	約99%
256次元の精度（1024次元比）	約97%
ナレッジベースでハイブリッド検索が使えるストア	Amazon RDS、OpenSearch Serverless、MongoDB（フィルタ可能なテキストフィールドがある場合）

出典：クエリと応答生成の設定、Titan Text Embeddings V2 の発表

紛らわしいものの比較表

誤答選択肢に繰り返し出てきた手段を並べました。「選ぶ合図」の列を問題文の語句と照らすのが使い方です。

手段	何をするか	何をしないか	選ぶ合図になる語句
固定サイズチャンキング	トークン数と重なり率で機械的に切る	節・手順・表の境界を考慮しない	特になし（誤答側に出ることが多い）
セマンティックチャンキング	意味の切れ目で切る	親子の階層を作らない	話題の境界で分けたい、長さがばらばら
階層チャンキング	子で検索し、親に置き換えて渡す	見出し構造そのものは解析しない	一文に一致させつつ節全体を渡す、方法論から考察まで
カスタムチャンキング（Lambda）	独自ロジックで切る	組み込み戦略より運用が軽いわけではない	組み込みで表せない構造、HTML の見出しで区切る
チャンキングなし	1ファイルを1チャンクにする	検索粒度を細かくしない	事前に自前で分割済みのファイル
ハイブリッド検索	BM25 とベクトルのスコアを統合する	順位の並べ直しはしない	略語・型番・専門用語の取りこぼし
リランキング	取得済み候補を cross-encoder で並べ直す	取れていない文書は拾えない	関連文書が15〜40位に埋もれる、類似度は高いのに的外れ
クエリ分解	複合質問をサブクエリに分けて検索する	1件ずつの順位は変えない	2つを比べる質問、片方しか返らない
取得件数（numberOfResults）を増やす	候補を広げる	クエリベクトルは1つのまま	誤答側。無関係なチャンクも増える
temperature を変える	生成のばらつきを変える	検索結果を一切変えない	誤答側。検索の問題には効かない
ファインチューニング	出力の形式や文体を学ばせる	更新される文書を検索可能にしない	誤答側。「再学習なし」が条件なら即除外
pgvector（Aurora）	SQL とベクトル検索を1つの DB で行う	数億件規模で水平に伸びにくい	50万件未満、メタデータと一緒に検索、サーバーレス
OpenSearch Service	分散 k-NN と全文検索を大規模に行う	小規模ではクラスター運用が過剰	数億件、月間数千万ユーザー、ハイブリッド

あなたの誤答から見える引っかけ

選んだ選択肢の記録が無いため、各問で最も紛らわしい不正解を1つ取り上げています。14問は大きく4つの型に分かれます。

型A：チャンキング戦略の取り違え（5問）

• 4-10 手順の一文に一致させ、節全体を渡したい。「小さいチャンク＋取得件数を増やす」がもっともらしく見えますが、返るのは断片だけです。決め手は「属する節全体をFMへ」で、階層チャンキングです。
• 2-25 論文の方法論・結果・考察をまたぐ質問。「意味の切れ目で切る」セマンティックが自然に見えますが、チャンクは平坦です。決め手は「段落同士の文脈を保つ」で、階層（親1,000・子200）です。
• 3-30 見出しで区切られた長さの不揃いな HTML 記事。組み込みの階層チャンキングが一見正解ですが、平均長で固定したサイズでは不揃いな段落を扱えません。決め手は「記事と段落の関係」と長さのばらつきで、Lambda のカスタムチャンキングです。
• 4-41 検査値の表と説明文が切り離される。Lambda で都度固定サイズに切る案は「自前で制御できる」ように見えますが、表の途中で割れます。決め手は表と説明の対応で、ナレッジベースのコンテキスト認識型チャンキング＋引用です。
• 4-29 コンテキスト長超過と入力の一部無視。「より大きなコンテキストのモデルに替える」が手軽に見えますが、履歴が増えればまた溢れます。決め手は「すべての顧客データを考慮」で、チャンキングで分割処理＋ナレッジベースで関連部分だけ取得の2つです。

型B：検索方式と後段処理の取り違え（4問）

• 1-37 医療略語の取りこぼしと、意味が近いだけの文書の混入。SageMaker でのリランキングは精度改善に見えますが、1段目がベクトルだけなので略語は拾えません。決め手は「完全一致」で、ハイブリッド検索です。
• 4-15 関連文書が15〜40位に埋もれ、FMは10件しか扱えない。Lambda でコサイン類似度を再計算する案は「並べ直し」に見えますが、同じ尺度の計算をやり直すだけです。決め手は「順位が悪い」で、リランカー（50件取得→上位10件）です。
• 3-71 類似度スコアは高いのに要約が的外れ。取得件数を増やす案が見えますが、価値の低い結果が増えるだけです。決め手は「優先順位付けが悪い」で、Rerank API またはナレッジベースのリランキングの2つです。
• 3-14 OpenSearch でハイブリッド検索を組む手順の並べ替え。取り込みパイプライン → 埋め込み作成と自動更新 → ハイブリッド対応のベクトル検索 → FM とプロンプトテンプレート、の順です。データが無いと埋め込めず、埋め込みが無いと検索できない、という依存で覚えます。

型C：クエリ変換の置き場所（2問）

• 4-17 2つの規程を比べる質問で片方しか返らない。Retrieve の vectorSearchConfiguration に分解を指定する案は API 名がもっともらしいですが、そこに変換タイプはありません。決め手は「最終回答を生成」で、RetrieveAndGenerate の orchestrationConfiguration です。
• 2-61 複数論点の複雑な照会を最小運用で。エージェント＋Lambda で分解する案は柔軟に見えますが、コードの運用が増えます。決め手は「最小の運用オーバーヘッド」で、ナレッジベース組み込みのクエリ分解です。

型D：埋め込みモデルとストアの規模感（3問）

• 4-34 英仏独の技術文書。英語へ翻訳してから埋め込む案は一見安全ですが、専門用語の意味がずれます。決め手は「カスタムコード最小」と多言語で、Titan Text Embeddings V2 に原語のまま渡します。
• 2-2 50万件未満の文書で本文とメタデータを検索。OpenSearch の Neural プラグイン案は検索に強く見えますが、この規模ではクラスター運用が過剰です。決め手は件数とメタデータで、Titan Embeddings＋Aurora PostgreSQL Serverless の pgvector です。
• 1-30 2億5,000万件のレビューを500ミリ秒以内に。PostgreSQL に pgvector を足す案は移行が少なく見えますが、この件数と同時アクセスは水平に伸びにくいです。決め手は規模で、OpenSearch Service の k-NN です。2-2 と対で覚えると、ストア選びの境界がつかめます。

判断の手がかり

問題文の語句から、回すつまみを先に決めます。

• 「前後が欠ける」「節全体を渡す」「文脈をまたぐ」 → 階層チャンキング
• 「組み込みでは表せない構造」「HTML の見出し」「長さが極端に不揃い」 → Lambda のカスタムチャンキング
• 「略語」「型番」「完全一致」 → ハイブリッド検索
• 「上位に来ない」「○位に埋もれる」「類似度は高いのに的外れ」 → リランキング
• 「比較」「複数の論点」「片方しか返らない」 → クエリ分解（RetrieveAndGenerate）
• 「多言語」「翻訳せず」 → Titan Text Embeddings V2
• 件数が数十万なら pgvector、数億なら OpenSearch Service
• temperature、取得件数の増加、ファインチューニング、より大きなモデルは、検索の問題では原則として誤答側

解き直す問題

AIP-C01 間違えた問題の解き直しで、次の14問を型ごとに解き直します。

型	問題ID
A チャンキング	4-10、2-25、3-30、4-41、4-29
B 検索方式と後段	1-37、4-15、3-71、3-14
C クエリ変換	4-17、2-61
D 埋め込みとストア	4-34、2-2、1-30

問題IDは「セットID-問題番号」です（セットID：演習1=1、演習2=2、Skill Builder=3、演習3=4）。

---

元ドキュメント: https://claude.ai/code/artifact/576cf81a-c04c-4865-9cab-229e38907c9a