評価結果_2024 08 19

評価実行例： evaluation_results_2024-08-19_10-52-31.csv

１回目（ほぼデフォルト設定）

実験設定

• Index methodをHigh qualityにする以外は、Difyのデフォルト設定のまま評価を行った。
• ナレッジのデータは、Firecrawlで自動収集した32ドキュメント＋手動でアップロードしたPDF５つ＋Excelデータ１つ
• 該当のボット：http://aidrd.japaneast.cloudapp.azure.com/app/0972d5ca-505a-46fa-9b1f-1a9d218cd96d/configuration

実験結果

結果の表：evaluation_results_all_default.csv

• source_urls_f1_score = 0.44 かつ Average Answer Similarity Score = 2.54ということで、数値的には正解率半分程度
• source_urls_f1_scoreが0（該当する情報ソースが取得できていない）場合は、当然ながらスコアが低くなっている。 また、ファイル単位では参照先が正しい場合でも、例えば「難病と指定された場合に，助成対象とはならない介護の内容は？」という質問に対して、「助成対象となる介護の内容」のチャンクを取得してしまい、「助成対象とならない費用」のチャンクを参照できていないなどの問題がある

２回目（chunk_size=200）

実験設定

• １回目とほぼ同様の設定だが、チャンク方法をAutoからCustomに変更し、チャンクサイズとして200文字を指定した。
  • なおAutoの場合は、文章の区切り位置次第でチャンクサイズが変動し、最小40文字、最大で1000文字超になっていた（平均すると500文字程度）

実験結果

結果の表：evaluation_results_chunk_200.csv

• source_urls_f1_score = 0.25 かつ Average Answer Similarity Score = 1.69 ということで、１回目よりかなり悪化している。
• チャンクサイズ以上に、Segment Identifierとして改行文字（\n）を採用してしまったことで、各チャンクが意味が成り立たないレベルまで細分化されてしまった影響が大きそうに見える。

３回目

実験設定

• １回目の設定と同じナレッジを使用するが、Rerankモデルを有効化し、RetrievalをN to 1（事前にどのナレッジを使用するかをLLMが決めてからチャンクを検索）ではなくMultipath Retrieval（すべてのナレッジを横断的に検索した後、Rerankでより関連性が強いものを選出）に変更した。

実験結果

evaluation_results_with_rerank.csv

• source_score が 0.49, answer_similarity が 3.54 と、１回目よりは良くなっている。
• N to 1 だったときはナレッジの説明を見てLLMが選択していたが、ここの情報量が足りていなかったためMultipath Retrievalの方が性能が出たものと思われる。
  • 実際、今回のような用途の場合に各ナレッジに説明をつけていくのは現実的ではないため、基本的にはMultipathの方が妥当？（ただ、説明自体を事前にLLMで付加するアプローチも可能かもしれない）