Skip to content

評価結果_2024 08 19

Jump to bottom
matsusho070 edited this page Sep 10, 2024 · 11 revisions

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

実験設定

実験結果

結果の表：evaluation_results_all_default.csv

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

２回目（chunk_size=200）

実験設定

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

実験結果

結果の表：evaluation_results_chunk_200.csv

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

３回目

実験設定

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

実験結果

結果の表：evaluation_results_with_rerank.csv

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

４回目

実験設定

  • 個別にアップロードした資料ではなく、クローリングスクリプトで完全に自動的に収集したナレッジを使用した評価を行った（ドキュメント数=414）。
  • チャンク分割などの設定は１回目と同じ。

実験結果

結果の表：evaluation_results_whth_automatically_crawled_knowledge.csv

  • source_urls_f1_score が 0.3, answer_similarity が 2.46と、source_scoreが１回目より悪い。answer_similarityは微妙に減少している
  • 単純に対象とするドキュメントの数が増えたので、どれを参照すべきかの精度が下がっている。
    • 数値的には下がったが、例えば「消化器疾患の難病と診断されましたが...」の質問に対しては、令和５年の資料ではなくより新しい令和６年の資料を参照して日程を回答しているなど、良い部分もある。
  • 実行時間：63秒

APIの利用料金に関して

  • 本評価スクリプト１回の実行に当たり発生しうる外部API利用料金は以下の通り
  • Azure OpenAI Service
    • gpt-4oモデル
      • 単価は 入力が $5 / 1M tokens, 出力が $15 / 1M tokens
      • 回答生成
        • Dify における回答生成では１回あたり 入力で7000-8000トークン（$0.035-0.04） 、出力が2500-3000トークン（$0.0375-0.045）程度に相当する
      • 回答結果の評価
        • LLMによる評価の実行では１回あたり 入力で7000-8000トークン（$0.035-0.04）、出力が150~200トークン（$0.00225-0.003）程度に相当する。
    • japaneast-text-embedding-3-large
      • ベクトル検索時のプロンプトの埋め込み
      • 単価は $0.00013 / 1K トークン であり、今回の実行では１回あたり 500-600 トークン（$0.000065-0.000078） 程度に相当する
  • Cohere
    • Rerankモデル
      • ベクトル検索結果の適切さによる並び替え
      • Trialモデルを利用する場合は無料。商用利用や正式にサービスインする場合にはproductionモデルを利用する必要がある
      • 単価は $2.00/1K Searches であり、今回の実行では１回あたり 13 Search（$0.026）に相当する

実行時間について

  • 今回実験した範囲では、おおよそ全質問に対して１分前後の時間がかかった （外部APIを利用する関係上、通信状況やAPIサーバの混雑状況によっても大きく変動する）

全体で共通の課題

  • 「指定難病ではなく，東京都が独自に指定する助成対象の疾患を教えてください」に対しては、８疾病あるということは回答できるがその具体的な内訳を回答できていない。
  • 「指定難病の認定を受けている場合，助成を受けられる訪問看護サービスはどこですか？」に関しては、資料を参照することができず、具体的な一覧を返すことができない（指定薬局板の質問も同様）
  • 「難病と指定された場合に，助成対象とはならない介護の内容は？」に対して、逆に「助成対象となる介護」のチャンクしか参照できておらず、具体的な回答ができない。

今後の改善の見込みに関して

  • 検索以前に、クローリングによる情報収集の時点で難病に関連しないURLを除くなどの処理を入れることが有効そう
    • 現状では、都道府県ごとのポータルサイトから辿れるURLをかなり無差別にFirecrawlで辿ってしまっているため
  • 検索してヒットしたチャンクだけではなく、その前後のチャンクも含めて回答生成の際に利用すると回答の精度が上がる可能性がある（例えば、「助成対象となる介護」のチャンクの直後に「助成対象とならない介護の例」が存在する）
  • RAPTORやGraphRAGなど、意味の階層を考慮した検索を行う枠組みを利用することでも精度が向上する可能性がある
Clone this wiki locally