本文へスキップ
事例からの学び

検索精度を決めるのは、検索技術より「知識の持たせ方」だ:教育と製造の2事例

「社内文書をベクトルDBに入れてRAGを作れば、AIが答えてくれる」。この期待は、多くの現場で裏切られてきた。本稿では、本番リリースまで進めた2つの案件をもとに、精度を決めたのが検索方式そのものではなく、「知識をどう分け、どうAIに持たせるか」だったことを紹介する。顧客名は伏せている。

この記事の要点

  • 全文書を一つのベクトルDBに入れる素朴なRAGは、「参照してはいけない知識」を拒めず、図や多言語にも弱い
  • 教育では知識をSkillに分けてAIに選ばせ、製造では検索空間を階層で絞ってから画像と文章を横断して探した
  • 知識を人が読めて直せる形で持たせると、システムは顧客の手で育ち続ける

事例A|大手教育企業:生徒の学年に合わせて解き、解説するAI

課題:中高生向けの学習支援で、問題の解答と解説をAIで生成したい。ただ正しいだけでは足りない。生徒がまだ習っていない概念を使った解説は、正解でも役に立たない。

成功指標:解答の正答率に加えて、「学年に対して適切な説明か」を測る指標を別に置いた。正しさと適切さを分けて測らないと、どちらが足りないのかが見えない。

最初の壁:教科書や参考書を丸ごとベクトルDBに入れた素朴なRAGでは、うまくいかなかった。意味が近ければ上の学年の内容も検索に掛かり、未習の概念が解説に混ざる。図形問題の図は読めず、古文・漢文では精度が落ちた。ベクトル検索は「似ているもの」を探す仕組みであり、「使ってはいけないもの」を除外する仕組みではないからだ。

判断と設計:RAGを万能の仕組みとして扱うのをやめた。学年別のカリキュラムや科目ごとの知識を、それぞれ独立した「Skill」として切り出した。AIは問題文を読み、ツール呼び出し(tool use)で使うべきSkillを自分で選ぶ。参照できる知識がその学年・科目の範囲に絞られるので、未習の概念が構造的に混ざりにくくなる。図形には、画像を読めるモデル(VLM)を組み合わせた。

結果:解答の正答率は83.7%から96.2%、学年適切性の指標は80.5%から93.7%に改善した。本件は複数社が参加したコンペを経て採用され、製品としてリリースされている。

前提条件:期間は約半年、体制は3〜4名。数値は当社の評価セットにおける結果である。

事例B|大手農業機械メーカー:160万ページ超の多言語マニュアル検索

課題:修理の現場で、必要なマニュアルの箇所にすばやくたどり着きたい。マニュアルは160万ページを超え、英語・ドイツ語・イタリア語で書かれている。一方で、現場は日本語で探したい。

最初の壁:壁は3つあった。質問と文書の言語が違うこと。現場とマニュアルで部品の呼び方がずれていること。そして重要な情報の多くが、文章ではなく図面や写真にあることだ。この規模では、似た部品の似たページが大量にあり、意味の近さだけでは正しい箇所が埋もれる。

判断と設計:一つの検索方式ですべてを解こうとせず、役割の違う部品を組み合わせた。

部品役割
階層による絞り込み機種や部位の階層で、先に検索対象を絞る。似た部品の誤ヒットを減らす
OCR図面や画像の中の文字を拾い、検索できる形にする
ローカル翻訳多言語の文書と日本語の質問のあいだをつなぐ
マルチモーダル埋め込み画像と文章を同じベクトル空間に置き、文章の質問から図面を引けるようにする

開発中は、正しい箇所が検索結果の上位に入っているか(ヒット率)を指標にして改善を回した。

結果:本番リリース後、現場の満足度は80%に達した。経験の浅い作業員でも、正しいマニュアル箇所にすばやくたどり着けるようになった。

前提条件:期間は約半年、体制はエンジニア3名とPM1名。難度が高く、ほぼフル稼働だった。

定着の工夫:知識の切り分け(Skill)をマークダウンの文書にし、顧客自身が更新できる形にした。新しい機種や呼び方が増えても、開発者を呼ばずに直せる。

2つの事例に共通する3つの知見

1. 知識の「境界」を設計する。精度を大きく動かしたのは、埋め込みモデルの選定よりも、「この質問で参照してよい知識はどこまでか」を先に決める設計だった。教育では学年と科目、製造では機種と部位がその境界になった。この境界は、技術ではなく業務の理解から決まる。

2. 「正しい」の定義を業務側で決める。教育では「学年に合った説明か」、製造では「現場が正しい箇所にたどり着けるか」だった。この定義がなければ、精度を上げる方向も決められない。

3. 顧客が育てられる形で渡す。知識がコードやベクトルDBの中に埋まっていると、更新のたびに開発が要る。人が読めて直せる形で持たせれば、システムは顧客の手で育ち続ける。

「RAGは終わった」のか

コード生成エージェントがベクトルDBを使わず、ファイル検索(grep)で十分に動くことから、「RAGは終わった」という声もある。私たちの見方は違う。終わったのは、全部を一つのDBに入れて一度だけ検索する雑な作りのRAGだ。いま主流になりつつあるのは、エージェントが検索し、読み、足りなければ別の方式で探し直す「Agentic RAG」である。

場面向いている方式
構造化されたコード。正確な識別子が分かっているファイル検索(grep)
大量の自然文。利用者が正確な言葉を知らない意味検索(ベクトル検索)
図面や写真を含む文書OCR+マルチモーダル埋め込み
参照範囲に業務上の境界があるメタデータによる絞り込み、Skillの選択
コードと技術文書が混在する複数方式の組み合わせ

技術の流行で方式を決めない。業務の場面が方式を決める。それが、私たちが実案件から学んだことだ。