社内文書・書類をAIの知識に変える。データ構造化ソリューションによるRAG精度向上 vol.1
みなさん。こんにちは。言語理解研究所（以降、ILU）で、CMO 事業開発責任者を務めています。芳賀と申します。
本日は、先日2024年12月3日に登壇しました、アイスマイリー主催のウェビナーの内容について、少し補足・説明しながら、お伝えしたいと思います。
登壇タイトルは『データを価値に変える！データ構造化ソリューションによるRAG精度向上の取り組み』。ILUの新しいソリューション、が生成AI活用で注目されているRAGの精度向上に寄与するかをまとめた内容になります。
企業特有データと生成AIの課題
生成AIが扱えないクローズドデータの問題
すでに、生成AIの業務利用を進めている企業も多いと思いますが、本格的に生成AIを活用する場合は、生成AIが企業特有のデータを扱えるようにする必要があります。
これは、ご存知のとおり既成の生成AI（GPTやGemini、Claude等）が学習しているのは、公開情報（オープンデータ）であるからで、企業内にある業界用語や業務手順、製品・サービス情報、社内マニュアルといった、その企業特有の非公開情報（クローズドデータ）は知識として保有されていないためです。
試しに、GPTに自社の情報に関する質問をしても、たいていは「それについての情報は、私の知識には含まれていません。詳細については、対象企業の公式な情報源をご確認いただくことをお勧めします。」といった感じで返されてしまいます。
生成AIの業務利用が個人レベルに留まる理由
生成AIが企業内部の情報を扱えるようにならなければ、あたりまえですが実業務の利用には限界が生じてしまいます。
議事録作成やメールの下書き、簡単な調査・調べ物など、企業内情報にアクセスせずとも対応できるような、個人利用に留まってしまっている企業も多いのではないでしょうか。
RAGの仕組みと現状の課題
これに対応するために、企業内の情報を生成AIが扱えるようにする開発が必要になります。
ただ、企業独自のLLM（大規模言語モデル）をいちから構築したり、オープンソースのLLMに対し企業内の情報を学習データとしてFine-tuning（微調整・再学習）するには、相当なコストを要するため、多くの企業は、開発コストがそこまで大きくならないRAG（Retrieval-Augmented Generation）という仕組みを選択しています。
RAGの仕組みについては、様々なWebサイトや書籍などで説明されているため、本記事では詳細は割愛しますが、簡単に述べると「ユーザからの質問に対して、まず外部情報を参照・必要な情報を取得し、それを組み込んだ質問文をLLMに投げ込んで回答を生成する」仕組みです。
一見、単純な仕組みのようにも見えるのですが、このRAGの仕組みを用いても、期待どおりのアウトプットが返ってこず、回答精度が満足いくレベルに達しないことが少なくない数で報告されています。
この課題を解決すべく、Web上には、RAGの回答精度を向上させるための様々な技術やテクニックが紹介されている状況です。
回答精度が思ったように上がらない大きな理由のひとつが、企業内の情報（クローズドデータ）のほとんどが、社内規程やマニュアル、レポート、議事録といったいわゆる社内資料や文書類であり、これらは人間が作成した文章や図表で構成された非構造的な定性データであることです。
RAGにおける検索技術の進化：ベクトル検索とハイブリッド検索
RAGの精度向上において、重要なのは外部データの取得部分、つまり「検索」にあります。RAGの仕組みが脚光を浴びる中、比例してこの検索で利用されるようになったのがベクトル（ベクター）検索という手法です。
これは対象テキストや画像をEmbeddingと呼ばれる技術を用いて、数値ベクトルに変換し、その類似度によって検索結果を取得するという方法です。
従来のキーワード（全文）検索が文字列を手がかりに検索するのに対し、数値化することで非構造的なデータも一定検索可能なことが画期的とされ、かつAzureやAWSといった生成AI（LLM）のフルマネージドサービスにも実装されているという手軽さも相まって、RAGにおいて企業内情報を扱うことに取り組むにおいては、もはや利用していない企業の方が少ないのかもしれません。現在は、従来のキーワード検索と上述のベクトル検索を併用する「ハイブリット検索」がRAGの検索部分において主流となっているようです。
ベクトル検索でも解決できない3つの課題
ただ、このベクトル検索をもってしても、非構造データから適切な対象情報を取得することができないケースがあります。複数の要因がありますが、よく直面する問題としては、以下の3点になります。
1.図表や記号など非テキストデータの扱い
1点目が、ドキュメントに含まれている図表や記号といったテキストではない表現の扱いです。
読者の皆さんもご経験されていたことが多いと思うのですが、一般的な社内資料では、文章だけでなく、より読み手が理解しやすいように、図や表、グラフやフローチャートを用いて記載されていたり、記号やマークを用いて強調や引用を行うような内容になっています。
人間が視覚的に理解しやすいような工夫なのですが、構造的なテキストとは言えないためベクトル検索で扱うデータとして難しいものが多いです。
時には、理解しやすいように作成されたこれらの表現方法が、作成者の力量不足によりかえって複雑で分かりづらいものになっているケースもあり、これは情報の整理が不十分で構成が論理的になっていないことが理由であるので、検索対象としてはより難易度を高めてしまっています。
2. 専門用語や社内用語の処理
2点目は資料に記載されている専門用語や社内用語といった固有の表現の扱いです。
これも会社という組織で働いている方は大きく頷かれることと思うのですが、その社内のみで通用する用語や言い回しは本当に多いです。
略語や造語、文字だけみると一般的な用語と一緒なのに、微妙に異なるニュアンスで用いられたりする（例えば私自身もTBAとTBDやコンセンサスとオーソライズの意味をごっちゃにして使っていました。よくない。）仕事を円滑に進めるために生まれた言葉ですので、それ自体を否定するつもりは無いのですが、社外の人間からすると意味不明です。
もちろん、公開情報を基に学習している生成AIがこれを扱うことは困難で、これが理由でベクトル検索をもってしても十分な精度がでない、という結果となってしまいます。
3. ドキュメントの内容分割の難しさ
3点目は、社内資料や文書といったドキュメントは、まとまったひとつの文書でも、中に記載されている内容は複数の別種の内容が含まれていることが多い場合があります。
例えば社内規程の一種である人事規程である就業規則ひとつとっても、中身には労働時間・休日、賃金といった内容があり、賃金の補足説明に労働時間の記述がある、という構成も珍しくありません。生成AIは投げ込まれた情報を基に回答を生成するので、検索において適切な箇所の情報を適切なサイズで取得しないと回答を作成する際にノイズが混じってしまい、期待したような回答を生成してくれない場合があります。
そのためドキュメントの中身を適切な大きさで分割する必要があるのですが（これをチャンキングと呼びます）。
しかし、その用途によって適切なサイズが異なりケースバイケースであることが多く、決定的に正しい分割の大きさが無いこともこの作業の難しい要因となっています。
データ前処理の重要性とその課題
これらの一連の問題を解決する際には、「前処理」と呼ばれるデータをAIが扱いやすいように整形するプロセスが必要になります。
このプロセスは、とても地道で面倒な作業となり開発コストを膨れさせてしまうため、重要とは理解しながらも、十分に対応できていないケースが多いと思います。
ILUのデータ構造化ソリューションのご紹介
さて、前提となる背景が長くなりましたが、この問題を解決できるのがILUの新ソリューションである「データ構造化ソリューション」です。
ILUは、40年以上前から自然言語処理技術の研究とシステム開発に取り組んでまいりました。（言語理解研究所の技術がどのようなものなのかは、他の記事を参考ください）その技術を用いて構築されたソリューションが「データ構造化ソリューション」です。
これを用いて、社内の非構造的なデータを構造化する「前処理」を、コストを押さえながらより高精度に行うことができます。
これを可能とするのがILUのあらゆる日本語のドキュメントの解析に向き合ってきた豊富な知見と実績、そして大規模言語データベースと呼称されている日本語の膨大な辞書です。極めてユニークな独自の技術といえます。
このILUのデータ構造化ソリューションはRAGの精度向上においても有効です。前述したハイブリット検索を構成するベクトル検索ともうひとつの検索手法、つまり、キーワード（全文）検索の精度を向上させることに効果的なのです。
次回は、データ構造化ソリューションが、具体的にどのようにキーワード（全文）検索精度向上に寄与するか、その機能説明も交えて述べていきたいと思います。