社内の文書はカオスで、それがコストになる——現場を渡した人はどう考えているか

社内のすべての文書——契約書、調査報告、録音の書き起こし、何百ページもあるスキャン資料——をそのまま「賢いシステム」に放り込んだら、どうなると思いますか。この経験をしたことのある人の正直な答えは決まっていて、入らないか、入っても質問に答え違いをするか、それとも誰にも気づかれないうちに請求額だけが上がっていくか。三つの中で一番ましなのはどれか、と訊かれても答えにくい。

文書が少なすぎる問題ではない。多すぎて、雑すぎて、高すぎる問題だ。企業のプライマリストレージ上に眠るデータのうち、60%から70%は90日以上まったくアクセスされていないという実態がある。高い本番ストレージの上で、誰も見ていないデータが場所を占め続けている。ナレッジワーカーは週のおよそ19%、つまり1日にして約1.5時間を、情報を探したりかき集めたりするために費やしているという試算もある。さらに、作業の中断から集中を取り戻すのに平均23分かかり、1日のうちに約35のアプリケーションを行き来している。文書の扱いを誤ると、それは単にディスクを食うだけでは済まない。あらゆる中断のコストを、静かに、しかし確実に何倍にも膨らませていく。

この「問題」に直面した新人が取りがちなのは、たいてい二つの行動だ。ファイルを小さくするツールを探すか、ベクターインデックスを作って検索できるようにするか。本番システムを組んだことのある人は、そこから始めない。

彼らの立てる問いは違う。「どのツールか」ではなく、「そもそもこのデータはなぜ変わる必要があるのか」だ。ストレージを減らすためか。メールに添付して送れるようにするためか。モデルに読ませて回答させるときにトークンを節約するためか。それとも十年間改ざんされずに残るコンプライアンス上のアーカイブにするためか。同じ山の文書でも、目的が変われば扱いはまったく別のものになる。現場を知る者は、何かに手を付ける前に制約を釘で打ち付けるように固定する。圧縮する、あるいはベクターインデックスを足す、をデフォルトの反射動作にしない。

制約を固定したら、手を付けるのはその山を「それが実際に何であるか」で仕分けることだ。赤い印鑑のある署名済み契約のPDFと、4Kの工学的スキャン画像と、200ページの規制報告書は、まったく別の生き物だ。契約書には構造と印鑑が文字通りそのまま残らなければならない。スキャン画像は冗長なピクセルに満ちている。報告書は繰り返されるレイアウトのパターンを抱えている。この三つに一つの「既定の圧縮」をぶつけると、たいていうまくいかない結果になりがちだ。くっきりしておくべきものがぼやけ、小さくなるべきものがそのまま。ここが素人と専門家の分かれ目だ。素人は「どれだけ小さくなったか」を見る。専門家は「絶対に動かしてはならないものはどれか」を見る。

一言深く掘り下げれば、専門家は情報そのものに立ち返る。なぜファイルは大きいのか。スキャン画像は、目には区別がつかないがバイトの上では冗長な高密度ラスタに満ちているから大きい。テキスト文書は、繰り返される構造と埋め込まれたオブジェクトのせいで大きい。だから圧縮するかどうか、どう圧縮するかは、デフォルトのプリセットに従うべきではない。そのファイルが何に使われるかによって決まる。十年の法的証拠として残るものはロスレスで可逆に。画面でさっと見るかメールに押し込むものは、大切な情報を保ったままロッシーに。ロスレスかロッシーかというスイッチをデフォルトの手から奪い返すこと。それが専門家とツールの工場出荷挙動の境界線だ。

分類を間違えば、その下流のすべてが壊れる。契約書をロッシーと設定して印鑑がぼやければ、それは事故だ。ロッシーにすべきスキャンをロスレスで固執させれば、サイズは微動だにせず、パイプライン全体が遅くなる。だから専門家は、後で火消しをするくらいなら、前の段階で十分間をとって「これはどの桶に属するか、圧縮後に誰が使うか」を訊くことを選ぶ。分類はワークフローの儀式ではない。その上に他のすべてが載る土台だ。

小さな例を出そう。スキャンされた契約書は、印鑑と署名日こそが命だ。これをぼやかせば、法的には文書を書き換えたのと同じになる。医療画像なら、圧縮して消してしまったのがまさにその病変の縁かもしれない。素人は「60%小さくなった」と喜ぶ。専門家は「その60%の中に、動かしてはならないものは混ざっていないか」と問う。圧縮する前に、専門家は訊く。このものが「変わった」せいで損をするのは誰か、と。その答えが、圧縮するかどうか、どう圧縮するかを決める。

新人が見落としがちなもう一つの層がある。同じ文書が会社の複数のシステムに、バージョンも揃わずに散らばっていることが多いということだ。専門家は圧縮や検索の話に入る前に、重複とバージョンの整理を済ませる。汚れたデータにインデックスを張れば、その後に何をしても検索の質は上がらないからだ。コストも総勘定しなければならない。埋め込みを一度計算し、再ランク付けを一度走らせ、モデルが一度読む——トークンはどこで一番価値を買うのか。余分な段落をいくつか引っ張ってモデルに選ばせるか、先に精査して少なめに取るか。その計算が見えなければ、「節約」は単なるスローガンだ。とりわけ検索拡張の構成では、引き出された各段落はモデルに再度読まれるから、汚い文書とおざなりなチャンキングはトークン請求書の上で月単位で複利になる。先に圧縮し、先に整理する——後でより高価なモデルを買うより、たいていは安くつく。

本番を組んだ人たちは、ナレッジベースを「アップロード」ではなく「稼働するシステム」として扱う。文書は変わり、事業は変わる。今日正しく答えられたものが、来月のバージョンが入ってくれば誤り始めるかもしれない。だから彼らは初日から評価セットとロールバックの余地を残し、「作る」と「養う」を一つの仕事として扱う。これが、デモが華やかで本番では崩れる理由だ。デモは「何かを返せる」ことを証明するだけだが、本番が求めるのは、本物の、乱雑で、移り変わる文書の上で正しく答え続けることだ。「何かを返す」を終点とする人と、それを起点とする人とでは、出来上がるシステムがまるで別物になる。

圧縮と検索は別の仕事だと多くの人は思い込んでいる。専門家はそうは考えない。彼らは「片付ける、小さくする、分割する、ベクターにする、検索する、答える」を一本の線と見なし、任意の孤立したきれいな数値ではなく、その線全体の結果だけを信じる。そして圧縮と検索の前には、たいてい片付けという段階がある。同じ資料が十数のフォルダに散らばり、名前がめちゃくちゃになっている。専門家は「どこに属すべきか、どの軸で分類するか」を決める。どんなに検索が優れていても、場所を間違えてしまった文書は救えないからだ。きれいに圧縮された文書は、検索に入るときノイズが少なく、トークンが抑えられ、再現が安定する——この文書の圧縮はストレージのおまけではない。検索の質の前置工程だ。逆に、検索がよく答え違いをするなら、専門家は真っ先にモデルを責めない。振り返って訊く。チャンクが文の真ん中で断ち切っていないか、口語的な質問がそのままの検索ではそもそも引っかからないのではないか、関連する段落が切り捨てられていないか、と。

検索という段階において、専門家の道具箱は素人の想像と違う。彼らは生の質問をそのまま放り込まない。実際のユーザーの質問は口語であり、略語であり、類義語の置き換えであり、しばしば一文に三つの意図を詰め込む——評価セットにあるきれいな「返金ポリシーを説明せよ」など現実にはほとんど存在しない。だから彼らはハイブリッド検索を行う。キーワードの経路で正確な一致を拾い、意味の経路で近い意味を拾い、二つを合わせれば見落とし率はすぐに下がる。一次のふるいの後には再ランク付けを継ぎ、本当に関連するものを上に押し上げる。難しい質問には、口語の一文を検索に適したいくつかの部分クエリに書き換え、別々に検索してから組み立てる。権限と出所も先に絞るので、見てはいけないものが漏れ出すことはない。

これらの動作は見せびらかしのためではない。すべてが一つのことを指している。答えの正確さを、運ではなく測れる指標にすることだ。これこそ、誰も求めなかったが専門家は必ずやる一連のことだ——コードを書き始める前に、出所の明記された標準回答付きの質問応答ペアを準備する。それなしでは「正しい」に定義がない。見落とし率と答え違い率を問題の種類別に分け、どの類型がいつも転ぶかを一目で見る。ナレッジベースを更新するたびに古い評価セットを再実行し、「今日は正しくても来月は誤る」という静かな劣化を防ぐ。

では、なぜこれを信じるのか。ベンダーが「我々は正確だ」と言うからでも、買い手が「たぶん十分だろう」と願うからでもない。耐えられるのは、第三者にも再現できるものだ。独立してラベル付けされた黄金の質問セット。誰かが同じラベルでシステムを再実行すれば、recall@k と忠実度が表に載る。新旧のパイプラインが実際の質問に答えたものを、独立した評価者が匿名で盲検し、その差が「内側でテストした」に頼らない。さらに回帰テストの一式を育て、正しく答えるべき既知の事例が正しく答え続けることを、赤緑のステータスを公開して確認する。圧縮自体も同じだ。圧縮後の文書が元と同じように開くか、印鑑はあるか、レイアウトは崩れていないか。開いて原本と比べればわかる。小さくした後にモデルに流せば、トークンは実際にどれだけ減ったか、検索はまだ正しいか。下流のタスクを一度走らせれば答えが出る。正しさは誰かの約束から来るのではない。誰でも検証できる動作から来るのだ。

結局、この一連の考え方はどこかの製品の機能リストではない。一つの習慣だ。どうするかの前に、なぜするのかを訊く。速さや安さを語る前に、「正しい」を定義する。そして、きれいなスローガンではなく、誰でも再現できる動作によって、それが本当に正しいと証明する。

私たちはこのほど、圧縮と検索のつなぎ目で小さな一歩を踏んだ。文書を検索に入れる前の前置きの圧縮を、複数の主流の大規模言語モデルで安定して動くように対応させた。スリム化された同じ文書が、異なるモデルでも読み取れて使えるようになったのだ。これがまさに上で書いた壁を解消する。小さくして、モデルが読めなくなってはいけない。これは全体のエンジニアリングの深い領域からすればほんの端っこだが、方向は間違っていない。「小さい」と「読める」を一つのことに溶かし、その上に評価と再ランク付けと可観測性を重ねていく。

よく似た考え方は、UglyPear Data の文書圧縮と RAG データエンジニアリングの実践の中にも見られる。例えば私たちが提案するのは、データ主権を自社で握る、プライベートデプロイメントを前提とした構成だ。データが内網の外に出ない、エアギャップ環境でも動く、ローカルファーストの設計。企業が自社の契約書や顧客記録を外部に渡さずに済むよう、 https://www.uglypear.com/ja/products/ では圧縮と意味検索を一つの線にまとめたアプローチを公開している。運用の背景や現場の考え方については https://www.uglypear.com/ja/blog/ にいくつかの記述がある。具体的な圧縮と検索をつなぐ検討は、 https://www.uglypear.com/ja/blog/ でも扱っている。

今すぐ試す

プライベートデプロイメント、データの内網外流出なし、圧縮と意味検索を一本の線に溶かした構成を本番環境に落とす様子を見たいなら、ここを参照されたい。

• UglyPear Data 製品一覧
• UglyPear Data 公式サイト
• 技術ブログ

よくある質問

Q：うちは小さい会社で文書も多くない。既定の圧縮で十分では？
A：文書に何をさせたいかによる。内輪でファイルを回すだけなら、既定の圧縮でたいてい足りる。しかし文書が検索に入り、モデルに読ませ、証拠として残る段になった瞬間、分型と戦略の差は小さくない。

Q：圧縮した文書は法的証拠になりますか？
A：圧縮の仕方による。アーカイブ系はロスレスで可逆だから、内容と印鑑がそのままで証拠になり得る。プレビュー系のロッシーは素早く見るためだけのもの。肝心なのは「圧縮したか」ではなく、「その類型がどちらの道を通ったか」だ。

Q：ハイブリッド検索は複雑そうで、小さなチームでも扱えますか？
A：中核は「キーワード＋意味」の二経路を合わせ、再ランク付けを足すだけで、どちらも公開された実装がある。コストは金銭ではなく、「正しく答える」を測り続ける気があるかだ。

Q：ナレッジベースが本当に正しく答えているか、どう見極めればいい？
A：デモを信じてはいけない。ラベル付けされた標準の質問応答、再実行できる評価、それに盲検と回帰テストが必要だ。第三者が同じ基準でシステムを再実行できれば、結論は立つ。

Q：圧縮と RAG は一緒にやらなければなりませんか？
A：同じ担い手である必要はないが、一本の線として見なければならない。きれいに圧縮された文書が検索に入ればノイズが減り、トークンが抑えられ、再現が安定する——二つを切り離すと、たいてい両方で損をする。