社内ナレッジベースが的外れな回答をする？まずは文書の下ごしらえを

「うちのナレッジベース、何を聞いても的外れな回答ばかり」。そんな相談をよく受ける。多くの人は直感で「モデルが小さいのかな」「もっと高いやつに替えればいいのかな」と思う。実際、より大きなモデルを試し、プロンプトを延ばし、お金をかけても、答えはやはりブレたままだ。

意外かもしれないが、原因はたいていモデル側にない。モデルに文書が渡される「その前」にある。社内の五年分の契約書、サポートチケット、製品マニュアル、スキャンした紙文件——これらを適当なフォルダに放り込み、そのまま「自分で理解して」とLLMに投げたとしよう。読み込まれるのは数十GBの、未整理の原文だ。検索で引っかかるのは、ファイル名やキーワードで硬くマッチした数ページ。出てくる回答が取り違えだらけになるのは当然だ。モデルが賢くないのではない。入れたもの自体が乱れているのだ。

モデルを替えるのは、天井を上げることにはなる。床は上がらない。

ここに見落とされがちなコスト構造がある。文書が庫に入る前の「衛生状態」——容量、形式、機微情報、重複——が、検索品質の上限を決めてしまう。どれほど強いモデルでも、入力が汚れたデータではどうにもならない。業界ではこれをデータ・ハイジーンと呼ぶ。散らかり、大きく、汚れた文書を先に片付けるほうが、後から算力を積むよりずっと安上がりだ。

表層を見ると「モデルがダメだ」となる。しかしよく考えると、根はもっと手前にある。検索の本質的問いは「モデルが賢いか」ではなく、「利用者が本当に求める情報を正確に定位できるか」だ。この第一原理は、あらゆるモデル技巧に先立つ。モデルは最後の工程にすぎない。手前の工程が間違っていれば、どれほど頑張っても救えない。

まともな知識基盤は、生ファイルをモデルに渡さない

知識ベースを本気で作る人は、原文をそのままモデルに渡さない。まず「データエンジニアリング基盤」と呼べる層を通す。文書を圧縮して軽くし、形式をそろえ、機微情報をルールで秘匿化し、検索に適した断片に切り、そして「どこから来たか」を添えて投入する。この一連の流れには、採取、洗浄、分割、ベクトル化、検索、生成という定番の工程がある。どの工程も、最後の回答の出来を左右する。

経験者は、依頼主が求めていない数歩を進んで踏む。たとえば、感覚で「なんとなく精度が上がった気がする」で終わらせず、実際の質問応答ペアを集めた検収セットを用意する。検索品質を数値化できる指標とし、定期的に回帰テストを回し、ある類いの質問が退化したら即座に気づく。長いバッチ処理を走らせる前に、失敗したらどう見えるか、境界はどこかを考えておく。ハイブリッド検索、再順位付け、クエリ書き換え、意味的分割、RAGASのような枠組みでのオフライン評価——これらは公開された常識であり、どこか一家の秘伝ではない。だが一つ一つの工程を再現可能に落とし込むには、基盤そのものを製品として磨く姿勢が要る。

「再現可能」という言葉は、スローガンになりがちだ。ある知識ベースが本当に役立つかは、どう独立して証明できるか。ベンダー独自のデモではない。独立に注釈されたゴールデン質問集合があり、オフライン指標が再現でき、盲検A/Bの結果が安定し、回帰スイートが継続的統合に常駐し、利用者の実使用信号が還流しているか。これらを欠けば、「より正確」は感覚でしかない。

もう一歩手前へ。前処理をブラックボックスにしない

前処理を「観測できる工程」にするのは、最近見過ごされがちな進展だ。数千件の文書を圧縮し、形式を変え、庫に入れる。それが数時間走るあいだ、どの工程で詰まったか、どの一文件がこっそり失敗したか——従来の流れではまるで見えなかった。UglyPear データの直近のRAG基盤はここを一歩進め、文書前処理（圧縮、形式変換などの長時間バッチ）を観測可能な工程とした。進捗が見え、どの工程が遅いか、どの文件が失敗したかを即座に定位でき、必要なら差し戻して再実行できる。つまり、黒い画面を眺めてただ待つ必要はなく、終わってから「最後の三割の文書がそもそも入っていなかった」と気づくこともない。

地味な一歩に見える。だがこれこそが「動く」と「本番で使える」を分ける一線だ。

なぜこれらの工程が本当に効くのか

「なぜ効くか」を説明するほうが、機能リストを並べるより意味がある。

圧縮から始めよう。法務部の契約書一つが数百MBになることは珍しくない。全量をそのまま入庫すれば、蓄積も検索も両方つぶれる。原理はこうだ。文書のなかには大量の重複情報、冗長なオブジェクト、再エンコード可能なメディアがある。これらを用途に応じて再エンコードすれば、容量は通常六〜八割落ちる。その一方で、文字や印章といった重要な情報は保たれる。あなたの得るものはこれだ。同じ検索庫でも、絞ったあとは応答が速く、コストが低く、巨大文件が「モデルに入らない」段階で詰まることもなくなる。

検索についても触れる。ファイル名で「2024年サプライヤー契約」を探し、出てこなければ本当に出てこない。内容の意味で探せば、モデルは「どこと締結したか、何についてか、条項はどこか」を理解できる。これが意味検索とファイル名マッチの世代差だ。見るのは文字ではなく含意である。とはいえ、意味検索がどれほど強くても、入力が汚れれば救えない。手前の洗浄と分割が、意味検索の実力を何割まで引き出せるかを決める。

配置の形にも触れよう。機微文書が恐れるのは、モデルが答えを間違えることより、データが内網を出ることだ。プライベートデプロイ（オンプレミス／エアギャップ）なら、前処理も検索も自社の環境で走らせられる。文書は社内ネットワークを出ない。コンプライアンスの口径は生まれつき綺麗だ。これは「より大きなクラウド上のモデルを買う」という道とは別物だ。一つはデータを出して賢さと交換し、もう一つは賢さを家に置く。

「每文に出所を添える」は、単独で取り上げたい。よくオマケ扱いされるが、実は必須だ。規制業界では、ある回答がどの文件のどの頁を引用したかを示せなければ、監査も責任の所在も取れない。データエンジニアリング基盤は、分割と入庫時に各断片へ溯源マークを打ち、生成時に出所ごと持ち出す。この工程は依頼主の目には「どうでもいい」かもしれないが、経験者は検収の赤線として扱う。コンプライアンスを前置きするとは、文書が庫に入る前にこれらの規矩を立てておくことだ。問題が起きてから補うのではなく。

計算違いしやすいコストもある。前処理を先にしない代償は、一回きりではなく、転がるように増える。検索がどんどん不正確になり、利用者の信頼が落ち、やがて使わなくなる。最初に投入した算力は水の泡だ。逆に、前処理という関を手前でしっかり作れば、あとの一つ一つの問いの品質はより高い床の上に立つ。限界費用はかえって低くなる。これはいくら節約できるかの話ではない。この道が通るか通じないかの話だ。

そのまま放り込むか、基盤で下ごしらえするか

以下の表は「モデルに直接放り込む」と「基盤で前処理を通す」を、測れる次元で並べたものだ。

三つの数字が、なぜ省けないかを語る

なぜ秘匿化が省けないか。IBMの「2025 Cost of a Data Breach」報告にある痛い数字だ。盗まれたデータのうち、顧客の個人識別情報（PII）が53%、従業員の個人情報が37%、知的財産が33%を占める。そして知的財産は1レコードあたりの損失がもっとも高く、178米ドルに達する。知識ベースがこうした項目をそのまま外に出せば、リスクは「あり得る」ではなく「すでに起きている」。

知識労働者の時間の話もある。McKinseyの調査によれば、ナレッジワーカーは勤務週の約19%を、情報の検索と収集に費やしている。検索の床が低いままでは、この19%は減らない。下ごしらえを通した庫は、この無駄を削る土台になる。

蓄積側の圧迫も小さくない。Kompriseの顧客調査によると、企業のプライマリストレージ上のデータの60〜70%が、90日以上アクセスされていない。それでもっとも高価な一次ストレージを占め続けている。知識ベースが絞りと階層化をしなければ、この「冷たいデータ」の塊はますます膨らむだけだ。

今すぐ試す

自社の文書を本当に使える資産にしたいなら、UglyPear データの取り組みを眺めてみてほしい。

• RAG データエンジニアリング基盤とプライベートデプロイの概要：https://www.uglypear.com/ja/products/
• 文書圧縮と形式のそろえ（SmartSlim）：https://www.uglypear.com/ja/products/
• 文件整理と意味検索の実践：https://www.uglypear.com/ja/blog/
• より深い技術解説と導入の考え方：https://www.uglypear.com/ja/

よくある質問

知識ベースが的外れな回答をするのは、モデルを替えるべきか、データを直すべきか

大半はデータの問題だ。どれほど強いモデルでも、入力品質の上限に縛られる。圧縮、洗浄、分割、秘匿化を先に正しく行って初めて、検索品質の上限が上がる。モデル交換は「天井が十分高いか」を解くだけで、基盤は「床が十分安定しているか」を解く。

文書圧縮で印章や重要条項が消えることはないか

ない。圧縮は用途で可逆と非可逆を分ける。文字、印章、図表のような重要情報は保真の経路を通り、冗長なオブジェクトやメディアだけを再エンコードする。ある公開実測では、443ページのOFD文書が約124秒で処理を終え、鮮明さも印章も保たれた。

機微情報の秘匿化は具体的にどう行われ、本文を誤って傷つけないか

氏名、証憑番号、金額、営業秘密などをルールで認識し遮蔽する（計13分類）。動かすべき箇所だけを動かし、本文の意味はできるだけ残す。どの項目を秘匿化するかは、自社のコンプライアンス一覧と合わせて決めるのが望ましい。

プライベートデプロイとクラウド上のモデル直利用、違いはどこか

核心はデータの位置だ。プライベートデプロイは前処理も検索も自社環境で走らせ、文書は内網を出ない。クラウド上のモデルは利用するために内容を外に送る必要がある。契約書、カルテ、財務資料のような文書では、手元に留まるほうがコンプライアンスの口径は綺麗だ。

小さなチームなら文書も少ないのに、基盤が必要か

「多いか」ではなく「乱れているか」で考える。数千件でも構わない。形式が雑で、機微項目を含み、長期保管が要るなら、観測可能な前処理一道でやり直しを大幅に減らせる。文件量が少ないほうが、かえって工程を先に整えやすく、のちに業務の拡大に合わせて広げられる。