家電マニュアルを知識にする — RAGデータベースの作り方

取扱説明書PDFをベクトル検索できる知識に変換するパイプラインと格納設計

RAGpgvectorベクトル検索チャンク設計ナレッジベース
読了時間: 8分

はじめに

一棟貸しの宿には、洗濯乾燥機、食洗機、オーブン、コーヒーメーカー、バーベキューグリルなど、家庭用とはいえ操作の分かりにくい家電が並びます。取扱説明書は部屋に置いてありますが、100ページのPDFから該当箇所を探すのは大変です。

この記事では、これらの取扱説明書をAIが検索して答えられる知識に変換した仕組みを紹介します。技術的な話が中心ですが、考え方は「本にしおりを挟む」のに近いものです。

PDFを検索できる形にする

なぜそのまま渡せないのか

「PDFをまるごとAIに渡せばいいのでは」と思うかもしれません。しかし取扱説明書は数万文字あり、一度にAIへ渡せる分量を超えています。複数の家電があればなおさらです。

そこで、あらかじめ文書を細かく分割しておき、質問に関係する部分だけを取り出してAIに渡す方式を取りました。

取扱説明書を知識に変えるまで
テキストを抽出

PDFから文章を取り出す。図が多い箇所は画像として読み取る

意味のまとまりで分割

見出しを区切りとして、数百文字ごとのかたまりに分ける

意味を数値に変換

各かたまりを「意味を表す数値の並び」に変換する

データベースに保存

どの家電のどのページかという情報とセットで格納

3番目の「意味を数値に変換」が、検索の肝です。文章の意味を数百個の数値で表現しておくと、「洗濯槽の掃除」と「ドラムのお手入れ」のように言葉が違っても意味が近い文章を見つけられるようになります。

分割の仕方で精度が決まる

分割の粒度は、実際に何度も調整しました。小さすぎると文脈が切れ、大きすぎると関係ない情報まで混ざります。今回は700文字前後を目安に、見出しの区切りを尊重して分けています。

分割で一番苦労したのが、手順の途中で切れてしまう問題でした。

また、目次や索引、保証書のページは検索対象から除外しました。目次は見出しの羅列なので、検索するとどんな質問にも中途半端に一致してしまいます。

安全に関わる記述には印を付ける

「警告」「火災」「やけど」といった言葉を含むかたまりには、安全に関わる内容という印を付けています。回答を作るとき、この印が付いた部分は省略せずに必ず含めるよう指示するためです。

「使い方だけ簡潔に教えて」という質問でも、火傷の危険がある操作なら注意書きは削らない。安全情報は要約の対象にしない、という判断です。

どこに保存するか

既存のデータベースで完結させる

意味を数値化したデータ(ベクトル)の保存には、専用のサービスもあります。しかし今回は、すでに使っているPostgreSQLデータベースの拡張機能(pgvector)を使いました。

「どの家電の説明か」「どのPDFの何ページか」といった情報と、意味のデータを同じ場所に置けるのが大きな利点でした。管理するサービスが1つ減るのも、小規模な運営では効いてきます。

前後のかたまりも一緒に取り出す

検索で見つかったかたまりだけを渡すと、手順の途中から始まる不自然な回答になることがあります。そこで、ヒットしたかたまりの前後1つずつも一緒に取り出すようにしました。

料理のレシピで「3. 10分焼く」だけを見せられても困りますが、前後があれば全体の流れが分かります。

日本語のまま保存し、回答時に翻訳する

4言語対応ですが、知識のデータは日本語のまま1種類だけ保存しています。英語で質問されたら、日本語の資料を検索して、回答するときに英語で答える方式です。

言語ごとに翻訳して保存する案もありましたが、家電が増えるたびに4倍の作業が必要になり、翻訳のずれも生まれます。元データは1つに保つほうが、長期的には管理しやすいと判断しました。

取り込みは手作業で丁寧に

管理画面を作らないという判断

家電の取扱説明書を取り込む機能には、あえて管理画面を作りませんでした。実行用のスクリプトを唯一の登録経路にしています。

家電の入れ替えは年に数回あるかどうかです。そのために管理画面を作り、PDFの解析処理を維持するのは割に合いません。それよりも、取り込み時の文字化け対策や分割の調整を、実行のたびに丁寧に確認するほうが品質が上がります。

何度実行しても同じ結果になるようにする

取り込みスクリプトは、同じ家電に対して何度実行しても結果が変わらないようにしました。実行時にまず既存のデータを削除し、それから新しく登録し直します。

「前回の残骸が混ざる」ことがないので、分割ルールを調整して再実行、という試行錯誤が安心して行えます。

文字化けはデータ側で直す

PDFによっては、特定の文字が化けて取り出されることがあります。これを元のPDFを修正して解決しようとすると、資料としての原本が失われます。

そこで、取り込む過程で文字を置き換える対応表を用意しました。原本は触らず、取り込み時に補正する。後から「元の資料はどうなっていたか」を確認できる状態を保てます。

まとめ

RAGデータベースの構築で押さえたのは、次の3点です。

  1. 分割の質が検索の質を決める — 見出しを尊重し、手順が途中で切れないよう配慮する
  2. 既存のデータベースで完結させる — 小規模なら専用サービスを増やさないほうが管理が楽
  3. 元データは1言語に保つ — 翻訳は回答時に行い、知識の重複管理を避ける