LASSIC Media らしくメディア

2026.07.09 らしくコラム

RAGの精度改善(リランキング・チャンク)を外注

LASSIC IT事業部|元請(プライムベンダー)としてシステム保守・運用を受託

検索精度のイメージ

この記事のポイント

  • RAGの精度改善は、稼働中のシステムでチャンク分割や検索方式を見直す取り組みで、新規構築とは目的が異なります。
  • 検索結果の並び替えにはリランキングモデルが使われ、AWSやAzure、Cohereなどが機能を提供しています。
  • 改善の効果は評価指標で確認しながら進めるものであり、内製と外注の判断もそこから検討できます。

RAGの精度改善とは、検索と生成を段階的に見直す取り組み

ベクトル検索のイメージ

RAGの精度改善とは、稼働中の検索拡張生成(RAG。社内文書などを検索してAIの回答生成に使う仕組み)について、チャンク分割・埋め込みモデル・検索方式・生成条件を段階的に見直し、検索結果の的中率と回答の正確性を高める取り組みを指します*1

図
図:RAGの精度改善は「原因診断→検索改善→生成改善→評価改善」の4段階で進めます。

新規にRAGを構築する取り組みとは目的が異なります。社内文書検索AIの導入など、システムを新たに立ち上げる工程は別稿で扱っており、本稿は「回答が的外れになる」「検索漏れが目立つ」といった、稼働後に浮かぶ課題への改善策に絞って整理します。

改善の第一歩は、検索(Retrieval)段階と生成(Generation)段階のどちらに原因があるかを切り分けることです。チャンクは埋め込みモデルによってベクトル化され、ベクトルインデックスに書き込まれます*1。この変換の精度が検索結果を左右するため、まず検索段階から点検するのが実務的な進め方になります。

的外れな回答が続く2つの原因——検索漏れと文脈の分断

検索段階の原因——チャンクの境界と埋め込みの精度不足

チャンク(文書を検索用に分割した単位)の切り方が文の途中で終わっていると、必要な文脈が別のチャンクに分かれてしまいます。既定のチャンク分割は文の境界を保つよう設計されていますが*1、独自に短いチャンク長を設定した場合は境界がずれることがあります。

埋め込みモデル(テキストを意味の近さで比較できる数値表現に変換するモデル)が専門用語や社内特有の言い回しを十分に学習していない場合も、意味的に近い文書が検索結果の上位に上がらない事態につながります。この場合はチャンク分割よりも埋め込みモデル自体の見直しが優先されます。

生成段階の原因——関連度の低い候補が上位に残る

ベクトル検索やキーワード検索による一次検索は、候補を素早く絞り込む一方、関連度の順位付けは粗くなりがちです。リランキング(検索結果の順序を関連度で並び替える処理)を使わない構成では、関連度の低いチャンクがそのまま生成プロンプトに含まれ、回答の的外れさにつながります*2

リランキングモデルは、クエリとチャンクの関連度を計算して並び替える処理です*2。取得件数を絞りつつ関連度の高い候補だけを残せるため、生成モデルに渡すコストや応答時間を抑える効果も見込めます*2

チャンク分割の最適化——固定長・セマンティック・階層型の選び方

チャンク分割の方式は主に3種類あります*1。固定長チャンキングはトークン数とオーバーラップ率を指定する方式で、既定値は約300トークンで文の境界を保つよう調整されています*1

セマンティックチャンキング(文の意味的なまとまりで分割する方式)は、上限トークン数に加えて、隣接する文をどこまで含めるかの範囲や、分割の境界を決めるしきい値を指定します*1。文脈を保ちやすい一方、追加の計算コストが発生する点に留意が必要です*1

階層型チャンキングは、粒度の異なる親チャンクと子チャンクを組み合わせる方式です*1。検索時は子チャンクで的確に絞り込み、生成時には親チャンクに差し替えて文脈を補います*1。小さいチャンクの検索精度と、生成に必要な文脈量を両立させたい場合の選択肢になります。

方式 特徴 向いているケース
固定長チャンキング トークン数とオーバーラップ率を指定*1。既定値は約300トークンです*1 シンプルな文書構成でまず試したい場合
セマンティックチャンキング 文の意味的なまとまりで分割します*1 文脈のつながりを重視したい長文
階層型チャンキング 親子チャンクを検索と生成で使い分けます*1 検索の的確さと文脈量を両立したい場合

埋め込みモデルとハイブリッド検索——キーワードとベクトルを組み合わせる

埋め込みモデルの見直し

チャンクは埋め込みモデルによってベクトルに変換され、意味的な近さで比較できるようになります*1。専門用語や社内特有の言い回しが多い文書では、汎用モデルでは意味の近さをうまく捉えられない場合があります。埋め込みモデルの変更はベクトルインデックスの再構築を伴うため、影響範囲を確認したうえで計画的に進める必要があります。

ハイブリッド検索——ベクトル検索とキーワード検索を組み合わせる方式

ハイブリッド検索(ベクトル検索とキーワード検索を1回のクエリで組み合わせる方式)は、両方の検索結果をReciprocal Rank Fusion(RRF。複数の順位付け結果を統合する手法)で統合します*6

ベクトル検索はキーワードが一致しなくても意味的に近い文書を見つけられる一方、キーワード検索は製品コードや専門用語、人名のような完全一致が重要な語に強みがあります*6。両方を組み合わせることで、片方だけでは拾えなかった候補を補えます。

リランキングで検索結果を並び替える

リランキングは、一次検索で取得した候補をクエリとの関連度に基づいて並び替える処理です*2。一次検索は速さを優先するため関連度の順位付けが粗くなりがちですが、リランキングモデルを後段に挟むことで上位の精度を高められます*2*8

利用できるサービスは複数あります。Amazon BedrockのRerank APIは、Cohere Rerank 3.5やAmazon Rerank 1.0といったモデルを利用できます*2。Azure AI Searchのsemantic ranker(セマンティックランカー)は、BM25(キーワード検索の代表的な採点方式)やRRFでランク付けした結果を、言語理解モデルでさらに並び替える機能です*7。Cohereは検索基盤を問わずRerank APIを単体でも提供しています*8

いずれの方式でも、一次検索で候補を広めに取得し、リランキングで絞り込むという二段構成が基本になります*8。取得件数と絞り込み後の件数の設計が、回答精度と応答速度のバランスを左右します。

クエリ拡張・書き換えとメタデータフィルタで検索対象を絞る

文書解析のイメージ

クエリの分解・書き換え

複数の論点を含む複雑な質問は、埋め込みに変換する際に意味が薄まり、検索結果がどの論点にも中途半端に合ってしまうことがあります*4。クエリ分解(複雑な質問を複数の単純な質問に分けて、それぞれ検索する手法)は、この課題への対応策です*4

分解した質問はそれぞれ独立に検索され、取得したチャンクをまとめてランク付けしたうえで生成モデルに渡します*4。Azure AI Searchのsemantic rankerにも、誤字の訂正や類義語での言い換えを含め、クエリ候補を10種類まで生成する書き換え機能があります*7

メタデータフィルタ

メタデータフィルタは、文書に付与した属性(部署名・更新日・文書種別など)で検索対象を絞り込む機能です*3。文字列・数値・真偽値・文字列のリストといった型で属性を指定でき、条件に合わない文書をあらかじめ除外できます*3

更新日が古い文書や、対象外の部署の文書が検索結果に混ざる場合は、チャンク分割や埋め込みモデルを見直す前に、メタデータフィルタの設定漏れを確認する方が近道になることもあります。

検索再現率と回答正確性の評価、継続改善のループ

チャンク分割や検索方式を変更しても、効果を測る仕組みがなければ改善したかどうかを確認できません。評価には、検索段階だけを対象にする評価と、検索と生成をまとめて対象にする評価の2種類があります*5

検索段階の評価ではコンテキストの関連度や網羅度(コンテキストの再現率)を指標にします*5。検索と生成をまとめて評価する場合は、回答の正確性・完全性・忠実性(生成内容が検索結果に基づいているか)を指標にします*5。いずれも大規模言語モデルを判定役に使う評価方式が採用されています*5

評価データが乏しいまま変更を重ねると、改善のつもりが精度を落としていても気づけないおそれがあります。想定質問と正解の対応を少数からでも用意し、変更前後で指標を比較する運用に落とし込むことが、継続改善のループを回す前提になります。

内製と外注の分かれ目——改善プロジェクトの進め方

この作業を内製で担うには、複数領域の知識が要ります。埋め込みモデルとベクトルデータベースの運用、リランキングモデルやハイブリッド検索の設定、評価指標の設計、そして変更後の効果を検証する分析力です*1*2*5

専門パートナーに委託する場合は、原因診断から評価設計までを一括して依頼できるかどうかが選定の分かれ目になります。内製では既存の運用担当者が通常業務と並行して対応することになり、評価データの整備や検証に割ける時間が限られる場合があります。

。改善対象のチャンク数や既存ベンダーとの契約形態によって必要な工数は変わってきます。現状の検索精度を診断したうえで、内製・外注の切り分けを検討することが実務的です。

まとめ:RAGの精度改善で押さえる3つの判断軸

本稿ではRAGの精度改善について、公式情報をもとに整理しました。要点は3つに集約できます。第一に、精度改善は新規構築とは異なり、稼働中のRAGで検索段階と生成段階のどちらに原因があるかを切り分ける取り組みです*1。第二に、チャンク分割・埋め込みモデル・ハイブリッド検索・リランキング・クエリ分解・メタデータフィルタが主要な改善手段であり、複数を組み合わせて使うのが一般的です*1*2*6。第三に、評価指標による継続的な検証があってはじめて改善の効果を確認でき、対象規模や工数次第で内製と外注の判断が分かれます*5

LASSICに相談するメリット

LASSIC IT事業部は、AWS・Azureなどのクラウド基盤上で稼働するRAGシステムの保守・運用を元請(プライムベンダー)として受託しています。チャンク分割の再設計から埋め込みモデルの切り替え、リランキング・ハイブリッド検索の導入、評価指標の設計まで、一貫して対応する体制を整えています。既存システムへの影響を抑えながら改善を進めたい企業様は、現状の検索精度診断からご相談いただけます。

よくある質問

RAGの精度改善は、既存のRAGを作り直すことになりますか。

作り直しではなく、チャンク分割や検索方式などの設定変更が中心になります。ただし埋め込みモデルを切り替える場合は、ベクトルインデックスの再構築が必要になります*1。既存の構成を維持したまま調整できる範囲かどうかを、まず確認することが大切です。

チャンク分割のサイズはどの程度が目安になりますか。

明確な正解値はなく、既定のチャンク分割は約300トークンを目安に文の境界を保つよう設計されています*1。文書の性質に応じて、固定長・セマンティック・階層型のいずれかを選ぶことが実務的です*1

リランキングの利用には追加費用がかかりますか。

利用するサービスによって課金方式が異なります。Amazon BedrockのRerank APIやAzure AI Searchのsemantic rankerは、利用量に応じた課金となる場合があります*2*7。導入前に想定する検索件数から費用感を確認しておくとよいでしょう。

評価用のデータがない場合、精度改善は進められますか。

評価データが乏しいまま変更を重ねると、改善の効果を確認できません。まずは想定質問と正解の対応を少数から用意し、変更前後で指標を比較できる状態を整えることが優先されます*5

改善作業を外部に委託する場合、何を確認すればよいですか。

現在のチャンク設定・検索方式・評価方法の棚卸し、改善対象の優先順位付け、評価指標の設計を委託先とすり合わせることが大切です。契約前に、検証環境での確認範囲を明確にしておくと、改善後のトラブルを抑えやすくなります。

著者:テレリモ総研編集部 鈴木 亮佑


ITアウトソーシング・システム開発のご相談はLASSICへ

元請(プライムベンダー)として、貴社の課題に合わせた体制構築・開発支援をご提案します。まずはお気軽にご相談ください。

無料相談はこちら

ご不明な点はお問い合わせフォームからもご連絡いただけます。

  1. *1 出典:AWS「How content chunking works for knowledge bases」(Amazon Bedrock User Guide)(https://docs.aws.amazon.com/bedrock/latest/userguide/kb-chunking.html
  2. *2 出典:AWS「Improve the relevance of query responses with a reranker model in Amazon Bedrock」(Amazon Bedrock User Guide)(https://docs.aws.amazon.com/bedrock/latest/userguide/rerank.html
  3. *3 出典:AWS「Include metadata in a data source to improve knowledge base query」(Amazon Bedrock User Guide)(https://docs.aws.amazon.com/bedrock/latest/userguide/kb-metadata.html
  4. *4 出典:AWS Machine Learning Blog「Amazon Bedrock Knowledge Bases now supports advanced parsing, chunking, and query reformulation giving greater control of accuracy in RAG based applications」(2024年7月10日)(https://aws.amazon.com/blogs/machine-learning/amazon-bedrock-knowledge-bases-now-supports-advanced-parsing-chunking-and-query-reformulation-giving-greater-control-of-accuracy-in-rag-based-applications/
  5. *5 出典:AWS「Evaluate the performance of RAG sources using Amazon Bedrock evaluations」(Amazon Bedrock User Guide)(https://docs.aws.amazon.com/bedrock/latest/userguide/evaluation-kb.html
  6. *6 出典:Microsoft「Hybrid search overview – Azure AI Search」(Microsoft Learn)(https://learn.microsoft.com/en-us/azure/search/hybrid-search-overview
  7. *7 出典:Microsoft「Semantic ranking overview – Azure AI Search」(Microsoft Learn)(https://learn.microsoft.com/en-us/azure/search/semantic-search-overview
  8. *8 出典:Cohere「An Overview of Cohere’s Rerank Model」(Cohere Docs)(https://docs.cohere.com/docs/rerank-overview


View