RAGで使われるベクトルデータベースは、従来のSQLとはそもそも解決する問題の種類が違う検索エンジンである。SQLのLIKE演算子が「文字の並び」をパターンで照合するのに対し、ベクトルDBは「言葉の意味」を多次元空間の座標に変換し、座標同士の近さで検索する。一文字も合っていなくても、「犬」と「ドッグ」を同じ近所に配置できるのは、AIが単語の背後にある概念を捉えているからだ。
この「文章を座標（点）にする」仕組みには、特有のルールがある。長い文章をそのまま1つの点にすると意味が薄まってボヤけてしまうため、適度な長さの「チャンク」に細かく刻んで保存するのが定石だ。日本語であれば200〜500文字程度が一つの目安だが、最適な分量は言語・モデル・用途によって変わる。いずれにせよ、数百次元から数千次元に及ぶ計算空間の中で、その情報の個性を鮮明に描き出せるサイズ感を探ることが肝要となる。ただし、この座標は使用する「埋め込みモデル」固有の地図。モデルを変えれば地図の縮尺も方角も変わるため、データは全て計算し直しになる。
文章を点にする際、AIは単語をバラバラにするだけでなく、文脈の「味わい」を数値に凝縮している。例えば「材質：SS、Φ400」という簡素なラベル形式よりも、「材質はSSです。直径は400です」という自然な文章形式の方が、AIにとっては「何が何であるか」の関係性が読み取りやすく、精度の高い座標が打てる。検索時の短い問いかけも同じ空間の点となり、意味の近いチャンクを高速で探し出していく。この「近さ」の測り方にも複数の流儀があり、ベクトルの向きで比較するコサイン類似度、距離で比較するユークリッド距離、内積で比較するドット積など、用途に応じて使い分けられている。
しかし、ここで一つの疑問に突き当たる。データが完璧にクレンジングされ、「材質」や「寸法」が整理されているなら、そもそもベクトルDBを使わずとも、これまでのRDB（関係データベース）の検索で事足りるのではないか。事実、数値の厳密な比較や特定の型番検索において、RDBの正確性とコストパフォーマンスにベクトル検索は勝てない。ただし逆に、構造化されたデータであっても、ユーザーの問いかけが自然言語である限り、「軽い素材」という曖昧な検索語からアルミやチタンを引き当てるような意味の橋渡しは、SQLの得意分野ではない。両者は優劣ではなく、得意な問題の領域が異なるのだ。
この議論を「積算業務へのAI活用」に当てはめると、より現実的な使い分けが見えてくる。1円の狂いも許されない単価の特定や計算に、確率的な「近さ」で答えを出すRAGをそのまま使うのはリスクが高い。積算における理想の形は、正確なスペック検索はRDBに任せ、過去の特記事項や現場の勘所といった「文章の中にしかない知見」をRAGで呼び出すハイブリッドな構成だ。
結局のところ、ベクトルDBは「整理しきれない人間のニュアンス」を扱うための道具であり、議事録や現場報告のような非構造データに対しては、負債の先送りどころか正当な解法となる。一方、美しくクレンジングされたデータセットがあるのなら、無理にベクトル化するのではなく、SQLでスマートに引くのがエンジニアリングとしての正攻法。大切なのは、どちらかを選ぶことではなく、それぞれの土俵を見極めて適材適所で組み合わせることだ。