正答率 6 割の壁を、構造で越える。
社内のナレッジを AI で活用する仕組みは、ここ数年で広く普及しました。一方で、導入された AI の正答率は 6 割前後で頭打ちと言われ、現場で「結局使えない」と評価される事例が増えています。
Livune は、この壁を設計の問題として捉えています。検索の仕組みそのものを見直せば、6 割の壁は越えられる ―― 自社検証で 5 割 → 9 割超を実証した経験を踏まえ、RAG と階層型ナレッジ設計の使い分けについて整理します。
RAG（Retrieval-Augmented Generation）は、文書をベクトル化して保存し、ユーザーの質問に類似した文書を検索して AI に渡す手法です。文書をそのまま投入できる手軽さから、現在の社内 AI 導入の主流になっています。
ただし、検索の精度は質問と文書の類似度にしか依存しません。同じ意味でも言い回しが違えばヒットせず、複数の情報をつなぎ合わせる質問には弱い。チャンク分割の境目で文脈が壊れることもあります。
RAG は、大量・非構造の文書群から、それらしい回答を引き出すのが得意な手法です。一方で、類似度ベースの検索という性質上、精度は 6 割前後で頭打ちしやすい。これが現場で「結局使えない」と評価される構造的な原因です。
階層型ナレッジ設計は、ナレッジを分類された構造として整理し、AI が必要なときに必要な層へ降りていく仕組みです。プロンプトには上位の見取り図だけが常駐し、深い情報は質問に応じて呼び出されます。
海外の AI 開発の潮流の中で広がりを見せつつある手法で、Livune ではこの階層型ナレッジ設計を採用し、企業ごとのドメインに落とし込むかたちで価値を出しています。
適しているナレッジ
A. 一般的な RAG
大量・非構造の文書群、論文・判例など
B. 階層型ナレッジ設計
業務手順、判断ルール、社内規程など分類できるナレッジ
データ量の目安
A. 一般的な RAG
数百万件以上に強い
B. 階層型ナレッジ設計
数百〜数千ノードが実用域（再帰的な分類で拡張可）
精度の傾向
A. 一般的な RAG
6 割前後で頭打ちしやすい
B. 階層型ナレッジ設計
設計次第で 9 割超を狙える
回答の説明可能性
A. 一般的な RAG
引用元は出るが選定理由は類似度のみ
B. 階層型ナレッジ設計
どのノードが発火したか追跡できる
更新運用
A. 一般的な RAG
文書追加のみ
B. 階層型ナレッジ設計
文書追加 + カテゴリ付与
初期構築の重さ
A. 一般的な RAG
軽い（文書をそのまま投入できる）
B. 階層型ナレッジ設計
中程度（構造化と検索の仕組みの設計が必要）
ランニングコスト
A. 一般的な RAG
ベクトル DB の常時稼働 + API 利用料
B. 階層型ナレッジ設計
API 利用料中心、抑えやすい傾向
論文・判例・特許のような大量の外部参照データから類似事例を引き出したい場合。または、自社内で分類設計のリソースを持てない場合の暫定構成。
経理規程・営業手順・社内マニュアル・技術ドキュメント・判断ルール・業務フロー ―― 業務の構造に沿って整理できるナレッジは、階層型が最も精度を出せます。ほとんどの実務ナレッジがここに該当します。
結論から言えば、企業ナレッジの大半は階層型で精度を出せます。経理・マニュアルといった周辺業務だけでなく、技術データ・営業データのような本業データも、業務の構造に沿って階層化できる ―― これが Livune の立場です。
大企業で現在運用されている RAG の多くは、階層型に置き換えることで精度の改善余地があります。
「とりあえず RAG を入れる」では、6 割の壁を越えられません。検索の仕組みは、ナレッジの性質から逆算して設計するべきものです。
Livune は、お客様のドメインを理解した上で、最適な検索の仕組みを設計します。階層型を主軸に、必要に応じて RAG を組み合わせる ―― 「RAG を使わない」のではなく「RAG 前提を疑う」、これが Livune の立場です。
自社のナレッジで何を実現したいか、お聞かせください。最適な設計を一緒に考えます。