2024/10/13
Semantic Kernelを使う(7)
前回、Semantic KernelのMemory機能でRAG(Retrieval-Augmented Generation)を実行しようとして、一つの事例でうまく行きましたが、異なる事例のデータを使うとうまく行かない問題があり、中途半端な状態で終わってしまいましたので、引き続き調査しました。同じプログラムでテキストファイルを読み込んでいる点は同じですが、結果が異なるということなので、原因として
1. ファイル容量(文字数)が多いこと
2. ファイルの中身の細部の形式が異なること
の2つを考えました。
結論から言うと、1.ではなく、2.がヒットしていました。結果をまとめると以下の通りです。
改めて、詳細を追って行きます。1.のファイル容量については確かに、エラーを吐いたブログ記事(A)の方が、正常に結果出力したもの(注文の多い料理店)に比べ、10倍以上の容量がありました。そこで、ブログ記事(A)から一部を抜粋したテキストファイル(B)を作成して実行させました。Token数も注文の多い料理店のテキストよりも少ないファイルです。しかし、結果は同じ「INFO NOT FOUND」でした。このことから、1.のファイル容量は関係のないことが分かりました。
次に、2.のファイルの中身の細部の形式ですが、注文の多い料理店のテキストファイルは、1文(句点)毎に改行が入っており、かつ無駄なスペースが含まれていないものでした。一方、ブログ記事は段落毎にしか改行が入っていません。そこで、テキストファイル(B)について、無駄なスペースを省き、一文毎に改行を入れるようなテキストファイル(C)を作成しました。実行すると、正常に動作しました。
最後に、ファイル容量とは関係ないことを裏付けるために、元々のブログ記事のテキストファイル(A)についても、1文毎に改行を入れたテキストファイル(D)を作成しました。実行すると、データ量が多いので「15秒程度」の待ち時間はありましたが、正常に回答が戻ってきました。
前回、不明で中途半端だったことが、今回、原因が分かり明確になりました。Semantic KernelのMemory機能に入力するデータは1文を1行として、整理整頓しておく必要があることが良く分かりました。次回から気を付けようと思います。
コメント