RAGにおける「前処理」とは?

まず、RAGの前提知識といたしまして、ユーザーが登録するテキストデータを、どのようにして処理されレスポンスまで持っていくのかを軽くまとめさせていただきます。

(出典:NVIDIA DEVEROPER)

 

ドキュメントの自動処理 (Document pre-processing)

ドキュメントが読み込まれた後、内容を加工する必要があります。
その一つの方法がテキストのスプリットで、長いテキストを小さな部分に分けます。

これは、e5-large-v2というモデルが使える最大の長さが512トークンだからです。この分割作業は簡単そうに見えるかもしれませんが、実際には慎重に行う必要があります。

 

埋め込みの生成 (Generating embeddings)

データを扱いやすい形にするため、埋め込みを生成します。
埋め込みとは、テキストを数値の形で表現することで、これを高次元ベクトルに変換します。

 

埋め込みをベクトルデータベースに保存 (Storing embeddings in vector databases)

加工したデータと生成した埋め込みは、ベクトルデータベースと呼ばれる特別なデータベースに保存されます。これにより、データの検索や取得が速く行えます。

高速化されたデータベースに保存することで、リアルタイムで素早く情報を引き出すことができます。

 

LLMs

LLM(大規模言語モデル)は、RAGシステムの中心的な要素です。これらのモデルは大量のデータでトレーニングされており、人間のようにテキストを理解して生成することができます。

RAGのシステムでは、LLMがユーザーの質問に対して、ベクトルデータベースから取り出した情報を元にして、適切な回答を生成します。

 

クエリ (Querying)

ユーザーが質問をすると、RAGシステムはデータとベクトルを使って関連する情報を検索します。システムは、質問のベクトルとベクトルデータベース内のベクトルを比べて、関連する情報を見つけます。そして、LLMがその情報を使って、適切な回答を作り出します。

 

 

今回はそんなRAGに関して、「前処理」がいかに重要か語っていきたいと思います。

知っているかいないかでは大違い。ぜひお読みください。

 

◼︎RAGの前処理

トークン数に応じてテキストを分割する際、ランダムに分けるのではなく、文章の区切り、句点や段落が影響します。(以下参照)

Retrieval Augmented Generation (RAG) Done Right: Chunking

テキストが整頓されていないと、”この行がどこにかかっているのか” という構造が見えなくなってしまい、ハルシネーションを引き起こします。

情報の構造が違う形で読み取られてしまうと、RAGの意味がありませんね。

 

これを整える作業が「前処理」です。

具体的には、以下のように構造化し、マークダウン形式に近い形で整理してやります。

 

◼︎前処理を行なっていく

以前弊社の記事で紹介したGoogleサービス『NotebookLM』で検証を行いました。

https://notebooklm.google/

 

題材は、松山市のマイナンバー申請手続きに関するページです。

https://www.city.matsuyama.ehime.jp/kurashi/tetsuzuki/mynumberseido/mynumber.html

(↓前処理なしデータ)

これを以下のプロンプトで GPT-4o に渡し、前処理を行いました。


以下のテキストを、RAGに使うテキストファイル用に整頓してください。

マークダウン形式が望ましいです。

=====

[全文]


 

(前処理ありデータ)

 

◼︎前処理の前後で比較

同じ質問を投げ、前処理なしとありで比較していきましょう。

・質問:「マイナンバーカード申請には何が必要ですか?」

ちなみに正解がこちらです。

それでは比較を見ていきましょう。

 


[前処理なしの回答]

マイナンバーカードの申請に必要なものは以下のとおりです。

* **申請書**: 申請書は窓口でも入手できます。代理人が申請する場合は、本人が必要事項をすべて記載し、顔写真を貼付する必要があります。
* **顔写真**: 縦4.5センチ×横3.5センチで、6か月以内に撮影したものを用意してください。 松山市役所本館1階の市民課にあるマイナンバーカード専用窓口では、申請用顔写真の無料撮影サービスを実施しています。
* **本人確認書類**: 15歳未満または成年被後見人の場合は、法定代理人の同行も必要です。

これらのものを持参して、市役所の窓口または郵便局で申請手続きを行うことができます。 また、スマートフォンやパソコンを使って、自宅からでも申請手続きを行うことができます。

 


[前処理ありの場合]

マイナンバーカードの申請には、以下のものが必要です。

* **申請書**: 代理人が申請する場合は、本人が必要事項をすべて記載し、顔写真を貼付する必要があります。様式は窓口にもあります。
* **顔写真**: 縦4.5センチ×横3.5センチの6か月以内に撮影したものを用意してください。松山市民課では、申請用顔写真の無料撮影サービスを実施しています。

申請時に必要なものは、申請方法によって異なる場合がありますので、詳しくはソースをご確認ください。


 

一見問題ないように見えるのが厄介ですが、[前処理なし] の方は誤った情報が返ってきているのがわかると思います。

↑ ここの部分を変に読み取り、「本人確認書類」を勝手に追加してしまっているようです。

◼︎現状の課題

ファインチューニングと違い、RAGは登録するファイルの質が問われてきます。

手軽な反面、前処理の質によって回答が変わってくるのは難点です。

上記で紹介したように、前処理を以下のようなプロンプトでAIに任せるのも手です。


以下のテキストを、RAGに使うテキストファイル用に整頓してください。

マークダウン形式が望ましいです。

=====

[全文]


 

しかし理想を言えば、それすら自動で行ってくれるのが楽ではないでしょうか。

今後半年、もしくは1〜2年の間で、そこの手間が無くなるような改革が起こる予感がしています。

今後も注目し、ハックしていこうと思います。

◼︎まとめ

いかがでしたでしょうか。

RAGは「パーソナルAI」を体現する技術です。間違いなくこれからもっと注目され、一般層にも馴染みの深いものとなっていくでしょう。

また気になるトレンドや技術を記事にしていきますので、お読みいただけますと幸いです。

お読みいただきありがとうございました!

Googleのアプローチを深掘ってみる

GoogleがAppleに対し、お金を払っているのを皆さんはご存知でしょうか。

それも年間で3兆円弱。かなりの額ですね。

iPhone (Safari) のデフォルト検索エンジンにしてもらうために支払われているそうです。

 

今回はこちらの記事を参考に、両社の関係やアプローチ、それに伴う動きについて触れていきます。
https://www.gizmodo.jp/2023/10/google-pays-apple-18-billion-for-search-engine-default.html

 

なぜ大金が動くのか

年間180億ドルから200億ドル(約2兆6000億円〜2兆9000億円)。

資産運用会社調べでは、この額はAppleの年間営業利益のおおよそ15%に相当するとのことです。

Appleの収益の15%はGoogleからの支払いということになります。

Googleに対する反トラスト訴訟 (独占禁止法的な観点での訴訟) の中で、主任訴訟担当官が、Googleの支払い額を100億ドル以上と推定しているそうですが、新しい推定では180億ドルから200億ドル(約2兆6000億円〜2兆9000億円)の規模になるだろうと言われています。

Google社内でも2007年に

「私たちが市場を独占するブラウザであることは、ユーザーエクスペリエンスとしてよいものではないし、印象もよいとは言えない。」

という声が上がったとの話もあり、また裁判所がGoogleに対し (Appleとの) 契約解除を命令する可能性についても浮上しているとのことです。

 

デバイスを持つAppleへのアプローチ

Googleは本音ベースでは、iPhoneユーザーにはSafariに依存してほしくないものと思われます。

実際に以下の記事は、iPhoneユーザーのSafariブラウザー以外からの検索量を増やすことを目標とした記事です。

https://www.theinformation.com/articles/google-struggles-to-lessen-reliance-on-apple-safari

Googleのブラウザである「Google Chrome」の普及に力を入れ、デバイスプラットフォームを持つAppleに対してアプリケーションレイヤーからアプローチを行なっています。

 

ところで、Appleといえば今年「Apple Intelligence」を発表しましたね。

その発表の目玉として、iOS18からAppleデバイスに、OpenAIのLLMモデル「ChatGPT」が組み込まれるという情報が出てきました。

OpenAIはセキュリティ面を強化することで、アプリケーションレイヤーよりもっと深く、OS深部までアプローチを試みる可能性がありますね。

まとめ

いかがでしたでしょうか。

弊社HAVASもAIエージェント開発に力を入れていますが、今回のような話題も参考にしながら柔軟に渡り歩いていきたいと思っております。

大規模言語モデル (LLM) をはじめとした各種ツール間のエージェントも模索しつつ、データベース (ベクトルDBなど) をはじめとした深いレイヤーの洞察および開発も視野に入れつつ、引き続き尽力していきたいところです。

今回もお読みいただき、ありがとうございました。