OpenProvenceを自社の評価データで検証してみた

Transcript

1. LegalOn Technologies 検索・推薦チーム Ja Wattanawong OpenProvenceを自社の評価データで 検証してみた
2. 2 • Name: Ja (Thanakul) Wattanawong ◦ @ja5087 ◦ バンコク（タイ）出身 • 2025/4よりLegalOn Technologiesで検索・推 薦チームにジョインしました ◦ 前職：営業支援AI Agent開発の スタートアップ ◦ その前：UC Berkeleyで修士課程 (NLP/AI研究) • 趣味：ハイキング、バドミントン 自己紹介
3. 3 経緯 - Search Engineering Tech Talk 2025 Autumn（10/30） でこの発表があった （残念ながら自分は参加 できなかった） - チーム内で検証した結果、 さまざまな知見が得られたため、 それをまとめてトークに した。 https://search-tech.connpass.com/event/370754/presentation/
4. 4 - LegalOnアシスタントとは？ - なぜProvence/OpenProvenceを検証した - 評価フロー（省略版） - Results - まとめ Agenda
5. 5 - 弊社の検索機能がついている法務特化型 AIエージェントプロダクト - 契約書・案件の検索結果を回答生成に 活用することは重要なユースケース - そのため、RAGの性能が重要である LegalOnアシスタントとは？ 参考ソース 回答に組み込まれた契 約書
6. 6 - 契約書は - 長い - クエリに関係ない部分が多い - 全文をLLMに渡すと - 生成速度・精度の低下 - コストの増加 - 参照できる契約書数の制限 といった問題が生じる - しかし、回答の信憑性が重要である ため、検索結果または契約書の一部をむ やみに除外することはできない 契約書をRAGで扱う際の問題 数千・万トークン ✕ 参考ソース数 コンテキスト膨大化 ＝ Hong, K., Troynikov, A., & Huber, J. (2025). Context Rot: How Increasing Input Tokens Impacts LLM Performance. Retrieved from Chroma website: https://research.trychroma.com/context-rot
7. 7 - そのため、契約書本文からクエリに関連する部分だけを 残したい - そこで Provence を検証することにした - ProvenceのKey Idea - Question と Context を入力すると、Cross Encoder によ り不要文を削除した短縮版 Context が 生成され、reranker score も取得できる。 - OpenProvence - 舘野 祐一 (@hotchpotch) さんによる日英版の再現 - オープンソース Provence / OpenProvence https://speakerdeck.com/hotchpotch/openprovence-kueriniguan-lian-sinaiwen-zhang-xue-chu-moderuri-ben-yu- ban-nozuo-cheng-togong-kai https://arxiv.org/abs/2501.16214 Chirkova, N., Formal, T., Nikoulina, V., & Clinchant, S. (2025). Provence: efficient and robust context pruning for retrieval-augmented generation. ArXiv, abs/2501.16214.
8. 8 - 評価インフラ - サンプル契約書がある環境 - データセットを用いて評価するスクリプト - 評価データセット - サンプルクエリ - 期待する結果とKey Point - メトリックス - LLM as a judge - （今回は追加）Recall, Precision, Contains Answer String - 検証したかったポイント - 精度への影響 - 成功ケース、失敗ケース - 実際にプロダクトに使えるか LegalOnアシスタントにおける検索機能の評価フロー（省略版） + OpenProvence LegalOnアシスタント データベース OpenProvence API サーバー 評価スクリプト・データセット コード変更を最小限に抑えるため、 OpenProvence の API サーバーを立てて、ドキュメント取得処理で差し替えた
9. 9 - 当チームは３つのデータセットを用いてLegalOnアシスタントにおけるRAGの精度を評価している - 各データセットで、データ構成が異なっている - Extraction (メイン), Summarization, Comparison, etc. - LLM as a judgeのスコアがそんなに下がらなかった（上がった場合もある）ため、期待できそうに 見える - ただし、クエリの種類によって結果に差がある Result 1: LLM as a Judge Dataset LLM-as-a-judge Provenceなし LLM-as-a-judge Provenceあり Dataset A 0.947 0.940 (-0.007) Dataset B 0.584 0.503 (-0.081) Dataset C 0.771 0.829 (+0.058)
10. 10 - Query: 販売業務の委託に関する取り決めが詳しく定め られている契約書を探しています - 赤色：削除部分 - 青色：回答に必要な部分 - 圧縮率 50% (-4000文字) - 今回の傾向：Extractive Q&A の場合は精度が高い Result 1.1 - Example Good Result 回答に必要な部分 削除された部分 対象の契約書
11. 11 - Query: (仮名) 山田奉太郎との過去の契約書と の違いを教えて - 備考： 現在閲覧中の契約書がある - ほとんどの文が削除された - 今回の傾向：「クエリと関連する部分」の 判定が難しい場合は精度が悪い - RAGにおける検索と同じ問題 Result 1.1 - Bad Result …と山田奉太郎（以下「受託者」 という... 削除されてしまった部分 対象の契約書
12. 12 - データセットの一部には、情報の所在に関する詳細なラベルが含まれている (Gold Label) - Retrievalの精度を除外し、正しいドキュメントを取得できた前提で、 OpenProvenceを実行した場合の結果を検証する - Contains Answer Stringは概算指標として活用できそう - RecallとPrecisionは計算してみたが、有効な指標ではない可能性がある - Recallは異常に高かった - 契約書には重複なトークンが含まれるため、 Gold Label内のテキストはプルーニングされたテキストの他の部分に も現れる - 修正できたら、F1/F2スコアを指標として使えるかもしれない Result 2 - Token Level Metrics 指標 値 説明 Contains Answer String 0.6250 OpenProvenceは約60%の確率でプルーニング後で正解を保持している。
13. 13 - 圧縮率が常に高いことを確認した - 長いドキュメントほど圧縮率が高い - 仮説：Extractive Q&Aの場合は必要な情報量がほぼ一定 - 平均圧縮率：68.7% Compression Rate (圧縮率)
14. 14 Summary - 有望に見えるが、プロダクトで使用する場合は様々な工夫が必要そう - 精度改善、コスト削減、レイテンシー改善に期待ができるため、引き続き調査中 Future work - 条文レベルプルーニング - 契約書の構造を利用する - コンテキストを担保する - LLMまたは別のモデルでプルーニングをするかを判定する - Azure AI SearchのSemantic Answers: https://learn.microsoft.com/en-us/azure/search/semantic-answers - Provenceへのクエリを拡張する - (Agent側で) 参照情報が不足した場合、再クエリを促す Future work, プロダクトに使う場合
15. ご清聴ありがとうございました