こんにちは。@chaspyです。
先日こちらのイベントで登壇してきました。
発表資料はこちらです。
概要については以下の @aoi1 さんの以下のブログも参照ください。
内容は資料を見ていただきたいですが、ポイントとしては以下になります。
- 基本的には検索システムと捉えている
- AI Search がクエリの生成と検索結果から回答生成を行っている
- そのため、E2E で評価しないと実際のアプリと同様の回答が得られない
- 若干高コストにはなるが、E2E で簡易的はリグレッションテストを行っている
- とにかく素早くフィードバックサイクルを回すことが重要(ソフトウェア開発と同じ)
- ユーザに使ってもらい、評価する、自分でテストを回して、修正する、を繰り返す
- 評価手法にこだわるよりは改善を繰り返す方が大事
また、アーキテクチャの補足もしておきます。
- Client は Slack の next-gen platform
- Azure の OpenAI の on-your-data API を叩いているだけ
- ソースドキュメントは全て markdown であり、docsify や honkit などの Static Site Generator でビルドし、S3 においてホストしている
- 一部 GitHub 上の md として閲覧している
質疑応答
当日、口頭で回答した質疑について、テキストでもまとめておきます。
Azureの選定理由はありますか?セキュリティー面が理由でしょうか?
社内基準を満たしているものから選択しています。
利用機会が増えると、いいねをつけ忘れる懸念はなさそうでしょうか?悪いねスタンプなどもし検討したことがあれば知りたいです!
機会が増えるとあり得るかもしれません。そうなったときに考えようと思います! 👎 はつけてもらってないのですが、メンションしてもらうようにしています。実際は @chaspy が張り付いてるので、(自分が所属歴が長いこともあり)正しい回答をしつつ、ドキュメントの追加更新をして改善しています。
up vote(👍) だけで、down voteはさせていないでしょうか?理由があれば知りたいです。また、1-10などの数値でfeedbackを試みたことはありますか?
同上で、down vote はさせていないです。👍がつかない時点で改善が必要なので、追加ヒアリングが必要だと考えるからです。1-10 の数値での feedback は検討してないです。現状、そこまでの細かさは不要だと考えています。
検索結果1件あたり文書全体という感じですか?
いえ、分割されたチャンクになります。
今回のつらみにはありませんでしたが、検索速度に関してこれまで何かの改善に取り組んだことはありますか?あれば教えてほしいです!
gpt-4o にすると早くなりました!!!実際、ここの api 呼び出しが支配的だと思います。
LLMには1文書全体を渡したということですか?長すぎることによる問題はコスト以外にありますか?
LLM には検索結果のチャンク上位3件を渡しています。チャンクが大きすぎると、コスト以外だと検索精度の低下が懸念されると思います。ただ、現状検索でクリティカルな問題には遭遇してないため、検索やチャンクサイズのチューニングは行っていません。
社内向けのアプリということですが、月間いくらくらいのコストでしたか?さきほどの方は800ドルとのことでしたが。。。
Azure AI Search が Basic プランで 21.37円/時間、30日で15386円になります。
これに加えて、RAG の呼び出しが gpt-4o だと1回あたり10円です。今のところ許容範囲だと考えています。
チャンクの分割単位はどの程度ですか?
Skillset を確認しました。以下の部分になるかと思います。
{ "@odata.type": "#Microsoft.Skills.Text.SplitSkill", "name": "#2", "description": "Split skill to chunk documents", "context": "/document", "defaultLanguageCode": "en", "textSplitMode": "pages", "maximumPageLength": 2000, "pageOverlapLength": 500, "maximumPagesToTake": 0, "inputs": [ { "name": "text", "source": "/document/content" } ], "outputs": [ { "name": "textItems", "targetName": "pages" } ] }
maximumPageLength が文字数になると思うので、2000文字程度で、500文字の overlap を許容するという設定になっています。
実際に AI Search で検索して確認してもその程度でした。ただし、markdown なので、link は文字数がかなり多くなるため、実際に読む文字数はもう少し小さくなると考えた方が良さそうです。
何名ぐらいで使われてますか?
対象の開発者は100名ほどいますが、実際に1回以上使ったことあるのは20名程度かと思います。
感想
「つらみ」を共有というテーマが発表者のハードルをいい感じに下げてくれて、非常に良いテーマ設定でした。発表の機会をいただきありがとうございました!
また追加で質問あれば @chaspy まで気軽に連絡ください!
Appendix: 他の方の発表資料
いちかわさんの発表。Google Drive をソース元にしようとしたができず、S3 をソースにしたとのこと。問い合わせの履歴を DynamoDB に保存していました。かなり社内で使われており、サーベイも実施しているところは今後真似したいと思いました。Kendra の利用料は高いですね...
山口さんの発表。Dify を GCP 上にセルフホストしていました。Dify 良さそうだなと思いつつまだあまり触れてないので、できることできないことかなり参考になりました。うちも社内でセルフホストしたい...
いでみつさんの発表。pdf をデータソースにしているとのことで、Azure Document Inteligence サービスを使っていました。RAG の回答精度評価に Azure プロンプトフローの事例を紹介いただきました。CLI は便利っぽいですよね、使ってみたい。VSCode 拡張もかなり良さそうでした。