なぜ RAG ではなく「ナレッジツリー探索」なのか

社内の規約や手続きを AI に答えさせたい——この要望はとても多くなりました。多くの場合、最初に選ばれるのが RAG（検索拡張生成） です。文書を細かく分割してベクトル化し、質問に似た断片を引っ張ってきて AI に答えさせる、あの方式です。手軽に始められる一方で、条件分岐の多い業務文書では事故を起こしやすいという弱点があります。

RAG が「年額の解約」を聞かれて「月額の手順」を返す理由

「年額プランの解約はどうすれば？」という質問を考えます。規約には年額と月額、それぞれの解約条件が並んで書かれていることがよくあります。RAG は文章の見た目の近さで断片を引くため、「解約」「手続き」「日割り」といった共通語が多い月額の段落を、年額より高くスコアリングしてしまうことがあります。

似ているから引いてきただけ。なぜその段落を選んだのか、本人（AI）も説明できない。

結果として、もっともらしいけれど取り違えた回答が返り、しかも「なぜそう答えたのか」を後から検証できません。規約・課金・解約のように、利用者の不利益や契約に直結する領域では、これは致命的です。

ツリーを「辿る」と何が変わるのか

VoiceCore が採る方式は、似た文章を引くのではなく、ナレッジをあらかじめ構造化したツリーを上から辿るというものです。学術的には "Don't Retrieve, Navigate"（取得するな、辿れ）という考え方に基づきます。

• ナレッジは事前に「規約・課金ツリー → 解約手続き → 年額プラン → 解約条件」のような階層に整理されます。
• AI は各階層の要約を読み、どの枝に降りるかを判断しながら降りていきます。
• 「年額」という分岐点で正しく年額の枝を選べば、月額の段落に紛れ込むことがありません。

断片の類似度ではなく、構造に沿った判断の連続で答えにたどり着く。これが取り違えに強い理由です。

そして、最大の利点は「足跡が残る」こと

ツリーを辿る方式の本当の価値は、正確さだけではありません。AI が「どのノードを、なぜ選び、最終的にどの文書に至ったか」が、そのまま足跡として残ることです。

たとえば、ある回答の足跡はこう残ります：

この足跡を見れば、担当者でも監査担当者でも「この回答は年額の解約条件（doc-42）に基づいている」と確認できます。RAG では難しかった説明責任に、技術的に応えられるのです。

会話の自然さは、もはや差別化点ではない

音声 AI の「自然さ」は、基盤モデルの進化で急速にコモディティ化しています。だからこそ私たちは、自然な音声会話を当然の土台としつつ、その上に「正確さ＋監査性」を載せることを選びました。賢く答えるだけでなく、なぜそう答えたかを示せること。それが、規約やナレッジを扱う現場で本当に求められている性能だと考えています。