「うちの会社、去年はいくら儲かった？」
自分のチームが作ったナレッジベースに、そう大白话で訊いてみたことがあるだろうか。
試した人は少なくない。返ってくるのは答えではなく、どこかそれた抜粋の山だったり、まるで別の部署の話を始めたりする。驚くべきことに、それは手前の「検索」が正しい段落をすくい上げていないからだ。モデルがどれほど流暢でも、間違ったネタを渡せば、偉そうに嘘を並べるだけになる。
UglyPear Data が RAG データエンジニアリング基盤を手がけてきた感触では、一つのことがだんだん明確になってきた。私有化ナレッジベースの要は検索にある。以下、その理由を順を追わずに、ばらばらに書き留める。
数字が教えてくれる重い現実
企業の NAS データの 6〜7 割は、90 日以上まったく触られていない状態のまま、高価なプライマリストレージに置かれ続けている。これは Komprise の調査が示す数字だ。要するに、多くの組織は使われていない資料を、いちばん高い場所に眠らせている。
知識労働者の週のおよそ 19%、日換算で約 1.5 時間が、情報の検索と収集だけに費やされているという推計がある。出典は McKinsey だ。1.5 時間というと小さく聞こえるかもしれない。だがそれは毎日、本題に入る前に消える時間である。
Asana の「Anatomy of Work」調査が別の側面を出している。仕事の中断から再開・集中までに平均 23 分かかり、1 日あたり約 35 のアプリを行き来しているという。検索に失敗して別のツールを開き、また戻る。そのたびに 23 分のロスが積み重なる。
三つの数字を並べると、輪郭が見えてくる。資料は増えるのに、目的の一文にたどり着くコストは下がらない。増やすことと、引き出せることとは別の問題だ。
意味検索が解くもの
キーワード検索が見るのは「字面が一致するか」だ。意味検索が見るのは「意味が近いか」である。
仕組みを平たく言えば、意味検索は文書を小さな塊に切り、それぞれの塊を意味を表す一連の数値に変え、ベクトル庫にしまう。質問したとき、その質問も同じように数値の並びに変わる。あとは「意味の空間で、どれが近いか」を比べる。その空間では「営業収入」と「いくら儲けた」は自然に隣り合う。人が同義語表を手で整備しなくてもいい。
これがキーワードより当たる根っこだ。内容の意味を扱っているからで、字面の一致ではない。読者にとっての利得は直接的で、口語や略語、業界の隠語で訊いても、対応するその段落を取り出せる。
具体例を出そう。ある財務チームが「昨年の所得税の確定申告、補税したっけ」と調べたいとする。キーワード検索なら「所得税」「確定申告」の字面がある場所を探すだけだ。しかし本当にそのことを書いているのは、表題のない「2025 税務事項の説明」という文書の、どこにもタイトルがついていない注記かもしれない。意味検索は字面にこだわらず、意味を認識するから、その注記もすくい上げる。
UglyPear Data ではこの意味検索について、最近ひと回りの全リンク最適化を終えている。全文書塊への意味ベクトルの付け直しを完了し、口語的な質問の解釈が明らかに安定した。エンドツーエンドの回答遅延は、数百秒台から十数秒台へと圧縮されている。口語と丁寧語、両方の言い回しを用意した回帰質問のまとまりは、すべて狙った段落に命中した。つまり、「赤字だった？」「お金はどこから来た？」と訊けば、本当に該当するページを指し示すようになった。この一段階が済んで、ナレッジベースは「探せる」から「訊けば答える」へと移った。
検索と圧縮は、実は二人三脚
この二つを一緒に考える人は少ない。だが私有化ナレッジベースの中では、前後にある二人の役者だ。
文書が庫に入る前にかさばり、冗長を抱えていれば、ベクトル庫もふくらむ。検索は遅く、高くなる。契約書や財務表、設計図を、意味を保ったまま一度圧縮しておけば、体積が下がり、意味の塊がきれいになり、検索の効率はそのまま上がる。UglyPear Data の進め方は、圧縮と RAG データエンジニアリングを切り離さずに一緒にやることだ。前端で文書を絞り、后端で検索を正確にし、データは一貫して客先の内網を出ない。
だから選定時にモデルのパラメータばかりを眺めてはいけない。正確に計算すれば、圧縮と検索のこの二段の連携が、より大きなモデルへ替えるよりも効くことが多い。
三つの方式を並べて見る
選定で迷うのは、名前にみんな「検索」がつくからだ。下の表で差を開く。次元を揃え、そのまま比べられるようにした。
| 次元 | キーワード検索 | 汎用意味検索 | 私有化意味検索（RAG 基盤） |
|---|---|---|---|
| 理解のしかけ | 文字の厳密一致 | 意味の近接一致 | 意味の近接一致 |
| 口語での質問 | ほぼ答えられず | 多くに対応 | 対応、回帰質問で実測全命中 |
| データの出境 | ローカル・クラウドいずれも可 | ふつうパブリッククラウド経由 | 内網から一切出ない |
| 応答速度 | 速い | 中程度 | エンドツーエンドで十数秒台 |
| 機微情報 | 手動確認頼み | プラットフォームの方針頼み | 複数種の機微情報を自動マスキング |
| 向くシーン | 文書少・項目整然 | 公開知識の質問 | 契約・財務・内網資料などのプライベート corpus |
この表を読めば、決断は軽くなる。手元にあるのが公開してもよいデータなら、前者二つで足りる。契約、給与、カルテ、顧客名簿といった「門を出せない」ものなら、第三列しか選べない。
デジタルな溜め込み、その裏側
「整理された数字ファイル」に関する調査に、ひと味違う数字がある。従業員の 28% が、デジタルファイルの散乱ゆえに毎週圧倒されていると感じており、ほぼ半数が「デジタルファイルの片付け」という仕事自体を先送りにし、若い世代ではその比率が 59% に達する。
表面は「溜めすぎ」に見える。根は「使えない」にある。山のように積んだのは、整理ツールが一つ増えたからではなく、何か探すたびにゴミの山から鍵を探すようなものだからだ。検索がずっとファイル名と目視に頼っていれば、データが増えるほど不安は重くなる。
私有化意味検索の価値は、まさにここに落ちる。ファイルを消してくれるわけではない。だが「一句訊けば、正しい一つをすくい上げる」ようにしてくれる。データは静かに内網に眠ったまま、誰も持ち去らない。
なぜ「私有化」を強調するか
初めて知識ベースを立てるチームのいくつかは、手間を避けてそのままパブリッククラウドの方式を選ぶ。すると問題がついてくる。契約や給与、カルテといった文書は、いったん内網を出た瞬間、自らの手の中になくなる。
UglyPear Data の RAG データエンジニアリング基盤は、全私有化配置をとる。元のデータは引っ越さず、域を出ず、検索も回答も客先自身のネットワークの中で完結する。基盤には複数種の機微情報の自動マスキングが備わっており、たとえば契約書の身分証番号や財務表の金額欄は、庫に入る前に識別されて処理される。どう実現しているかの詳細はここでは割愛する。能力の境界を外に明確に伝えればよい。
企業にとっては、二つのことが同時に成り立つ。ナレッジベースが本当に自社の業務を「わかる」こと。そして業務データが、あのサーバー群を一度も離れていないことだ。
ある総合病院の情報システム部が似た立場にいた。カルテも画像も誰にも触れさせられない。それでいて現場は「一句訊けば、ある種の患者の既往を引っ張ってきたい」と願う。パブリッククラウド案はコンプライアンスで真っ先に退けられた。行き着いたのは全私有化だった。検索も回答も院内の機械室で動き、機微な欄は庫入り前にマスキングされる。医師は滑らかに訊け、監査にも疵が見つからない。こうした現場では「内網を出ないか」は加点項目ではなく、前提である。
誰がこの組み立てを真剣に見るべきか
いくつかのチームが特に向いている。法務と財務。契約、証憑、台帳は軽く一万件を超える。製造と医療。図面、カルテ、工程文書は専門的でかつ機微だ。そして「知識がみな古参の頭の中にあって、新人が半日探しても出てこない」どのチームもそうだ。
今の悩みが「データがない」ではなく、「データはあるのに引き出せない、引き出しても安心して使えない」なら、それはおそらく検索層の問題で、より高価なモデルが足りないわけではない。
よくある質問
Q：意味検索と、直接大きなモデルに訊くことの違いは？
A：モデル自体は御社の内部文書を知らない。意味検索の役割は「御社の資料から関連段落を探し出す」ことで、モデルの役割は「その段落をもとに答えを組み立てる」ことだ。両者が組むからこそ、もっともらしく作り話をする事態を避けられる。
Q：私有化配置だと遅くならないか？
A：かつては確かに遅かった。ベクトルが十分に建っていない、リンクが最適化されていない、というところに引っかかっていた。全文書の意味ベクトルを補い、検索リンクの最適化を終えれば、エンドツーエンドの回答は十数秒台に圧縮でき、日常の質問としての体感は許容できる。
Q：機微情報はどうやって内網に留めるのか？
A：全私有化配置の下、元データは引っ越さず域を出ず、検索も回答も客先の内網で完結する。基盤には複数種の機微情報の自動マスキングが備わり、庫入り前に先んじて識別・処理される。人が一通ずつ確かめる形ではない。
Q：ファイル形式がとても雑多なのだが、知識ベースに入れられるか？
A：契約書、財務表、工単、設計図、会議録といったよくある形式は取り込める。前提は、圧縮と形式の治理を先に施し、体積と冗長を下げておくことだ。そうして初めて検索効率が高まる。
Q：知識ベースを立てるのに、大きなチームが必要か？
A：いらない。明確な検索とマスキングの方針、そして私有化配置の能力があればよい。小さなチームでも基盤を正しく使えば、散らばった資料を「一句訊けば答える」内製アシスタントに変えられる。
今すぐ試す
私有化意味検索が実際にどう動くか見たいなら、UglyPear Data の RAG データエンジニアリング基盤を参照いただきたい：https://www.uglypear.com/ja/products/
工程の実践や選定の考え方は技術ブログにまとめている：https://www.uglypear.com/ja/blog/
手元の文書が多くて雑多、しかも内網から出せないなら、狭い範囲の試行から始めるのを勧める。一つの部署の知識ベースで検索とマスキングを先に走らせ、それから広げる話をする。導入の相談はこちらから：https://www.uglypear.com/ja/contact/
より深い設計の論考については、同じくブログの一覧から確認できる：https://www.uglypear.com/ja/blog/