ASIMOV: Dialog Axiata PLCにおけるエンタープライズRAG
セッションについて
本プレゼンテーションでは、Retrieval-Augmented Generation（RAG）を活用して、通信エンジニアや技術者に正確でドメイン固有の支援を提供する新しい取り組みであるASIMOVプロジェクトについて掘り下げます。本セッションでは、プロジェクトで選定されたベクトルデータベースであるMilvus DBの独自の機能と、他のベクトルデータベースに対する優位性に焦点を当てます。
取り上げるトピック:
- ASIMOVプロジェクトの紹介: プロジェクトの概要、その目的、そしてこれらの目標を達成するうえでのRAGとMilvus DBの役割。
- なぜRAGなのか?: プロジェクトでRAGが選ばれた理由、従来のLLMに対する利点、そしてドメイン固有の知識の取得効率をどのように向上させるかについての議論。
- Milvus DB vs. Chroma DB and Pinecone: Chroma DBやPineconeに対するMilvus DBの利点を、パフォーマンス、開発者にとって使いやすい機能、オンプレミスストレージなどの観点に焦点を当てて示す比較分析。
- 類似性検索の最適化: Milvus DBでメタデータ属性を個別の列に再編成することにより、RAGシステムの類似性検索機能がどのように強化されるかについての洞察。
- 通信工学への影響: ASIMOVの機能が通信工学における一般的な課題をどのように解決し、設定やトラブルシューティングのプロセスを効率化し、新進エンジニア向けのトレーニングリソースとして機能するかについての議論。
本セッションに参加することで、通信工学におけるRAGとMilvus DBの可能性について、より深く理解できます。この分野でよくある課題に対処し、運用効率を高める方法を学べます。本セッションでは、ベクトルデータベースの選択について十分な情報に基づいた意思決定を行い、ユースケースに最適な形でそれらを活用するための知識を身につけることができます。
本日は、本日のセッションに、スリランカの、えー、主要な通信事業者であるogataのAsim Enterprise Ragと、ゲストスピーカーの、えー、Bindu、Aita、Nulaをご紹介できることを嬉しく思います。彼らは、通信エンジニアや技術者に正確なドメイン固有の支援を提供するために、レトロ拡張生成、または通常ragとして知られるものを活用する、新しい取り組みについてお話しします。DUは、General Sir JohnKote, lava Defense Universityで電子通信工学の理学士号を取得しており、これはかなり長い名前ですが、英国のRobert GoldenUniversityでビッグデータ分析の修士号も取得しています。彼は2014年にインターンとしてDialogueでキャリアを開始し、その後2016年に製品開発のシニアエグゼクティブとして正社員チームに移りました。現在は、ネットワーク分析および自動化のリードエンジニアとして勤務しています。
彼の専門分野は、データサイエンス、AI、機械学習、ビッグデータ分析、クラウドエンジニアリング、ネットワーキングにまたがっています。詳細として、general search on Tel Lavaの卒業生であり、Defense Universityでも、えー、コンピューターサイエンスの理学士号を取得しています。えー、コンピューターサイエンスの理学士号です。失礼しました。
彼は2021年にインターンとしてdialogueでの歩みを始め、ネットワーク分析および自動化のシニアエグゼクティブの役割へと進みました。彼はデータサイエンス、AI、機械学習の専門家でもあります。また、データエンジニアリングにおいても顕著な熟練度を持っています。そして最後に、Nalaです。彼はgeneral surgeon, Kova DA Events Universityの卒業生で、えー、そこで電子通信工学の理学士号を取得しました。彼は2019年にインターンとしてDialogueでキャリアを始め、製品開発のシニアエグゼクティブへと進みました。
現在は、ネットワーク分析および自動化におけるシニアデータサイエンティストとして勤務しています。彼の専門分野には、データサイエンス、AI、機械学習、地理情報システムが含まれます。仕事以外では、広報およびコミュニケーションの役割でボランティア活動をしています。皆さん、ようこそ。それでは、ステージをお譲りします。
画面を共有できます。えー、ありがとうございます、Steven。えー、できれば、えー、画面を共有します。えー、皆さんに私の画面が見えていることを願います。はい。
えー、はい、えー、ありがとうございます。えー、紹介については、えー、Stevenがすでにしてくださったので、長くはしません。えー、皆さん、ようこそ。えー、このセッションにご参加いただきありがとうございます。そして、このセッションを実施するために私たちを招待してくださったrisにも、えー、感謝します。えー、それでは早速始めます。えー、本日取り上げたい内容について少し。
えー、まず、ogataのwhoと、プロジェクトに関するAsimovについて簡単に紹介します。えー、その後、Asimovのアーキテクチャと機能についてDeep diveします。えー、それから、特に、えー、なぜこの製品のためのベクターデータベースとしてMilを選択したのか、えー、そして今後予定している将来のロードマップについても話します。では、えー、私たちが誰であるかの簡単な概要です。えー、私たちOgataは、ATA Group baharの一部です。
えー、現在、私たちはスリランカ最大の、えー、接続プロバイダーであり、島全体で1,700万人以上のお客様にサービスを提供しています。えー、そして、モバイルテレニー、固定テレニー、えー、デジタルテレビ、国際サービス、デジタルファイナンス、Enterprise Servicesのサービスを提供しています。えー、1993年に設立されたので、30年以上のサービス実績があります。えー、そして、えー、その年月を通じて、南アジアおよびスリランカにおける技術の先駆けを主導してきました。これには、南アジア初の2G、初の3G、初の4G、そして初の5G Trial Networkが含まれ、まもなく、えー、商用展開される予定です。えー、私たちはまた、スリランカ最大の外国直接投資家でもあり、投資額は、えー、合計で、えー、3.
250億米ドルです。ええと、そしてまたdialogueは長年にわたり、6つのGlobal Mobileを含む複数の栄誉を受けています。ええと、私たちは13年連続で年間最優秀通信ブランドに選ばれており、ええと、Shanikaで5年連続で最も価値のあるブランドにも選ばれています。そして最新の、ええと、OpenSignalの国別レポートによると、ええと、全体的な体験、カバレッジ、そして一貫性において、総合的に最高の評価を得ています。ええと、以上が私たちが何者であるかについての簡単な紹介です。
ええと、そして、ええと、dialについての簡単な紹介です。では、ええと、asmoとは何かに入る前に、ええと、RAGまたは検索生成という概念に初めて触れる方々のために、ええと、RAGとは何かを簡単に分解して説明します。つまり、ええと、RACの最初の重要な部分は、ええと、テキストデータの形で存在する知識を、ええと、多次元ベクトル空間に埋め込むことです。つまり基本的には、そのテキストデータの数学的表現です。ええと、そしてそれはこの多次元ベクトルデータで、このベクトル多次元ベクトル空間で表現されます。ええと、その結果、ええと、より関連性の高い、ええと、関連するデータが、そのベクトル空間内で互いに近くに位置するようになります。
ええと、次のステップで何が起こるかというと、ええと、私たちは、ええと、入力を埋め込みます。ええと、私たちの場合は質問になりますが、それを、ええと、初期知識を埋め込んだものとまったく同じ埋め込みモデルで、ええと、埋め込みます。そして、ええと、その後に起こることは、ええと、その質問も、ええと、ベクトル化されると、関連する情報のチャンクを、ええと、取得できるようになります。そして取得された情報は、生成モデルに渡すことができます。私たちの場合、それはtransformモデルまたはGPTであり、ええと、必要な出力を生成します。以上が、ragまたは検索拡張生成とは何かについての非常に簡単な、ええと、概要です。では、ええと、Asimovと、この製品を構築する動機を紹介します。
では、ええと、私たちは全員、ええと、dialogues group technologyの出身です。これは、ええと、dialogues engineeringに関するもので、そして、ええと、私たちのエンジニアリングスタッフに関して言うと、ええと、彼らは非常に広範な領域に取り組んでおり、ええと、さまざまな専門領域によって区分されています。つまりTelecoエンジニアリングドメインは、ええと、アクセスネットワーク、コアネットワーク、ええと、通信インフラ、電力とエネルギーで構成されています。ええと、つまり、それは非常に広い領域です。そして、ええと、そこに存在する情報量や、ええと、ドキュメントの量は、ええと、一般的な情報である場合もあれば、非常に製品またはシステム固有の情報である場合もあります。ええと、それらすべてが、ええと、日々使用されています。ええ、ここでの私たちのスタッフの業務の過程を通じてです。
ええと、Asimovで私たちが目指していることは、ええと、第一に、集中化され安全なナレッジベースを提供することです。ええと、それによって、ええと、これらすべての、ええと、すべてのリソース、すべてのドキュメント、すべてのものが、集中化された安全な、ええと、安全な場所に保存されます。ええと、そしてそこで、そこで私たちは区分化されたアクセスを提供します。つまり、私たちは、ええと、その知識へのアクセスを各人に提供しますが、それは、ええと、その人がアクセス権を持つ機密レベルに基づき、ええと、知る必要性に基づいて行われます。また、ええと、所要時間を削減し、日々のタスクにおける効率を向上させることも目的です。ええと、ええと、ええと、基本的には、彼らがさまざまな、ええと、情報源を参照するために費やす時間を削減し、ええと、その日々の、ええと、業務の中で生じる問い合わせに対して、素早く簡単に答えを見つけられるようにするためです。したがって、それが、ええと、基本的に私たちの、ええと、Asmoにおける目的です。ええと、以上が、ええと、esmoを構築するにあたっての、ええと、意図と、ええと、ええと、ええと、私たちの動機についての少しの説明です。
ええと、それでは次に、あー、Azimoの核心に、あー、踏み込み、舞台裏を見ていくために、あー、あー、ステージにお招きしたいと思います。はい、ありがとう、na、何についての、ov ですね。そう、Amberが述べたように、非常に多くの機能があるため、エンジニアリングスタッフ全体、あー、対話に対応しています。ですので、あー、これを行うためには、それがどのように機能するのかを理解する必要があります。ESMO、あー、ESMOは4つの主要コンポーネント、フロントエンド、エージェント、ベクターデータベース、そしてモデル、基盤モデルで構成されています。
それで、あー、それらはエージェントによって相互接続されています。つまり、エージェントがシステムの心臓部です。これらはすべて、あー、まあ、非常によく知られた、あー、フレームワークの上に構築されています。たとえば、フロントエンドはstreamliの上に構築されており、コアであるエージェントはplan chainの上に構築されていて、私たちのベクターデータベースです。あー、そうですね、そして、あー、open AIはopen areaに使用します。
あー、g PTモデルが私たちの基盤モデルです。では、これがどのように機能するのかをもう一歩深く、あー、この全体の中へ進んで見てみると、エージェントは、あー、チェーン、検索チェーンで構成されていることがわかります。Azimoの初期版では、あー、chainコミュニティによって開発された標準の、会話型チェーンを使用しました。その上に構築し、あー、独自の、あー、クイック、あー、クリックや、あー、機能を追加しました。あー、私たちが行ったことの一つは、あー、チェーン上のフィルター機能を拡張したことです。
そして、あー、メタデータフィルタリング機能を使用しました。そこで、ミドルウェアコレクションに複数のメタデータフィールドを追加しました。そしてそこから、ユーザーがドキュメントの種類を絞り込めるようにし、機能を向上させ、あー、システムが返す回答や応答を改善できるようにしました。ここで変更できるもう一つの要素、あー、はK値です。ここでのK値はチャンク数、チャンクの数です。
これは重要です。なぜなら、あー、チャンク数を増やすと、あー、LLMによって返される応答がよりニュアンスのあるもの、またはより洗練されたものになるからです。ですが、これらすべては、あー、特定のガイドラインに従って、あー、一定の方法で行う必要があります。これはプロンプトテンプレートを使って行われます。つまり基本的に、非常にシンプルなプロンプトテンプレートがある場合、たとえば、これは非常にシンプルなプロンプトではありませんが、あー、中程度または、あー、平均的なレベルのプロンプトです。このようなものがあると、システムは良い出力を返します。
しかし、応答の仕方やチャンクの分析方法について正確なガイドラインを与える、非常に明確で、うまく、あー、定義された、あー、プロンプトがあれば、LLMは非常に豊かな、または非常に、あー、洗練された出力を返します。ですので、あー、私たちが開発したIMOの特別な版がありましたので、それについては後ほど説明します。それは非常に、あー、洗練された出力を与えてくれました。あー、つまりカスタムビルドでした。ここでわかるように、あー、私たちは質問、質問、チャット履歴、そしてコンテキストを組み込んでいます。質問とは基本的に、ユーザーが、あー、システムに尋ねる内容です。
つまり、あー、ユーザーが質問するたびに、たとえば、何が、あー、何が、あー、無線アンテナなのか、というようなことです。質問はここに入ります。次に、あー、チャット、チャット履歴は、あー、ユーザーがそのセッション内で、あー、あー、蓄積したすべての以前のチャットです。ですので、あー、これは、あー、チャットが続くたびに、あー、ユーザーがチャットボットとのチャットを続けるたびに増えていきます。これは、あー、可能な限り増えることができますが、ここには一定の制限があります。
あー、コンテキストは、あー、あー、ベクターデータベースから取得されたチャンクまたはデータです。これについては後ほど説明します。これらすべてがテンプレートから入力され、LLMに渡されます。つまり、システムの頭脳、システムの頭脳であり、基盤モデル、またはlmsです。あー、私たちのプレリリースでは、GPT、あー、3. 5.を採用しました。
ええと、これにはコンテキストのドラフトがあり、ええと、16,000トークンでした。なので、プレリリースまたは、ええと、ovの初期バージョンには十分でした。ええと、そのときは非常に小さいチャンク、または、ええと、1,024、ええと、トークンのチャンクがありました。なので非常に小さく、十分でしたが、ええと、ローンチ版でGB fourに切り替えたとき、ええと、そこには千、ええと、128Kトークンのコンタクトセンターがあり、応答が改善されたことがわかりました。そしてGB fourはより高度なので、応答はより明確になり、ええと、より洗練された応答が出されました。ええと、でも、ええと、これも問題ありません。ただGBD fourには問題がありました。なぜなら、応答がユーザーに返ってくるまでに比較的長い時間がかかったからです。というのも、一部のプロンプトは2分くらいまでかかったからです。
そしてこれは、ええと、ユーザー体験に影響を与えました。なので、ええと、g BT four Oが出るとすぐに試験を行い、GB fourに切り替えました。そして、ええと、今ではユーザー体験は本当に良くなっています。なぜなら、今では平均して1応答あたり約20秒、ええと、で得られるからです。ええと、もう一つ行ったことは、Azure Open Air Serviceを利用したことです。この主な理由は、ええと、プライバシー条項です。なぜなら、ええと、Azureは、私たちがopen airに送るプロンプト、ええと、その、その、openning、ええと、surveysが記録されたり、モデルの再学習に使われたりしないことを保証しているからです。
これは私たちにとって大きな、ええと、懸念事項です。なぜなら、ええと、私たちは常にチャンクやドキュメントを機密に保ちたいと思っていたからです。なぜなら、ベクターデータベースに保存されているドキュメントのほとんどは会社機密であり、時には部門機密だからです。なので、すべてを安全に保ちたいと考えていました。これもまた、私たちが選んだもう一つの理由です。なので、aがこれについて後で、ええと、詳しく説明します。なので、もし必要なら1つ作ってください。
はい。わかりました。では、考える必要があったもう一つの要素は埋め込みモデルでした。なので、私たちは、ええと、一般的に、all Minを使いました。これは一般的に性能が良いモデルの一つです。長い間、良好な性能を示してきました。
なので、ええと、それを汎用の、ええと、ドキュメントに使用しました。すると、技術文書、手順書、さらにはビジネス文書から、本当に良い応答が得られました。なので、私たちにとっては十分でした。しかし、ええと、埋め込みモデルを、by、ええと、またはfollow irのようなものに変更したとき、性能が変わることがわかりました。ベクトル空間が変わり、ええと、モデルがテキストのより多くの、より多くの、ええと、属性を拾えるようになったため、応答はより、ええと、洗練されました。
ええと、なので、ええと、私たちは、ええと、埋め込みモデルまたはベクトルの間で切り替える能力を持ちたいと考えました。なのでこれは、ええと、私たちが本当に必要としていたもう一つのことです。それから、ええと、はい、なので、ええと、これに加えて、チャンクのサイズとチャンクのオーバーラップを増やしたとき、pro the応答がより洗練されることがわかりました。そこで私たちはこれについて多くの実験を行い、チャンクサイズなどを一定量まで制限する一般的な、ええと、基準に達しました。はい、そしてフロントエンドです。
フロントエンドは、ええと、先ほど述べたように、Streamletの上に構築されています。Streamletは非常に扱いやすい、ええと、フレームワークです。ええと、ええと、ですが、Azure ADをstream rateフレームワークに統合するような特定のことについては、いくつかの回避策を設定する必要がありましたが、うまく機能しました。なので、全体の、ええと、stream rateフロントエンドは、単なるチャットインターフェースではありません。そこでチャットボットに、ええと、先ほど述べたフィルターのような追加機能を与えました。ユーザーは、ええと、ドメイン、サブドメイン、extractなどを選択し、あらゆる種類の、あらゆる種類のフィルタリングを行うことができます。
それにより、ユーザーにはそこで多くの機能が提供されます。それから、ええと、これはメタデータフィルタリングです。それから、ユーザーが最も関連性の高い、ええと、チャンク、またはユーザーにとって有用な最も関連性の高いテキストを見られるようにしました。これはフロントエンドユーザーにとって本当に良い、ええと、本当に大きなプラスポイントです。それから、ええと、私たちが行ったもう一つのことは、最も関連性の高いチャンクも表示できる機能を提供したことです。
つまり、ユーザーがドキュメントに移動して関連ページと照らし合わせて確認したい場合にも、その機能を提供しています。プロセスについてですが、先ほど申し上げたように、これは、ええと、ええと、すみません、あまり単純なプロセスではありません。ユーザーがフロントに質問を入力すると、それが long chainagent から bank chain agent に渡され、NA が先ほど述べたように、質問はベクトル空間に変換され、最も近い 10 個、つまり X 個のベクトルが vector db、この場合は middleware から取得され、それが open air service に送られます。そこからレスポンスを取得します。これが SMO の一般的なフローです。
それで、ですが、私たちは現在、これを基にしたカスタムの chain を構築しているところで、それによりフローを少し変更する自由度が高まります。というのも、今後パイプラインにいくつか興味深いものが控えているからです。それについても後ほど説明しますよね？それから、もう一つ私たちが実現したかったことは、ユーザーが自分自身のドキュメントをアップロードし、そのドキュメントに対してクエリできる能力、または自由を与えることです。なぜなら、通常、技術チームや技術スタッフは、更新されたドキュメントや新しい技術マニュアル、たとえば 3G PPP リリースを受け取り続けるからです。そのため、それらを読み込ませて、常に最新情報を取得できる能力が必要になります。このために、ユーザーが特定のベンダー、またはドメインやサブドメインに応じてデータをアップロードできる別のフロントエンドを開発し、これらの特定のドキュメントからも関連情報をクエリできるようにしました。
これにより、ユーザーには非常に大きな自由度が与えられます。はい、これがフロントエンドでのロード、ドキュメントをロードするフロントエンドの一般的なフローです。次にドキュメントがロードされます。バックエンドには別の detail model があり、ドキュメントを取り込んでから、ドキュメントを個別のチャンクに分割することで e model のフローを実行します。その後、それを embedding model に通し、vector database にロードします。
はい、これが全体的な詳細アーキテクチャフローです。ですので、次に、なぜ私たちが ware を選んだのかについて説明してもらうことになると思います。そして、その理由については本当に良い理由がいくつかあります。では、お願いします。ありがとうございます。ええと、本日は皆さんお集まりいただきありがとうございます。このプロジェクトに取り組むにあたり、私たちは自分たちのアイデアを実装するために、スケーラブルでかなり柔軟なソリューション群が必要になることを理解していました。最初は小規模に始まりましたが、大規模な、そして大規模スケールのプロジェクトになり得ることはわかっていました。というのも、すぐに上層部や、それを聞いた全員の関心を引いたからです。
そのすべてを念頭に置いて、私たちはいくつかの具体的な要件を探していました。特に、データベースのスケールやそれに関連するすべてのことについてです。ええと、VUS にはいくつかの、というより多くの機能がありましたので、その中で私たちの目を引いた機能をいくつかご紹介します。vus は、複数の embeddings をサポートしています。これが主な機能です。先ほど説明したように、私たちは all main や by embedding、そしていくつかの他の embeddings を試してきましたが、Ware はそれらすべてをサポートしており、必要な a p や SDKs もすべて含まれています。サポートや、ええと、Python mills collect connectors もあります。
そのため、これを自社の on-prem サーバーの一つに組み込み、構築して稼働させるまでの移行は、利用可能な他のいくつかのデータベースと比較すると、かなり便利でした。mails は、主に on-prem と cloud hosting capabilities という柔軟なホスティング機能を提供します。私たちの具体的な要件は、データを外部と共有しないことでした。そのため、データベースを自社の on-prem server の一つに含める必要があり、was は、chroma や BV eight などの他のデータベースと並んで、その点で有力な候補でした。それについては、さらに詳しく説明します。
うん。ええと、それ、クラッシュしましたよね？ つまり、SoMiller は動的ノード割り当てをサポートしています。それが何をするかというと、いえ、またクラッシュしました。はい、今また見えます。ああ、すみません、切断されたみたいです。
皆さん、すみません。技術的な問題です。戻ってきました。すみませんでした。続けてもいいですか、Ross のところまで戻れますか、それともはい。
ええと、ちょうど、あなたは私たちが DB などを andro していることに触れていて、それから始めかけていたので、ここからもう一度始めてください。わかりました。では、ええと、VO はオンプレミスでデプロイ可能なベクターデータベースの有力候補でした。その他の主要な機能には、ええと、分散アーキテクチャとパーティショニングがあり、これは、ええと、bu に含まれています。動的ノード割り当てが行うことは、ワークロードの増加、つまりデータベースのサイズや、ええと、pay calls、アクセスポイントなど、すべてがスケールアップされる際に、これを動的に処理するということです。ええと、かなりスムーズで、負荷も分散されます。ですので、手動での介入はほとんど必要ありません。ええと、すべて自動で行われます。そして、含まれているもう一つの主要機能があり、それがパーティショニングです。
パーティショニングを含めることで、ええと、メモリ利用の効率を最小化し、向上させることができます。ええと、特定のユースケースに基づいてパーティションを分けることができます。そして、ええと、パーティションが行うことは、データセット全体を取得する必要がなく、特定のパーティションだけがアクセスされ、メモリにロードされるようにすることです。ですので、ええと、私たちのユースケースでは、ええと、私たちが行ったのは、ベンダー、または前のスライドの UI でご覧いただいたいくつかのフィルターのいずれかでパーティションを分けることです。そのパーティショニングに基づいて、ええと、そこがアクセスされます。
これらは私たちの目を引いた機能の一部ですが、主な、他の候補ではなく mailbu を選んだ理由となる主要機能は、これらの、ええと、これらの具体的な点でした。まず第一に、オープンソースであり、素晴らしいコミュニティサポートがあります。つまり、ええと、私たちはこのウェビナーに招待されましたが、それ自体が何かを物語っていますし、ええと、いくつかの質問を問い合わせようとした際に、middle チームから、ええと、ソーシャルメディアで連絡を受けました。ですので、オンラインの、ええと、フォーラムなどでも素晴らしいコミュニティサポートがあります。ええと、もう一つの機能はオンプレミスデプロイメントでした。
これは私たちの主要要件の一つで、データを組織内に保持し、他の組織に渡さないようにする必要がありました。ええと、これには一定の制限が伴いました。というのも、データベースはまだ進化している途中で、良好で、ええと、安定したレベルに達しつつあり、そして非常に優れたパフォーマンスを発揮する競合が数多く存在していたからです。しかし、ええと、私たちは主に Chroma DB をテストしましたが、テストしたところ、ええと、より高い、ええと、秒間クエリ数があることがわかりました。そして、データバックアップと移行のサポートがはるかに優れていました。つまり、はるかに優れたパフォーマンスを発揮し、データをクエリする際に、より高い精度で低い、低いレイテンシを実現していました。
もう一つの主要機能がハイブリッド検索で、ええと、これは、埋め込まれた、ええと、埋め込みデータ以外のクエリデータを含みます。ですので、前の、ええと、UI インター、ええと、UI でご覧いただいたように、ええと、g でも、ええと、特定のドキュメントセットをフィルターで絞り込んだり、特定のフィルターを適用したりできます。フィルターが行うことは、ええと、rad を、ええと、特定のドキュメントセットに向けることで、モデルに対してより微調整された出力を提供できるようにすることです。そしてもう一つ重要な要素は、ええと、スケーリングに関して、データセットを増やす必要があること、ええと、ユーザー数やそれに関連するすべてを増やす必要があることを私たちは理解していました。そして、ええと、ware の動的ノード割り当ては、負荷を処理するために必要なほぼすべてを私たちに提供してくれました。
はい。これで、私たちが他の競合ではなく Ware を選んだ理由の説明はまとまったと思います。ありがとうございます。ええ、はい。
はい、ありがとうございます。ええと、それでは、基本的にそれが、なぜこのプロジェクトのベクトルデータベースとしてMilを選定したのかについての内訳でした。では、Asimovの今後についていくつか説明します。現在取り組んでいることの一つは、これをさらに別のドメインへ拡張することです。エンジニアリングの技術スタッフと取り組んでいる一方で、社内全体の他のユースケースへこれを拡張できる可能性も見えてきました。最近の例の一つとして、当社のコーポレートプランニングチーム向けに、Asimovのカスタム版を開発することができました。
それにより、最近開催されたdialoguesの年次株主総会に向けた特定の文書を準備する際に、彼らを支援することができました。このように可能性をもたらすユースケースがあります。ですので、コーポレートプランニングや規制対応のような、さらに別のドメインへの拡張が視野に入っています。そしてそれに関連して、各ユースケース向けのプロンプトテンプレートのリポジトリも作成する予定です。
それにより、基本的に体験を調整し、各特定のユースケースに関してMの応答を改善するのに役立ちます。ですので、各ユースケース向けのテンプレートのリポジトリを確立することは、現在計画中のものです。また、当社の技術文書に関しては、多くのグラフやさまざまな図などがあります。そこで、GPT-4のマルチモーダル機能を活用して、よりリッチなドキュメント読み込みを行う予定です。そこでは、GBT four ohに画像ベースの情報の説明を提供させます。そうすることで、読み込む文書に関して、より豊かなコンテキストを得られるようになります。
これも私たちが検討しているもう一つのことです。また、データとのチャット機能を実現することも考えています。これは必ずしもRAGではありませんが、可能性があると見ている領域です。そこで、当社の内部ネットワーク構成やパフォーマンスデータベース、さらにopen signal metaが提供するようなクラウドソースのインテリジェンスデータベースとの接続性を提供する予定です。そうすることで、Asimovに関して、またVatiが当社のエンジニアに提供できるものに関して、より大きな機能性を持たせることができます。はい。以上が基本的に簡単な概要です。ご質問があれば、喜んでお受けします。
Stevenさん。おお、プレゼンテーションをどうもありがとうございました。お話を聞けて本当にとても面白かったです。参加されている方で質問があれば、ぜひチャットで聞いて、読む、書いてください、すみません。なければ私自身からいくつか質問があります。
では、それらから始めてもよいかもしれません。その後、様子を見ましょう。まず最初の質問ですが、現在直面している規模はどのくらいなのか、つまり、何人くらいがあなた方のRAGシステムを使っているのかということです。ええと、現時点ではエンジニアリングスタッフだけで、コアのエンジニアリングスタッフです。その中には、実際にかなりよく使っているプランニングチームが含まれます。はい、彼らが実際によく使っている人たちです。ですので、およそ50数名です。彼らが使っています。また、見ていると、何人かも来て、彼らは、Nandoが述べたように、私たちはこれらのチームと非常に密接に協力して、プロンプトテンプレートを開発し、応答を改善しました。
ですので、彼らは出力を洗練することに関与していました。それで彼らはこのシステムにかなり興味を持つようになりました。そのため、彼らは日常的に使っています。わかりました。いいですね。
それに関連して、たぶんフォローアップの質問があります。なので、もしかすると共有していただけるか分かりませんが、現在、中間にどれくらいのベクトルがありますか、おおよそで？ええと、たぶんそれで良いイメージがつかめると思います。共有できないかもしれませんが、ええと、ベクトルの数は共有できますが、ええと、その、コンテンツの詳細については、ええと、お伝えできません。ああ、大丈夫です。では私がそれについてコメントできます。ええと、現在は170万ありますが、日々増加しており、より多くのドキュメントを、ええと、さまざまなドメインで追加しています。
ええと、技術文書や企業文書です。なので、画像やその他のマルチモーダルな、ええと、ええと、要件を必要とするドキュメントを、ええと、別の次元として含めることを計画しています。なので、そこから増え続けることになりますが、現在はだいたい、ええと、約172万くらいです。わかりました。
わかりました、いいですね。ありがとうございます。ええと、それから質問があります。ええと、サービスは高可用性をサポートしていますか？ええと、皆さんが、ええと、これに答えたいかどうか分かりませんが、そうでなければ私が答えられます。ええ、対応しています、ええ、サポートしています。
これは私が答えます。ええと、高可用性はサポートしています、はい。ええ、対応しています。それから、ええと、クラウド提供もあり、そこでも、ええと、高可用性があります。99です。
99パーセントくらいです。なので、はい。ええと、それからもう一つ質問があります。たぶん、なので、たとえば、その、たぶん将来により関係することです。ご存じのように、現時点では、ええと、人々はragについて話していますが、ええと、その一方でadvanced ragと呼んでいるものもあります。なので、たとえばエージェントとかを試してみることを考えているようなものですか、あるいは、ええと、質問を分割すること、つまり、たとえばユーザーが非常に長い質問を1つした場合に、質問を複数に分割したい、というようなことです。
ええと、これは現在検討していることですか？ええと、はい、そうですね、一般的にユーザーに関して言うと、彼らは、ええと、多くのフォローアップ質問をします。なので、わかりました。チャット履歴機能と、ええと、そして、ええと、チャット履歴は回答を大きく改善するのに役立ちました。ただ、ご指摘のadvanced rackについては、ええと、昨日、rafという新しい論文を見つけたと思います。たぶん、ええと、Nalaがそれについて少し説明できると思います。はい。ええと、私たちが調べたもの、ええと、昨日調べていたものは、ええと、augmented fine tuningでした。
なので、ええと、私たちがやりたいことの一つは、ええと、時間とともに、ええと、ユーザーフィードバックも実装することです。わかりました。ええと、そうすることで時間とともに、ええと、回答の良いコレクションと、それらの回答がユーザーにとってどれほど良く、どれほど関連性があったかを持てるようになります。ええと、そこで私たちが使えるもの、できることは、ハイブリッドな、ええと、ええと、rackプラス、ええと、ファインチューニングモデルに進むことです、はい。ええと、そこで私たちは、ええと、それらの、ええと、ユーザーから得る出力やフィードバックを使って、ええと、GPTをファインチューニングし、ええと、基本的に、ええと、より正確にすることができます。
そして、ええと、なので、なので、ええと、Dulingが言及していた、ええと、raf、ええと、retrieval, augmented fine tuningです。ええと、これはかなり新しい概念で、ええと、関連ドキュメントだけでなく、紛らわしいドキュメントも使って、ええと、LLMを、ええと、学習、ええと、ファインチューニングすることを含みます。ええと、そして基本的に、私たちはLLMに、ええと、ええと、チャンクが与えられたときに、ええと、関連情報だけを取り込むように教えます。ええと、なので、ええと、それも昨日見ていた興味深いことの一つです。なので、ええと、はい、そのようなことを、ええと、将来的に実装したいと思っています。
はい。わかりました、いいですね。ありがとうございます。それに追加すると、すみません、それに追加すると、なので、この、ええと、draftに関しては、ええと、埋め込みモデルへの依存を減らせるようになると思います。なぜなら、それはreシステムの重要な部分だからです。はい。
つまり、トップを取るには一流の埋め込みモデルが必要ですが、draft を使えば、ええと、be bundle への依存を減らして、その複雑さや、ええと、その知能を LLM に委ねることができます。そこから、ええと、より良い応答を得ることができます。ああ、そうですね、そうですね。つまり、それらは非常に重要です。ええと、多くのモデルは通常、結果に大きな違いをもたらします。
ええと、わかりました、いいですね。確認します。もう質問はないと思います。ですので、その場合は、あなたにありがとうと言いたいです。プレゼンテーションありがとうございました。とても有益でした。
ええと、録画はオンラインで共有されます。ええと、なので心配しないでください。もし一部を見逃した場合は、ええと、ぜひ私たちのウェブページもチェックしてください。vis tayo です。GitHub でも直接チェックしてください。そして改めて、ええと、dialogue にも感謝します。最初にブログ記事を書いてくれたことに対してです。
それが、そもそも私たちが彼らを知ったきっかけでした。ご存じのとおり、彼らの知識を共有してくれたのです。そして、はい、また次回お会いしましょう。ええと、素敵な朝、昼、夜をお過ごしください。改めてありがとうございます、皆さん、ここで講演してくださって。Love。
そちらではもう遅いので、素敵な夜をお過ごしください。ありがとうございます。ありがとう、Steven。ありがとうございます。
Join the Webinar
Loading...
Meet the Speaker
Join the session for live Q&A with the speaker
Dumindu Ranasinghearachchi
Lead Engineer in Network Analytics and Automation at Dialog.
Dumindu Ranasinghearachchi holds a Bachelor of Science in Electronic and Telecommunication Engineering from General Sir John Kotelawala Defence University and a Master’s in Big Data Analytics from Robert Gordon University, UK. Dumindu embarked on his career with Dialog in 2014 as an intern and transitioned to the permanent team in 2016 as a Senior Executive in Product Development. Currently, he serves as the Lead Engineer in Network Analytics and Automation. His expertise spans Data Science, AI/ML, Big Data Analytics, Cloud Engineering, and Networking
Aditha Iddamalgoda
Senior Executive
Aditha Iddamalgoda is a graduate of General Sir John Kotelawala Defence University, holding a Bachelor of Science in Computer Science. He began his journey with Dialog as an intern in 2021 and has since advanced to the role of Senior Executive in Network Analytics and Automation. Aditha is a specialist in Data Science and AI/ML, with a pronounced proficiency in Data Engineering.
Nandula Asel Karunasingha
Senior Data Scientist
Nandula Asel Karunasingha is an alumnus of General Sir John Kotelawala Defence University, where he earned his Bachelor of Science in Electronic and Telecommunication Engineering. He started his career at Dialog as an intern in 2019, progressing to a Senior Executive in Product Development by 2018. Currently, Asel serves as a Senior Data Scientist in Network Analytics and Automation. His areas of specialization include Data Science, AI/ML, and Geographic Information Systems. Outside of work, he volunteers in Public Relations and Communications roles.