よりスマートなRAGパイプライン：MilvusとFeastで検索をスケールする
このウェビナーについて
Milvus と Feast を組み合わせて使用し、オープンソースを活用してベクトル検索をスケールさせ、検索用のビューを簡単に宣言する方法を学びます。Milvus と Feast を統合して、カスタマイズされた RAG パイプラインを構築する方法をデモします。
取り上げるトピック
- Feast を活用して動的メタデータとドキュメントの保存および検索を行い、推論時に常に正しいデータを利用できるようにする
- Feast と Milvus を統合して、RAG システムにおけるベクトルベースの検索をサポートする方法を学ぶ
- Milvus を使用して高速な高次元類似度検索を行い、RAG モデルの検索フェーズを強化する
WEBVTT
1 00:00:03.805 --> 00:00:05.825 本日は、セッション「Milvus
2 00:00:05.825 --> 00:00:07.585 と Feast による、よりスマートな RAG
3 00:00:07.585 --> 00:00:10.145 パイプライン」にゲストスピーカーの Francisco をお迎えできてうれしく思います。
4 00:00:10.895 --> 00:00:12.785 彼は Red Hat のシニアプリンシパルエンジニアで、
5 00:00:12.925 --> 00:00:15.865 AI
6 00:00:15.925 --> 00:00:18.065 と ML、さらにソフトウェア、FinTech
7 00:00:18.125 --> 00:00:21.985 と AI、LAIG、Commonwealth Bank of Australia、
8 00:00:22.335 --> 00:00:25.865 Goldman s Sans、Goldman Sachs、失礼、fast Affirm で10年以上携わってきました。
9 00:00:25.925 --> 00:00:28.825 そして Red Hat での役割は、ソフトウェアから
10 00:00:29.125 --> 00:00:30.545 データエンジニアリング、クレジット、不正検知、
11 00:00:30.545 --> 00:00:31.945 データサイエンス、機械学習にまで及びます。
12 00:00:33.005 --> 00:00:36.225 彼は経済学と統計学、
13 00:00:36.285 --> 00:00:39.505 およびデータサイエンスと機械学習の大学院学位を Columbia University、
14 00:00:40.285 --> 00:00:43.945 えー、ニューヨーク市の Columbia University と、また Clearstone University で取得しています。
15 00:00:44.415 --> 00:00:47.465 彼はオープンソースのフィーチャーストアである Feast のメンテナーで、
16 00:00:47.565 --> 00:00:49.825 Cube Flow の運営委員会メンバーでもあります。
17 00:00:50.315 --> 00:00:52.745 これは AI のための Kubernetes のオープンソースエコシステム
18 00:00:52.745 --> 00:00:54.185 コンポーネントで、
19 00:00:54.185 --> 00:00:57.905 そして ML です。Francisco、ステージはあなたのものです。どうぞ始めてください。
20 00:01:00.505 --> 00:01:03.405 皆さん、こんにちは。えー、Francisco です。お会いできてうれしいです。
21 00:01:03.465 --> 00:01:06.005 よろしくお願いします。えー、帽子を脱ぎますね、えー、
22 00:01:06.065 --> 00:01:09.885 ただ、ウェビナーのプロフィール写真との一貫性のために、あの、あの、
23 00:01:09.905 --> 00:01:12.565 あのウェビナーでは、これをかぶって登場しようと思ったんです。
24 00:01:12.985 --> 00:01:15.725 えー、それでは、えー、今日は、えー、
25 00:01:15.775 --> 00:01:20.045 Feast、Rag、Milby についてお話しします。そして画面を共有します。
26 00:01:21.715 --> 00:01:25.535 えー、皆さん、はい。チャットで知らせてください。はい、完璧です。
27 00:01:25.845 --> 00:01:29.015 確認できました。えー、素晴らしい、素晴らしい。
28 00:01:29.275 --> 00:01:31.535 では始めていきましょう。
29 00:01:31.955 --> 00:01:35.095 えー、では、えー、あの、えー、
30 00:01:35.935 --> 00:01:37.525 peace RVIs、それが今日お話しする内容です。
31 00:01:38.585 --> 00:01:42.245 えー、皆さんに私のことを少しお話ししようと思ったので。
32 00:01:42.525 --> 00:01:44.085 すでに紹介されたと思います。
33 00:01:44.345 --> 00:01:46.525 えー、あの、でも少し背景をお伝えしたかったんです。
34 00:01:47.205 --> 00:01:51.005 私は、あの、過去12年以上にわたってさまざまな
35 00:01:51.165 --> 00:01:52.285 企業でデータサイエンス、データエンジニアリング、
36 00:01:52.485 --> 00:01:53.645 ML インフラチームを率いてきました。
37 00:01:53.825 --> 00:01:57.165 えー、そしてどういうわけか Feast のメンテナンスをすることになりました。
38 00:01:57.225 --> 00:02:00.325 えー、えー、以前働いていた会社でそれを出荷し、
39 00:02:00.325 --> 00:02:04.045 本番環境でスケールさせました。
40 00:02:04.185 --> 00:02:08.165 チェックアウト決済向けに、えー、あの、信用リスク
41 00:02:08.165 --> 00:02:11.925 と不正検知モデル向けに、えー、そこでは低レイテンシの取得が、
42 00:02:11.925 --> 00:02:13.565 本当に、本当に重要な部分です。
43 00:02:13.625 --> 00:02:15.805 そして、えー、高い回復力と稼働率も重要です。
44 00:02:15.905 --> 00:02:19.805 それで、えー、私はキャリアの中でモデルを構築し、
45 00:02:19.825 --> 00:02:21.165 そしてモデルを出荷することに取り組んできましたし、
46 00:02:21.225 --> 00:02:23.325 それはデータに大きく依存しています。
47 00:02:23.465 --> 00:02:25.245 ですので、繰り返しになりますが、それがある意味で
48 00:02:25.245 --> 00:02:26.485 私が Feast に行き着いた経緯です。
49 00:02:26.865 --> 00:02:29.245 えー、あの、以前は昔ながらのやり方でやっていましたが、
50 00:02:29.305 --> 00:02:32.525 その後、最終的にはより新しい、えー、
51 00:02:32.595 --> 00:02:34.845 モデルを提供する、より構造化された方法です。
52 00:02:35.505 --> 00:02:39.165 ええと、私は去年、ほぼちょうど一年前に Red Hat に入社しました、ええと、
53 00:02:39.905 --> 00:02:41.325 オープンソース AI に取り組むためです。
54 00:02:41.325 --> 00:02:43.685 そして Feast に取り組めることをとても光栄に感じていますし、
55 00:02:43.705 --> 00:02:46.045 それから、そうですね、ええと、Q Flow
56 00:02:46.105 --> 00:02:49.205 や他のコミュニティにも関わり、ええと、本当に、そうですね、
57 00:02:49.715 --> 00:02:53.685 AI がオープンであり続けるようにすること、そして、
58 00:02:53.685 --> 00:02:55.725 オープンソースの最良のものを活用することに取り組んでいます。
59 00:02:56.425 --> 00:02:59.245 ええと、私には妻と2人の子どもがいて、それから、
60 00:02:59.265 --> 00:03:00.605 ニュージャージーを故郷と呼んでいます。
61 00:03:00.805 --> 00:03:02.845 この写真はサウスダコタにいたときに撮りました。
62 00:03:02.965 --> 00:03:05.085 以前は西部に住んでいました。ええと、とても良い時期でした。大好きです。
63 00:03:05.425 --> 00:03:09.005 ええと、ワイオミングの近くの Rapid City です。ええと、それが私です。
64 00:03:09.545 --> 00:03:11.625 では、見てみましょう。
65 00:03:14.365 --> 00:03:17.225 まずは少し歴史的な文脈から始めたいと思いました。
66 00:03:18.185 --> 00:03:20.265 RAG はかなり人気があります、ええと、
67 00:03:20.805 --> 00:03:23.225 でも多くの場合、人々は元の論文を読んでいなかったり、
68 00:03:23.445 --> 00:03:25.025 元の論文について知らなかったりします。
69 00:03:25.725 --> 00:03:28.025 なので、その簡単な歴史と背景をお話ししようと思いました。
70 00:03:28.405 --> 00:03:31.385 それで、ええと、RAG は
71 00:03:31.385 --> 00:03:32.785 Retrieval Augmented Generation の略です。
72 00:03:33.045 --> 00:03:36.705 つまり、2020年に NIPS で発表された PA 論文で、ええと、
73 00:03:36.725 --> 00:03:38.345 Meta AI の研究チームによるものです、
74 00:03:38.405 --> 00:03:41.345 あるいは当時は Fair Facebook AI Research と呼ばれていました。
75 00:03:42.005 --> 00:03:46.345 ええと、そして、ああ、2つ目の箇条書きで
76 00:03:46.345 --> 00:03:48.185 この部分を仕上げるのを忘れていたようです。
77 00:03:48.185 --> 00:03:51.205 ともかく、ええと、その、その、
78 00:03:51.265 --> 00:03:55.605 そのアーキテクチャでは、ええと、そうですね、
79 00:03:56.395 --> 00:03:57.965 今日では人々がやや省略していることについて話していました。
80 00:03:58.115 --> 00:03:59.885 実際には2つのモデルが使われていました。
81 00:03:59.885 --> 00:04:02.005 retriever と呼ばれるものがあり、ええと、
82 00:04:02.005 --> 00:04:03.285 その図の中にあります。
83 00:04:03.285 --> 00:04:05.885 論文からスクリーンショットを撮りました、ええと、
84 00:04:06.825 --> 00:04:08.605 そして、ええと、generator です、
85 00:04:08.945 --> 00:04:10.605 そして query encoder がこの
86 00:04:10.605 --> 00:04:12.525 retriever というものの一部としてあります。これは、そうですね、
87 00:04:12.815 --> 00:04:15.845 私たち皆がかなりよく知っているような encoder で、
88 00:04:15.845 --> 00:04:17.845 query や文のようなものを受け取り、
89 00:04:17.845 --> 00:04:19.925 それをベクトルにマッピングしますよね？
90 00:04:20.025 --> 00:04:21.365 ええと、数値の集合で、
91 00:04:21.465 --> 00:04:26.245 さまざまな長さのようなものです、ええと、それは
92 00:04:26.345 --> 00:04:27.885 選んだモデルによって決まります。
93 00:04:28.025 --> 00:04:29.605 ええと、そうですね、人々は
94 00:04:29.605 --> 00:04:33.005 584 か何かのような大きな数を任意に設定しがちです。
95 00:04:33.385 --> 00:04:34.805 ええと、通常は2の累乗です。
96 00:04:34.905 --> 00:04:37.685 ですが、ええと、そうですね、
97 00:04:37.685 --> 00:04:40.685 このことに関する議論でよく見落とされていた点の一つは、
98 00:04:41.715 --> 00:04:43.525 この Seminole 論文が出たとき、
99 00:04:43.625 --> 00:04:46.285 それは retriever と generator の
100 00:04:46.625 --> 00:04:48.085 エンドツーエンドのバックプロパゲーションに関するものだったということです。
101 00:04:48.345 --> 00:04:50.925 それはどういう意味でしょうか？ つまり彼らはある種の
102 00:04:50.925 --> 00:04:53.565 モデル、何らかの、そうですね、事前学習済みの重みを取り、
103 00:04:53.625 --> 00:04:54.645 それらをファインチューニングしたということです。
104 00:04:55.185 --> 00:04:56.845 ええと、そしてそれは本当に重要な、
105 00:04:57.065 --> 00:04:58.285 ええ、基盤となる層だと思います。
106 00:04:58.525 --> 00:05:01.605 というのも、それは実際には、今日の実務における、ええと、
107 00:05:02.525 --> 00:05:04.365 ragについて人々が考えている方法や、それを使っている方法とはまったく違うからです。
108 00:05:04.365 --> 00:05:06.325 彼らはたいてい推論の観点からそれを考えています。
109 00:05:06.545 --> 00:05:07.725 そして、そしてそれは理にかなっています。つまり、それは、
110 00:05:07.725 --> 00:05:09.005 批判ではなく、ただある種の、
111 00:05:09.005 --> 00:05:10.405 事実の表明です。
112 00:05:11.025 --> 00:05:14.485 ええと、それから、そうですね、2020年、
113 00:05:14.865 --> 00:05:16.245 それは、ずいぶん前のことです。
114 00:05:16.505 --> 00:05:20.205 ええと、つまり、なぜそれほど人気になったのでしょうか？
115 00:05:20.385 --> 00:05:23.685 そして、いくつかのデータを見ると、ええと、おそらく
116 00:05:23.685 --> 00:05:27.965 chat GBTのせいです。ええ、chat GBTは、そうですね、
117 00:05:28.355 --> 00:05:32.925 2022年10月に世界を混乱させました。ええと、
118 00:05:33.355 --> 00:05:35.365 彼らは、最初のドキュメントの中で、
119 00:05:35.365 --> 00:05:36.725 ragを使うことを提案していました
120 00:05:37.225 --> 00:05:41.405 そして、in context learningのような言い回しはそれほど一般的ではありませんでした。
121 00:05:41.985 --> 00:05:43.005 ええと、そして、
122 00:05:43.905 --> 00:05:46.405 しかし人々が発見したのは、単にLLMの
123 00:05:46.405 --> 00:05:50.285 コンテキストにものを放り込むだけで、いくつかのプロンプトや、
124 00:05:50.465 --> 00:05:53.485 ええ、指示、ええ、フォーマットがあれば、かなりうまく機能するということでしたよね？
125 00:05:54.025 --> 00:05:57.285 ええと、そしてGoogle Trendsを見ると、ええと、
126 00:05:57.655 --> 00:06:00.945 ここに両方ともスクリーンショットを載せていますが、そうですね、改めて、
127 00:06:01.345 --> 00:06:03.785 2020年12月が、それが公開された時期です。
128 00:06:04.005 --> 00:06:07.505 ええと、そして見てわかるように、ほとんど、いや、まったく、
129 00:06:08.595 --> 00:06:10.815 言及がありませんが、見てわかるように、ええ、
130 00:06:11.565 --> 00:06:14.895 chat GBTが2020年10月に急伸したとき、ええと、
131 00:06:15.075 --> 00:06:19.255 その時にRACが本当に人気になり始めたのがわかります、
132 00:06:19.555 --> 00:06:20.975 少なくともGoogle Trendsによれば。
133 00:06:21.555 --> 00:06:22.895 ええと、そして改めて、それは
134 00:06:22.895 --> 00:06:24.895 彼らがドキュメントでそれを参照していたからで、そして、
135 00:06:24.915 --> 00:06:28.255 そして、そうですね、私はこれが起きた頃、ええ、
136 00:06:28.445 --> 00:06:31.455 その種のものに取り組んでいて、彼らが、そうですね、やり方を示していたopen AI demoを使いました
137 00:06:31.455 --> 00:06:34.135 彼らが、そのやり方を示していたものです。
138 00:06:34.195 --> 00:06:37.415 ええと、そして、ええ、そうですね、
139 00:06:37.595 --> 00:06:39.535 それはこのように驚くほど強力でした。
140 00:06:39.635 --> 00:06:42.295 そして、そしてそれが、今日私たちがAI engineeringと呼ぶものの
141 00:06:42.645 --> 00:06:44.255 マインドシェアを奪っていったようなものです。
142 00:06:45.415 --> 00:06:47.715 しかし改めて、ここには本当に重要なステップがあって、
143 00:06:47.715 --> 00:06:48.835 それは、私には、
144 00:06:48.835 --> 00:06:52.235 この議論から抜け落ちているように感じます。それは、ええ、
145 00:06:52.785 --> 00:06:54.675 ほとんどのragアプリケーションは推論だけを使っていて、
146 00:06:54.675 --> 00:06:57.075 それは素晴らしいことです。うまく動くことを考えれば、そうですね、ええ。
147 00:06:57.135 --> 00:06:59.475 しかし、ragには
148 00:06:59.475 --> 00:07:03.395 まったく別のストーリーがあったということにも注意することが重要です。
149 00:07:03.935 --> 00:07:05.715 ええと、そして、そしてその多くは、
150 00:07:05.715 --> 00:07:08.675 データやドキュメントをコンテキストに
151 00:07:08.895 --> 00:07:12.755 放り込んでフォーマットし、ええと、
152 00:07:13.055 --> 00:07:14.835 ベクトル類似度検索を行うのが非常に簡単だからだと思いますが、
153 00:07:15.255 --> 00:07:17.235 実際にはファインチューニングを行うのはずっと難しいのです。
154 00:07:17.495 --> 00:07:19.955 ええと、それは、まあ一種の、ええ、
155 00:07:20.915 --> 00:07:22.155 物議を醸す発言だとは思いません。
156 00:07:24.535 --> 00:07:26.435 では、馴染みのない人のために、RAGはどのように機能するのでしょうか？
157 00:07:26.635 --> 00:07:28.635 簡単な例を見ていこうと思いました。
158 00:07:28.855 --> 00:07:31.755 ええと、本当に中核となるステップは4つあります。
159 00:07:31.845 --> 00:07:34.755 1つ目は、データを埋め込むことです。たとえばドキュメントを取り、
160 00:07:35.145 --> 00:07:38.315 PDFや、あるいは何らかのトークン、何か、ブログのようなものです。
161 00:07:38.895 --> 00:07:41.035 ええと、それを埋め込むわけですよね？
162 00:07:41.035 --> 00:07:44.235 繰り返すと、すべての文を何らかのベクトル空間にマッピングします。
163 00:07:44.235 --> 00:07:45.555 つまり、そのテキストを分割する
164 00:07:45.735 --> 00:07:49.515 あるいはチャンク化する方法を見つけるわけです。
165 00:07:49.975 --> 00:07:51.395 そしてそれらの分割を取り、
166 00:07:51.395 --> 00:07:53.475 各分割を視覚的に埋め込み、
167 00:07:53.705 --> 00:07:56.675 それからそれらの埋め込みを、何らかの主識別子とともに、
168 00:07:57.095 --> 00:07:58.755 ええと、何らかのデータベースに保存します。
169 00:07:59.255 --> 00:08:02.155 そして、リアルタイムで
170 00:08:03.165 --> 00:08:05.195 ユーザークエリと呼ばれるものを埋め込みます。これは、
171 00:08:05.335 --> 00:08:06.515 チャットボットに話しかけるようなものです。
172 00:08:06.535 --> 00:08:09.475 たとえば、「ええと、米国の
173 00:08:09.855 --> 00:08:11.315 首都はどこですか？」と言うわけです。
174 00:08:11.735 --> 00:08:16.275 ええと、そしてリアルタイムで、そのクエリも
175 00:08:16.275 --> 00:08:18.635 ベクトルに埋め込むことになり、
176 00:08:18.975 --> 00:08:20.075 そのベクトルを使って
177 00:08:20.175 --> 00:08:21.955 データベース内のすべてを検索します。
178 00:08:22.175 --> 00:08:24.475 そこでVector searchやPine Coneや、
179 00:08:24.615 --> 00:08:28.035 そしてvisなどが登場し、本当に「ねえ、見てください、
180 00:08:28.035 --> 00:08:30.355 私たちは実際にベクトル類似検索をサポートしています」と言うようになりました。
181 00:08:30.375 --> 00:08:31.635 そして、これらは非常に、
182 00:08:31.985 --> 00:08:33.155 非常に広く普及し、人気になりました。
183 00:08:33.735 --> 00:08:36.075 ええと、そして、mil、これはかなり、
184 00:08:36.075 --> 00:08:37.235 かなり以前から存在していましたよね？
185 00:08:37.295 --> 00:08:41.715 ええと、これは本当に2022年よりも前のことでしたよね？
186 00:08:41.895 --> 00:08:44.915 ええと、重要なのは、
187 00:08:44.915 --> 00:08:47.515 ベクトル類似検索という構成概念は
188 00:08:47.515 --> 00:08:48.595 非常に長い間存在してきたという点です。
189 00:08:48.855 --> 00:08:53.155 そして情報検索は、ええと、かなり長い間、
190 00:08:53.155 --> 00:08:57.085 実践されてきました。標準的な、ええと、
191 00:08:57.325 --> 00:08:59.605 検索や推薦システムは、これを
192 00:08:59.605 --> 00:09:01.485 かなり長い間使ってきました。私の理解では、
193 00:09:01.485 --> 00:09:03.685 それが実際にbuが最初に始まった経緯です。
194 00:09:04.345 --> 00:09:07.965 ええと、そして最後には、そのクエリを取得し、
195 00:09:07.965 --> 00:09:09.765 Vector similarity searchでそれを取得して、
196 00:09:09.825 --> 00:09:11.685 それをコンテキストに注入し、
197 00:09:11.825 --> 00:09:12.925 そのまま進めて、
198 00:09:12.985 --> 00:09:15.725 自分のLLMに何らかの
199 00:09:15.725 --> 00:09:16.925 応答を生成させ、うまくいくことを期待するわけです。
200 00:09:17.305 --> 00:09:19.725 ええと、実際にはかなりうまく機能しました。
201 00:09:19.985 --> 00:09:23.085 ええと、では、
202 00:09:25.275 --> 00:09:26.855 では、FeastはRAGにどのように役立つのでしょうか？
203 00:09:27.455 --> 00:09:30.265 私は、ええと、
204 00:09:32.425 --> 00:09:36.375 feastは本当にfeature storeとして根付いていて、
205 00:09:36.395 --> 00:09:38.295 そしてfeature storeは本当に支援を目的としていました。
206 00:09:38.875 --> 00:09:41.655 モデルを、
207 00:09:41.935 --> 00:09:44.575 特に表形式のものを本番環境に持っていく複雑さを減らすことです。
208 00:09:44.835 --> 00:09:47.215 ええと、そして実際のところ
209 00:09:47.215 --> 00:09:48.735 モデルを本番環境に投入するうえで最も難しい部分は
210 00:09:48.735 --> 00:09:52.095 表形式の予測MLの世界においては、
211 00:09:52.595 --> 00:09:54.535 ええと、実はモデルそのものではありません。
212 00:09:54.855 --> 00:09:57.255 実際、モデルが小さい場合、推論は
213 00:09:57.255 --> 00:09:59.095 本当にリアルタイムの計算機であることに帰着します。
214 00:09:59.195 --> 00:10:00.775 そして、それは難しくありません。
215 00:10:00.805 --> 00:10:02.415 実際に難しいのはデータをオーケストレーションすることです。
216 00:10:02.435 --> 00:10:03.775 そしてそれは、あの、ある意味、
217 00:10:03.815 --> 00:10:05.735 私が講演の序盤で述べたことです。
218 00:10:05.735 --> 00:10:07.335 こうした企業と仕事をしていて私が気づいたのは、
219 00:10:07.335 --> 00:10:12.255 非常に多くのばらばらのデータベースシステムがあり、ええと、
220 00:10:13.045 --> 00:10:16.175 自分たちが持っているすべてのデータを
221 00:10:16.175 --> 00:10:20.575 一元化する方法を見つけること、そうすればその後で、特徴量化、ええと、
222 00:10:20.725 --> 00:10:22.855 そのデータを特徴量化して、それを
223 00:10:22.855 --> 00:10:25.295 モデルに提供できるのですが、それは実際かなり難しいのです、ええと、
224 00:10:25.365 --> 00:10:27.015 技術的にも組織的にもです。
225 00:10:27.115 --> 00:10:29.695 ですから、ええと、私は、あの、自前の粗削りな形の
226 00:10:29.695 --> 00:10:31.375 フィーチャーストアを実装している場所で
227 00:10:31.375 --> 00:10:33.375 キャリアの大半を働いてきて、
228 00:10:33.425 --> 00:10:35.015 最終的にはその1つを保守することになりました。
229 00:10:35.475 --> 00:10:38.855 ええと、そして、あー、私がよく話す冗談があるのですが、あー、
230 00:10:38.855 --> 00:10:40.455 Commonwealth Bank of Australiaにいたときの経験で、
231 00:10:40.455 --> 00:10:42.135 誰かからデータをもらうためにシドニーへ2回飛んだ、
232 00:10:42.755 --> 00:10:43.775 というものです。
233 00:10:43.775 --> 00:10:45.175 そしてそれは実は本当の話です。
234 00:10:45.175 --> 00:10:48.735 なぜなら、それはそれほど明白ではなく、
235 00:10:48.795 --> 00:10:50.295 実際にそのデータを取得するのは些細なことではなかったからです。
236 00:10:50.635 --> 00:10:53.655 ええと、ですからそれは企業にとって本当に、本当の問題であり、
237 00:10:54.115 --> 00:10:55.855 Feastはそれを解決することを目指しています、ええと、
238 00:10:55.955 --> 00:10:59.535 一元化された、あの、プラットフォームを提供することで、ええと、
239 00:10:59.895 --> 00:11:02.855 既存のインフラをつなぎ合わせ、ええと、
240 00:11:02.995 --> 00:11:05.255 適切なパターン、あー、そして権限
241 00:11:05.255 --> 00:11:08.855 とガバナンス、そして、あの、サーバーやその他すべてを備えて、
242 00:11:08.855 --> 00:11:11.975 モデルを本番環境に投入して成功できるようにします。
243 00:11:12.715 --> 00:11:16.415 つまり前提として、FeastはRagに役立ちます。
244 00:11:16.515 --> 00:11:19.295 MLEが最も得意とすること、
245 00:11:19.345 --> 00:11:21.215 つまりデータの力を活用することを可能にすることで、ええと、
246 00:11:21.655 --> 00:11:22.895 MLEとデータサイエンティストです。
247 00:11:22.895 --> 00:11:25.295 両者のニュアンスが何かについては、あの、曖昧さがありますが、
248 00:11:25.295 --> 00:11:26.215 しかし
249 00:11:26.295 --> 00:11:27.455 私は、それらを同等として扱います。
250 00:11:28.035 --> 00:11:31.375 ええと、ですから、あの、Feastsを使うと、ある意味、
251 00:11:31.395 --> 00:11:32.735 ragを本番環境に投入しやすくなります。
252 00:11:33.195 --> 00:11:35.575 あー、feastは実戦で検証済みのサポートで、あー、
253 00:11:35.805 --> 00:11:37.815 リアルタイム、バッチ、ストリーミングデータに対応しています。
254 00:11:38.115 --> 00:11:41.055 先ほど述べたように、ええと、前職では、あの、私たちは、
255 00:11:41.075 --> 00:11:44.255 ストリーミングを出荷し、リアルタイムを出荷し、バッチデータを出荷し、
256 00:11:44.385 --> 00:11:47.095 さまざまなサイズのバッチデータセットを出荷しました、
257 00:11:47.095 --> 00:11:48.535 3億6,000万レコードくらいです。
258 00:11:48.915 --> 00:11:51.575 ええと、それで、つまり、費用がスケールし、つまり、あなたは、あなたは
259 00:11:51.575 --> 00:11:55.045 到達し始めるんです、ええと、つまり、これをデータベースで本当にスケールさせることに、
260 00:11:55.065 --> 00:11:57.365 ええ、使っているものに、結局は行き着くんです。
261 00:11:57.785 --> 00:12:00.765 ええと、でも、つまり、私たちは、Feastを使って
262 00:12:00.985 --> 00:12:02.165 ええと、実際に素晴らしい稼働時間を得られました。
263 00:12:02.185 --> 00:12:07.165 それで、ええと、私は、ええと、それは、それは、それは機能すると思います。
264 00:12:07.235 --> 00:12:09.485 はい。そして、それはそれによって機能してきました、それは、それは機能します
265 00:12:09.505 --> 00:12:13.005 そして、非常に多くの、ええ、素晴らしく、ええ、
266 00:12:13.005 --> 00:12:14.245 強力な企業に使われています。
267 00:12:14.245 --> 00:12:15.525 ですから、私たちはそれをかなり誇りに思っています。
268 00:12:15.705 --> 00:12:16.765 ええと、そして
269 00:12:16.765 --> 00:12:19.085 それで、Ragを完全な機能にするのに少し遅れましたが、
270 00:12:19.085 --> 00:12:20.725 今は、それについて良い状態にあります。
271 00:12:21.385 --> 00:12:24.545 ええと、そしてそれは、それは本当に
272 00:12:24.545 --> 00:12:26.185 分散コンピューティングと取り込みのために構築されています。
273 00:12:26.185 --> 00:12:28.265 そして、つまり、私は、その、挿入について触れましたが、
274 00:12:28.285 --> 00:12:32.505 でも、つまり、FeastにおけるSparkサポートは、ええと、
275 00:12:33.085 --> 00:12:34.465 本当に強力な仕組みです。
276 00:12:34.725 --> 00:12:37.905 つまり、私たちは、ええ、それはADIANの人たちから寄贈されたもので、ええ、
277 00:12:37.905 --> 00:12:40.145 ですから、彼らに大きな称賛を送りたいです、ええと、
278 00:12:40.325 --> 00:12:41.465 オフラインストアとして。
279 00:12:41.645 --> 00:12:44.745 そして、つまり、ファインチューニング用の
280 00:12:44.765 --> 00:12:48.025 トレーニングデータを生成する際に出てくる複雑さは、しばしば、まあ、
281 00:12:48.025 --> 00:12:49.585 トレーニングデータ用に100万件くらいの
282 00:12:49.905 --> 00:12:51.145 ドキュメントをどう埋め込むのか、ということですよね？
283 00:12:51.485 --> 00:12:53.425 そしてそこで、ええ、つまり、
284 00:12:53.425 --> 00:12:55.145 分散コンピューティングフレームワークのようなものを使い始めます、
285 00:12:55.145 --> 00:12:56.625 特にSparkやRayのようなものです。
286 00:12:57.125 --> 00:12:59.665 ええと、daskのような他のものもあります。私たちもaaskを使います。
287 00:12:59.665 --> 00:13:02.025 ただ、実際にはそれほど多くは使っていません、ええと、
288 00:13:02.645 --> 00:13:04.305 オフラインストアについては、ええ、それほどは。
289 00:13:04.565 --> 00:13:07.185 ええと、でも、つまり、こうしたフレームワークは存在し、
290 00:13:07.185 --> 00:13:09.785 そして最終的には、それらは、それらは、つまり、構築されていて、
291 00:13:09.925 --> 00:13:10.985 ええ、Feastの中にあります。
292 00:13:11.965 --> 00:13:14.865 そして私たちはファインチューニングを第一級の存在として扱い、
293 00:13:15.205 --> 00:13:18.465 ポイントインタイムの正確性、データの結合、
294 00:13:18.465 --> 00:13:21.305 つまり、あなたが、ええと、いわゆる、
295 00:13:21.805 --> 00:13:22.825 データリーケージを起こしていないこと、
296 00:13:22.825 --> 00:13:24.265 つまり将来のデータを見ていないことを確認します。
297 00:13:25.645 --> 00:13:28.345 そして、ええと、これらはすべて、
298 00:13:28.345 --> 00:13:30.265 FETがragで本当に役立つ理由の仕組みであり、
299 00:13:30.285 --> 00:13:31.905 それは完全にオープンソースですよね？
300 00:13:32.045 --> 00:13:33.385 ええと、つまり、それは、それは
301 00:13:33.385 --> 00:13:34.985 その本当に大きな利点の一つです。
302 00:13:34.985 --> 00:13:36.945 だからこそ、つまり、ええと、ユーザーは
303 00:13:37.325 --> 00:13:38.385 Feastを採用する傾向があります、
304 00:13:38.385 --> 00:13:41.145 単に自分たちのデータを、つまり、外部に送りたくないから、
305 00:13:41.325 --> 00:13:43.385 ええと、あるいは単にサービスを制御したいからです。
306 00:13:43.605 --> 00:13:48.535 それで、それが本当に役に立つことになります。さて。
307 00:13:48.535 --> 00:13:50.535 それで本番環境のFeastですが、私は少し、何を確認したいと思いました、
308 00:13:50.535 --> 00:13:52.415 アーキテクチャがどのようなものか、そして、
309 00:13:52.475 --> 00:13:56.495 そして、ええと、Feast では物事がどのように見えるのか、
310 00:13:57.715 --> 00:14:00.935 そしてそれが RAG とどのように自然につながるのか、ということです。
311 00:14:01.355 --> 00:14:03.335 Feast の世界には、2つのものがあります。
312 00:14:04.445 --> 00:14:06.015 オンラインインフラストラクチャがあり、
313 00:14:06.305 --> 00:14:07.815 それを私たちはオンラインストアと呼んでいます。
314 00:14:07.815 --> 00:14:09.775 これは基本的には、たとえばコンシューマー向けアプリケーションで
315 00:14:09.775 --> 00:14:11.655 使うようなデータベースで、
316 00:14:11.725 --> 00:14:13.495 高い回復力と高い稼働率を備えています。
317 00:14:13.875 --> 00:14:17.295 そしてオフラインインフラストラクチャがあり、これは、ええと、データベースのようなもので、
318 00:14:17.295 --> 00:14:21.575 モデルのファインチューニングに使うものです。ええと、つまり、
319 00:14:21.575 --> 00:14:24.535 オフラインウェアハウスのようなもので、そこでは、
320 00:14:24.535 --> 00:14:27.135 大量の読み取りを行い、書き込みはそれほど多くなく、そして、
321 00:14:27.155 --> 00:14:31.255 主に Big Query のようなものでクエリを実行するわけです。
322 00:14:31.795 --> 00:14:36.455 あるいは Snowflake や Spark で、ええと、そのデータは、
323 00:14:36.475 --> 00:14:39.175 つまり、もしダウンしても、
324 00:14:39.245 --> 00:14:41.255 基本的に顧客に悪影響を与えることはありません。
325 00:14:42.135 --> 00:14:45.675 それで右側の図を見ると、そこには
326 00:14:45.745 --> 00:14:47.275 私たちがデータプロデューサーと呼ぶものがあります。
327 00:14:47.655 --> 00:14:48.995 データプロデューサーとは何かというと、
328 00:14:49.015 --> 00:14:50.475 基本的にはアプリケーションのようなものです。
329 00:14:51.135 --> 00:14:52.365 たとえばあなたが決済会社で、
330 00:14:52.365 --> 00:14:54.365 認証サービスのようなものを持っているとしますよね？
331 00:14:54.365 --> 00:14:55.765 たとえば、顧客がログインして、
332 00:14:55.765 --> 00:14:57.605 そのセッションを追跡しておきたい、
333 00:14:58.345 --> 00:15:00.725 その人が何回ログインしたか、
334 00:15:01.095 --> 00:15:02.925 あるいは、ええと、支払いに関することかもしれません。
335 00:15:02.925 --> 00:15:04.205 過去に何回支払いをしたか、
336 00:15:04.305 --> 00:15:05.725 もしあなたが eコマース企業なら、
337 00:15:05.985 --> 00:15:07.525 あるいはその人が購入した商品についてです。
338 00:15:08.145 --> 00:15:12.325 ええと、やりたいことは本質的にはそのデータです。
339 00:15:13.105 --> 00:15:14.645 イベントを発行したり、
340 00:15:14.985 --> 00:15:19.345 オフラインストアにデータを書き込んだりしたいかもしれません。
341 00:15:19.345 --> 00:15:21.225 そうすれば後で戻って分析できます。
342 00:15:21.225 --> 00:15:23.865 そして先ほど言ったように、顧客体験に影響を与えることなく、
343 00:15:23.965 --> 00:15:25.505 ええと、これはかなり、かなり一般的ですよね。
344 00:15:25.505 --> 00:15:28.585 そして、すべてのビジネス分析は、要するに、
345 00:15:28.895 --> 00:15:31.745 何らかのオフライン分析ストア、たとえば click House
346 00:15:31.745 --> 00:15:33.545 のようなものに基づいていて、つまり、このデータにクエリをかけて、
347 00:15:33.685 --> 00:15:34.785 そこから何かを学ぶ、ということです。
348 00:15:35.205 --> 00:15:37.425 そして次の段階として、たとえば、
349 00:15:37.505 --> 00:15:39.945 何かを予測するモデルを作りたい AI エンジニアや ML エンジニアがいる、
350 00:15:39.945 --> 00:15:42.465 という話になります。たとえば、何を、
351 00:15:43.005 --> 00:15:46.825 ええと、顧客の、つまり、ええと、
352 00:15:47.585 --> 00:15:51.145 LTV がどれくらいか、あるいはその人がこれを、この商品を買う意思があるか、ええと、
353 00:15:51.165 --> 00:15:52.625 あるいはレコメンデーションエンジンを構築することです。
354 00:15:53.885 --> 00:15:56.665 そしてそれが、一番左にある図が示しているようなもので、
355 00:15:56.665 --> 00:15:59.745 オフラインログ、C-D-C-E-L-T とあるところです。これは、
356 00:15:59.745 --> 00:16:02.665 これは本質的には、オフラインストアにデータを発行することについてです。
357 00:16:02.665 --> 00:16:03.905 そうすれば、それを分析できます
358 00:16:04.585 --> 00:16:06.125 そして、このオフラインの話に入っていきます。
359 00:16:06.125 --> 00:16:08.605 そして多くの場合、人々はそれを S3 バケットのようなものに出力します。
360 00:16:09.105 --> 00:16:12.485 ええと、ご存じのように、実際には、ええと、
361 00:16:12.805 --> 00:16:15.445 イベントを Kinesis や Kafka に出力する人もいて、ええと、
362 00:16:15.705 --> 00:16:16.925 そして、ご存じのように、それらは最終的に、
363 00:16:16.925 --> 00:16:18.325 S3 バケットも使えます。
364 00:16:18.545 --> 00:16:21.725 ええと、CDC は変更データキャプチャです。
365 00:16:21.825 --> 00:16:25.085 ですから、たとえば、ええと、ELT システムがある場合、
366 00:16:25.115 --> 00:16:26.725 これはかなり、かなり一般的なものになりがちです。
367 00:16:26.725 --> 00:16:27.725 Fivetran は、その一例です
368 00:16:27.745 --> 00:16:29.045 それをかなりうまく行うプロバイダーの。
369 00:16:29.195 --> 00:16:30.525 Air、Airbyte があります
370 00:16:30.525 --> 00:16:31.805 それがオープンソース版だと思います。
371 00:16:32.505 --> 00:16:37.125 ええと、そしてそこから、出力されたログデータのようなものから、通常はそこが
372 00:16:37.125 --> 00:16:38.485 トレーニングデータセットを生成する場所です
373 00:16:39.355 --> 00:16:43.575 そして Feast は、Spark のようなものと上手く結合できます
374 00:16:43.595 --> 00:16:46.255 または Snowflake、あるいはあなたのオフラインストアが何であれ
375 00:16:46.515 --> 00:16:48.615 そしてトレーニングデータセットの作成を支援します。
376 00:16:49.075 --> 00:16:51.015 ええと、それが本当に、そこにおける
377 00:16:51.635 --> 00:16:53.335 大きな価値提案のようなものです。ご存じのように、
378 00:16:53.335 --> 00:16:55.135 データ準備、モデル訓練
379 00:16:55.155 --> 00:16:57.895 そしてバックテストがあります。それは、あなたが
380 00:16:57.895 --> 00:17:00.215 そのようなバッチの世界の中で行いたいかもしれないもので、そこでは、ご存じのように、
381 00:17:00.735 --> 00:17:04.695 大量の、たくさんの、ええと、データセットに対する大規模な計算で
382 00:17:04.695 --> 00:17:05.775 それには少し時間がかかります。
383 00:17:06.355 --> 00:17:08.735 ええと、そしてこれがあります。
384 00:17:09.235 --> 00:17:12.215 ですから、それはすべてこのデータウェアハウス内に留まります、
385 00:17:12.215 --> 00:17:15.255 このオフラインストアの領域、ええと、実際にはモデル探索です。
386 00:17:15.275 --> 00:17:19.015 そして、Q flow エコシステムでは、
387 00:17:19.035 --> 00:17:21.575 これをモデル開発ライフサイクルのように話します。
388 00:17:22.545 --> 00:17:24.965 そして一般的には、そこでオフラインストアに留まります。
389 00:17:25.225 --> 00:17:29.245 ええと、では図の、上の方に戻ると
390 00:17:29.295 --> 00:17:33.325 イベントがこの種の
391 00:17:33.325 --> 00:17:34.605 ストリーミングアプリケーション、Flink
392 00:17:34.605 --> 00:17:37.485 または Spark に到達することについて話しているところです。アーキテクチャ上の理由で。
393 00:17:37.715 --> 00:17:41.085 いくつかの、いくつかのアプリケーションは実際に
394 00:17:41.785 --> 00:17:43.085 ストリーミングアーキテクチャ
395 00:17:43.085 --> 00:17:44.405 またはイベント駆動アーキテクチャを使いたいかもしれません
396 00:17:44.405 --> 00:17:46.365 そこでは Kafka トピックにイベントを出力するだけで、
397 00:17:46.825 --> 00:17:48.645 そしてコンシューマーがそれを購読する、
398 00:17:49.025 --> 00:17:50.725 またはアプリケーションがそのトピックを購読して
399 00:17:50.825 --> 00:17:51.885 それらのイベントを消費し
400 00:17:51.885 --> 00:17:54.605 自分たちが望む任意の周期でそれらを処理します。
401 00:17:54.625 --> 00:17:56.045 そして、ええと、Flink
402 00:17:56.065 --> 00:17:59.765 と Spark Streaming は、自然に、ええと、良い選択肢です、
403 00:17:59.765 --> 00:18:00.885 その、その場合には
404 00:18:00.885 --> 00:18:03.405 実際に変換を構築できる場合で、
405 00:18:03.405 --> 00:18:06.645 それがスループットを管理し、それによってバッチ化できます、
406 00:18:06.865 --> 00:18:08.525 ええと、リクエストをまとめて、そして、
407 00:18:08.585 --> 00:18:13.085 特徴量計算もまとめることで、あなたが、ええと、書き込んでいないようにします
408 00:18:13.145 --> 00:18:16.565 オンラインストアにあまりに高い頻度で送ることです。
409 00:18:16.725 --> 00:18:17.885 というのも、そうすると、その場合
410 00:18:17.885 --> 00:18:19.005 リソースの競合が起き始めるからです。
411 00:18:19.005 --> 00:18:21.325 そして一度に大量のボリュームが発生すると、
412 00:18:21.465 --> 00:18:23.125 実際にいくつかの、
413 00:18:23.125 --> 00:18:24.445 本番環境での課題を招く可能性があります。
414 00:18:24.945 --> 00:18:29.285 ええと、それで一部のデータプロデューサーは、ええと、
415 00:18:29.805 --> 00:18:32.085 あるモデルを選びます。つまり、サイドカーがあって、
416 00:18:32.705 --> 00:18:34.565 イベントをS3バケットに書き込んでいる、というものです。
417 00:18:34.985 --> 00:18:36.965 あるいは、彼らはただ、その、代わりに
418 00:18:36.965 --> 00:18:38.365 サイドカーではなくKafkaを使いたいのかもしれませんよね？
419 00:18:38.745 --> 00:18:41.765 そして単にバッチダンプのようなことをする人もいますよね？
420 00:18:41.765 --> 00:18:43.845 例えば24時間ごとに、データベースのコピーを
421 00:18:43.845 --> 00:18:45.485 取って、そのままダンプする、という感じです。
422 00:18:45.945 --> 00:18:49.645 ええと、そしてまた、次のようなアーキテクチャが必要かもしれません。
423 00:18:49.675 --> 00:18:52.045 そのデータプロデューサー、その、その、そのアプリケーション
424 00:18:52.585 --> 00:18:54.365 またはサービスが、API経由で
425 00:18:54.365 --> 00:18:56.125 オンラインストアに直接書き込む、というものです。
426 00:18:57.065 --> 00:18:59.085 そしてfeastはこれらすべてのアーキテクチャをサポートしています。
427 00:18:59.085 --> 00:19:00.285 そして、これらの異なる書き込みパターンには
428 00:19:00.285 --> 00:19:03.525 それぞれ異なるトレードオフがあります。特に、ええと、
429 00:19:03.525 --> 00:19:04.725 ミッションクリティカルなサービスにおいてです。
430 00:19:05.505 --> 00:19:09.925 ええと、決済や、融資のような、ええと、そうした領域では、
431 00:19:10.795 --> 00:19:13.765 データの鮮度の低さについて、あるいは
432 00:19:14.025 --> 00:19:15.565 一貫性という言葉が
433 00:19:15.565 --> 00:19:16.845 データに対してよく使われますが、その保証が異なります。
434 00:19:17.185 --> 00:19:22.045 ええと、その、オンラインストアへの異なる書き込みパターンが、
435 00:19:22.105 --> 00:19:24.325 異なるデータソースごとに必要になるでしょう。
436 00:19:24.785 --> 00:19:26.005 ええと、なぜなら繰り返しになりますが、それらは、
437 00:19:26.005 --> 00:19:27.285 それぞれ異なる影響を
438 00:19:27.345 --> 00:19:28.485 消費者体験にもたらすからです。
439 00:19:28.665 --> 00:19:30.845 そして最も具体的な例は、強い、
440 00:19:30.845 --> 00:19:32.725 一貫している、一貫性が必要だということです。
441 00:19:32.725 --> 00:19:34.765 例えば、ええと、融資を行っていて、
442 00:19:35.225 --> 00:19:36.445 確認したい、ええと、
443 00:19:36.445 --> 00:19:37.485 あるいはある人の総エクスポージャーを計算するための
444 00:19:37.485 --> 00:19:40.125 特徴量を作りたい場合、つまり
445 00:19:40.125 --> 00:19:41.365 その人にいくら貸し付けているかということですが、
446 00:19:41.705 --> 00:19:43.125 それをリアルタイムで間違えたくはありません。
447 00:19:43.145 --> 00:19:44.685 その、つまり、確実にしたいわけです。例えば、
448 00:19:45.115 --> 00:19:47.725 その数値が最も正確なデータで計算されていることを。
449 00:19:47.865 --> 00:19:49.525 ええと、なぜならそれは、ええと、かなり深刻な
450 00:19:49.625 --> 00:19:50.805 金銭的影響をもたらす可能性があるからです。
451 00:19:51.745 --> 00:19:55.125 そして、このオンラインストアに
452 00:19:55.235 --> 00:19:56.845 さまざまな場所すべてから必要なデータを
453 00:19:56.845 --> 00:19:58.845 取り込んで満たしたら、繰り返しになりますが、バッチ処理であったり、
454 00:19:58.885 --> 00:20:03.005 ストリーミングプロデューサーかもしれないし、ええと、オンラインアプリケーションかもしれません。
455 00:20:03.505 --> 00:20:04.685 ええと、その、
456 00:20:04.705 --> 00:20:07.125 そして提供用にこのオンラインストアへ集約します。
457 00:20:07.665 --> 00:20:11.445 ええと、するとAIアプリケーション内で、
458 00:20:11.505 --> 00:20:13.885 実際に推論プロバイダーとやり取りできます。
459 00:20:14.015 --> 00:20:16.285 別のサービスかもしれません。時にはmallが非常に小さく、
460 00:20:16.285 --> 00:20:18.685 実際にそれらをフィーチャーサーバーに含めることができます。
461 00:20:19.105 --> 00:20:20.925 ええと、繰り返しますが、表形式の領域では
462 00:20:20.925 --> 00:20:22.965 モデルがそこまで巨大ではないので、それは
463 00:20:22.965 --> 00:20:24.405 実際には珍しいパターンではありません。
464 00:20:24.745 --> 00:20:28.085 ええと、ただ、明示的な、ええと、
465 00:20:28.405 --> 00:20:29.805 別個の推論エンドポイントを持つことには多くの有用性があります。
466 00:20:29.905 --> 00:20:32.285 ええと、特にモデルが本当に大規模にスケールし始めると、
467 00:20:32.425 --> 00:20:36.565 どんなLLMも自然と、ええと、独自の入力プロバイダーを必要とします。
468 00:20:37.065 --> 00:20:41.085 ええと、ここにあるようなクライアントAIアプリケーションを見ると
469 00:20:41.085 --> 00:20:43.605 それはユーザーのフロント側ブラウザーかもしれませんし、
470 00:20:43.865 --> 00:20:45.285 別のバックエンドサービスかもしれません。
471 00:20:45.865 --> 00:20:48.005 ええと、実際にはこれらすべてがこうしたものとやり取りしていて
472 00:20:48.005 --> 00:20:50.045 大企業では、これはかなり、
473 00:20:50.105 --> 00:20:51.485 かなり一般的な、一般的なパターンになります。
474 00:20:52.025 --> 00:20:56.405 ええと、なのでこれを見ると、少し抽象的ですが、
475 00:20:56.425 --> 00:21:00.735 気づくのは、まあ、これは自然に
476 00:21:00.755 --> 00:21:02.015 RAGシステムに当てはまるということですよね？
477 00:21:02.165 --> 00:21:05.735 なぜなら、たとえばドキュメントを取り込む場合、
478 00:21:05.735 --> 00:21:08.895 それはWebからのコンテンツかもしれませんし、あなたのCMSからかもしれませんよね？
479 00:21:08.925 --> 00:21:12.815 Contentlyのように、ええと、APIがあり、web hookがあり
480 00:21:12.815 --> 00:21:14.975 そこで、つまり、更新したり、つまり、
481 00:21:15.075 --> 00:21:17.175 コンテンツに変更が発生したりして
482 00:21:17.355 --> 00:21:18.535 それを埋め込みたい、そして、
483 00:21:18.635 --> 00:21:21.695 そして、ええと、反映したい、
484 00:21:21.715 --> 00:21:23.895 RAGシステム内にこれらの変更を、ですよね？
485 00:21:24.595 --> 00:21:27.815 ええと、まあ、それはAPIでやらざるを得ません。もし
486 00:21:27.815 --> 00:21:29.655 それをバッチでやると、つまり、
487 00:21:30.155 --> 00:21:32.575 検索で悪い結果になるでしょう
488 00:21:32.575 --> 00:21:34.575 なぜなら、インデックスされたデータが古くなってしまうからです。
489 00:21:35.115 --> 00:21:38.375 ええと、なので、すべてがある意味、論理的に、こう、
490 00:21:38.435 --> 00:21:42.055 こう続いていきます。ああ、実は、これらのデータパターンは、
491 00:21:42.055 --> 00:21:43.295 RAGにとても適しているのだ、と。
492 00:21:43.515 --> 00:21:45.375 ええと、それはアクセントではなく、
493 00:21:45.375 --> 00:21:47.255 本当に違う唯一の点は
494 00:21:47.255 --> 00:21:49.975 表形式ではなくテキストだということだけです。ええと、とはいえ、
495 00:21:50.005 --> 00:21:51.655 ベクトルなので依然として数値ではありますよね？
496 00:21:52.235 --> 00:21:54.615 でも、ええと、つまり、それは重要な部分です。
497 00:21:54.755 --> 00:21:57.135 そしてここでの本当の、本当の主要な価値提案は
498 00:21:57.135 --> 00:22:00.375 Feastがオンラインインフラだけでなく、ええと、
499 00:22:00.595 --> 00:22:02.575 コアの優先事項として扱うだけでなく、オフラインもそうだということです。
500 00:22:02.635 --> 00:22:05.135 ええと、繰り返しますが、ファインチューニングは第一級の市民です。
501 00:22:05.165 --> 00:22:07.815 それは、それは、それは、本当に
502 00:22:07.815 --> 00:22:11.895 Feastがもともと作られた理由は、つまり、
503 00:22:13.115 --> 00:22:15.255 トレーニングとサービングのSKUのようなものを減らすためでした。
504 00:22:15.255 --> 00:22:17.495 そこには、そこには古い論文があって、ええと、
505 00:22:18.145 --> 00:22:19.375 ML Opsについてのものです。
506 00:22:19.475 --> 00:22:22.015 そして、そして、つまり、この、この論文では、
507 00:22:22.555 --> 00:22:27.415 MLにおける運用面の本当に中核的な重要性について語っていました。
508 00:22:27.435 --> 00:22:29.655 そして、そしてそれはAIエンジニアリングにも当てはまります。
509 00:22:29.655 --> 00:22:31.735 そして生成AIです。なぜなら、
510 00:22:31.735 --> 00:22:33.215 同じ問題すべてに対処する必要があるからです。
511 00:22:33.275 --> 00:22:34.415 モデルを頻繁にトレーニングする必要はありません。
512 00:22:34.415 --> 00:22:35.455 微調整したいかもしれませんが、
513 00:22:35.455 --> 00:22:37.575 それ以外の問題はすべてまだ残っています。
514 00:22:37.915 --> 00:22:41.575 ええと、データリネージ、権限、ガバナンス、
515 00:22:41.875 --> 00:22:44.975 ええと、照合やその他すべてのことです。
516 00:22:45.155 --> 00:22:47.935 ええと、ですから、その、
517 00:22:47.935 --> 00:22:49.855 thesis から得られる利点の一つはレジストリで、
518 00:22:49.855 --> 00:22:53.095 そこには、ええと、使用するデータの種類に関するメタデータが保存されます。
519 00:22:53.095 --> 00:22:56.535 推論や、さらにはトレーニングの際に使うデータですね。
520 00:22:57.075 --> 00:22:58.895 ええと、それについてはもう少し
521 00:22:58.895 --> 00:23:00.135 後ほどお話しします。
522 00:23:00.755 --> 00:23:02.255 ええと、いいですね。
523 00:23:03.845 --> 00:23:06.025 では今日はデモをお見せしたいと思います。
524 00:23:06.445 --> 00:23:10.265 そして、ええと、beast Vis と Dock Ling について話します。
525 00:23:10.285 --> 00:23:11.545 Dock Ling は本当にクールです。
526 00:23:11.965 --> 00:23:15.705 ええ、それは、ええと、基本的にはさまざまな
527 00:23:15.705 --> 00:23:18.905 入力タイプのテキスト形式を受け取ります。PDF であれ、
528 00:23:19.075 --> 00:23:22.985 PowerPoint、doc X-H-T-M-L であれ、それを変換して
529 00:23:22.985 --> 00:23:24.785 埋め込み、ええと、トークンにします。
530 00:23:24.845 --> 00:23:26.945 ええ、それをベクトルに埋め込みます。ええと、
531 00:23:27.925 --> 00:23:30.265 そしてそれを nobus にアップロードできるようにします。
532 00:23:30.805 --> 00:23:32.465 ええ、それで私はこのシンプルな図を作りました。
533 00:23:32.555 --> 00:23:35.145 そこでは、ある管理者が、そうですね、
534 00:23:35.745 --> 00:23:38.305 おそらくエンドユーザーではない人がドキュメントを書くことを選び、
535 00:23:38.305 --> 00:23:41.785 それらを、ええと、フィーチャーストアに取り込むと想像できますよね？
536 00:23:41.925 --> 00:23:44.225 ええと、ここでは非常にシンプルに進めて、
537 00:23:44.245 --> 00:23:45.485 バッチ演習を行います。
538 00:23:46.905 --> 00:23:48.245 それらをオンラインストアに書き込み、
539 00:23:48.245 --> 00:23:49.805 そしてあるユーザーがそれらを取得して、
540 00:23:49.825 --> 00:23:51.045 ドキュメントと対話したいと思うわけです。
541 00:23:51.385 --> 00:23:54.005 基本的にはそれだけです。ええと、その、
542 00:23:54.465 --> 00:23:56.525 このデモ全体の目的は、
543 00:23:56.525 --> 00:23:57.685 それがどのように機能するかを強調することです。
544 00:23:58.735 --> 00:24:00.475 今週ちょうど完成させたばかりなので、もし
545 00:24:00.475 --> 00:24:01.515 バグに遭遇したらご容赦ください。
546 00:24:01.785 --> 00:24:03.635 あらかじめ警告しておきます。ええと、
547 00:24:04.695 --> 00:24:07.075 しかし、これは Feast が行うことの中核のようなものです。
548 00:24:07.395 --> 00:24:09.115 データを取り込み、データを変換して保存し、
549 00:24:09.115 --> 00:24:10.995 低レイテンシで取得できるようにします。
550 00:24:11.255 --> 00:24:14.475 ええと、それ以外のことは本当に範囲外ですが、
551 00:24:14.535 --> 00:24:16.395 つまり、それこそが私たちの目指していることです。
552 00:24:17.695 --> 00:24:19.515 では、これから得られる
553 00:24:19.515 --> 00:24:21.155 Feast の構成要素について少し話しましょう。
554 00:24:21.855 --> 00:24:24.995 Feast のオブジェクトのようなものを説明したいと思いました。
555 00:24:26.495 --> 00:24:28.155 右側には、二つ、
556 00:24:28.255 --> 00:24:29.315 二つのコードスニペットが表示されています。
557 00:24:29.735 --> 00:24:33.595 最初のものはエンティティで、ここでは Chunk ID と呼んでいます。
558 00:24:33.735 --> 00:24:34.795 そして値の型があります。
559 00:24:34.865 --> 00:24:37.755 それは文字列で、つまり基本的には、ええと、
560 00:24:38.095 --> 00:24:42.055 その、これは、ええ、Feast の構成要素だと言うためのものです。
561 00:24:42.055 --> 00:24:44.295 そしてエンティティは、ほぼ主キーに対応します
562 00:24:44.295 --> 00:24:45.335 テーブルに入れることになるものです。
563 00:24:46.195 --> 00:24:49.775 ええと、そしてこの document は別の主キーで
564 00:24:49.775 --> 00:24:50.975 テーブルに入れることになるものです。
565 00:24:51.275 --> 00:24:53.455 ええと、そこにはいくつか、いくつかの要素があって
566 00:24:53.455 --> 00:24:55.655 最終的に Feast にとって役立つものになります、description、
567 00:24:56.155 --> 00:24:58.015 value type、そして joint keys です。
568 00:24:58.235 --> 00:25:01.095 ええと、なぜなら複数の joint keys を、ええと、1つの中に持てるからです。
569 00:25:01.095 --> 00:25:02.815 だからリストにする必要があります。ええと、
570 00:25:02.815 --> 00:25:04.495 宣言する data sources があります。
571 00:25:04.585 --> 00:25:05.615 これらはファイルのようなものや
572 00:25:05.715 --> 00:25:08.855 request objects で、CSV や Parquet ファイルのようなものです。
573 00:25:09.395 --> 00:25:11.735 そして API call、request object によって
574 00:25:11.735 --> 00:25:13.575 任意のデータを Feast に送ることができ、
575 00:25:13.575 --> 00:25:15.695 Feast はそれを単なる API call のように扱い
576 00:25:15.695 --> 00:25:17.735 変換したり、それに対して処理を行ったりできます。
577 00:25:18.515 --> 00:25:21.575 ええと、そしてここに source が見えます、ええと、
578 00:25:22.835 --> 00:25:24.215 これは file source で、先ほど言ったように
579 00:25:24.215 --> 00:25:25.495 parquet format です。
580 00:25:26.315 --> 00:25:27.975 ええと、それから request source があり、
581 00:25:27.975 --> 00:25:30.455 この場合は PDF になります、ええと、
582 00:25:30.455 --> 00:25:31.895 PDF bytes があるのが分かります。
583 00:25:31.895 --> 00:25:33.975 つまり、PDF を bytes にキャストして
584 00:25:33.985 --> 00:25:36.095 Python でロードし、それを送信するということです。
585 00:25:36.875 --> 00:25:39.925 ええと、そして file name は string です。
586 00:25:40.905 --> 00:25:44.165 そして私は、その metadata をすべて定義しています
587 00:25:44.165 --> 00:25:47.805 そうすることで、論理テーブルのようなものを定義できるようになります、ええと、
588 00:25:47.805 --> 00:25:49.285 右側の feature view です。
589 00:25:49.385 --> 00:25:51.685 そして feature view は Dock Link Example
590 00:25:51.685 --> 00:25:55.125 feature view と呼ばれています。とても創造的な名前ですよね、ええと、その変数は、
591 00:25:55.425 --> 00:25:57.485 docking feature view という名前です。
592 00:25:57.665 --> 00:25:59.805 そしてそこに entities list があり、
593 00:25:59.915 --> 00:26:01.165 chunk として定義されているだけです。
594 00:26:02.105 --> 00:26:06.785 そして、その field name は filed name です。
595 00:26:06.925 --> 00:26:09.585 つまり field definition は field に相当し、
596 00:26:09.585 --> 00:26:12.025 feature のようなものです、ええと、feature という
597 00:26:12.045 --> 00:26:14.105 言い方は ML エンジニアの間では非常に一般的です。
598 00:26:14.335 --> 00:26:15.545 それはそれほど明白ではありません
599 00:26:15.645 --> 00:26:17.385 モデルを構築しない他のすべての人にとっては。
600 00:26:17.645 --> 00:26:20.425 でも、ええと、そこでの一般的な命名は features です、ええと、
601 00:26:20.605 --> 00:26:22.985 ここでは明示的に、それが
602 00:26:23.185 --> 00:26:26.395 field であり、これは最終的に database table に対応する
603 00:26:26.425 --> 00:26:28.795 field のための schema だと分かるように、fields と呼んでいます、ええと、
604 00:26:29.455 --> 00:26:30.835 Milvus では collection です。
605 00:26:31.575 --> 00:26:34.915 ええと、そしてここで気づくと思いますが、この、ええと、
606 00:26:36.235 --> 00:26:37.455 raw chunk of markdown があります。
607 00:26:37.515 --> 00:26:41.135 Docking では、テキストの一部を抽出できます、
608 00:26:41.155 --> 00:26:44.125 つまり、chunks の、その、テキストの一部です。
609 00:26:44.585 --> 00:26:46.485 ここでは単に markdown として抽出しています。
610 00:26:46.485 --> 00:26:47.765 そのコードはすぐに見ます。
611 00:26:48.065 --> 00:26:52.945 ええと、ベクターフィールドの下を見ると、
612 00:26:53.355 --> 00:26:56.425 D 型のほかに追加のブール値が2つあります。
613 00:26:56.425 --> 00:27:00.305 これは Float 64 の配列で、ええと、ベクターインデックスです。
614 00:27:00.405 --> 00:27:01.625 そして true と表示されているのがわかります。
615 00:27:02.245 --> 00:27:04.265 これが Feast でベクトル類似度検索を
616 00:27:04.265 --> 00:27:05.385 設定する方法です。
617 00:27:05.565 --> 00:27:08.905 ええと、そして、ベクトル検索メトリックはコサインです。
618 00:27:08.905 --> 00:27:10.985 つまり、それが計算に使われる距離メトリックです。
619 00:27:11.205 --> 00:27:12.545 つまり、私が言っているのは、
620 00:27:12.545 --> 00:27:13.825 これを実現するには多くの大変な作業があるということです。
621 00:27:14.005 --> 00:27:15.345 ええ、でも私はこれに本当にワクワクしています。
622 00:27:15.345 --> 00:27:16.105 なぜなら、それは ML
623 00:27:16.305 --> 00:27:17.625 エンジニアが気にしなくてよいということを意味するからです。
624 00:27:17.815 --> 00:27:20.825 彼らはただ、そうですね、このフィーチャービューを宣言して、
625 00:27:20.845 --> 00:27:24.065 それから、ソフトウェア担当者に
626 00:27:24.065 --> 00:27:25.265 「ねえ、これを使えばいいよ」と言えばいいのです。
627 00:27:25.265 --> 00:27:28.145 これは簡単です。ええと、そして彼らは、そうですね、
628 00:27:28.595 --> 00:27:31.145 自分たちの ML モデルや LLM を提供し、
629 00:27:31.145 --> 00:27:32.465 ニーズに合わせてカスタマイズできます。
630 00:27:32.565 --> 00:27:34.105 ええ、ですからそれが本当にワクワクする、
631 00:27:34.105 --> 00:27:35.905 強力な部分であり、また、
632 00:27:35.905 --> 00:27:38.025 そこにデータソースも指定していることがわかるでしょう。
633 00:27:38.025 --> 00:27:40.145 そしてそれは、後でマテリアライゼーション、
634 00:27:40.165 --> 00:27:42.265 あるいは実際にはデータ取り込みにおいて重要になります。
635 00:27:42.455 --> 00:27:45.385 TTL があります。ええと、そうですね、ええと、
636 00:27:47.165 --> 00:27:48.385 基本的にはそれだけです。
637 00:27:49.425 --> 00:27:51.405 つまり、私たちはメタデータを持っています。
638 00:27:51.945 --> 00:27:54.885 次に、これをどう拡張するかについて話したいと思います。つまり、
639 00:27:54.885 --> 00:27:56.005 変換をどう行うかです。
640 00:27:56.005 --> 00:27:57.725 そして、ええ、Feast では
641 00:27:57.785 --> 00:28:01.485 先ほど述べた Spark のようなバッチ計算エンジン、
642 00:28:01.485 --> 00:28:04.325 Spark Streaming や Flink のようなストリーミング計算エンジン、
643 00:28:04.325 --> 00:28:07.245 そして API サーバー、つまり、
644 00:28:07.245 --> 00:28:09.485 そうですね、Feast feature server でフィーチャー変換を行えます。
645 00:28:09.745 --> 00:28:13.635 ええと、それはデコレーターを通じて行われます。
646 00:28:14.215 --> 00:28:16.875 そしてこれは基本的に、先ほどフィーチャービューで見た
647 00:28:16.875 --> 00:28:18.635 その他の内容を定義します。
648 00:28:20.735 --> 00:28:23.875 そして関数定義の中で、
649 00:28:23.875 --> 00:28:26.675 実際に、その、その、変換を定義します。
650 00:28:26.935 --> 00:28:29.235 今、私たちは、これは後で見直して、
651 00:28:29.235 --> 00:28:31.075 エンジニアにとって少し簡単になるように
652 00:28:31.255 --> 00:28:32.795 少し変更する予定ですが、
653 00:28:32.795 --> 00:28:34.995 同じような構造になるでしょう。
654 00:28:35.005 --> 00:28:38.435 on-demand feature view から transform へと
655 00:28:38.435 --> 00:28:39.675 直接デコレーターを読み取っており、
656 00:28:39.735 --> 00:28:40.915 そして、そうですね、
657 00:28:40.915 --> 00:28:42.395 基本的にその他はすべて同じままです。
658 00:28:42.815 --> 00:28:44.315 ええと、後方互換性もありますが、
659 00:28:44.375 --> 00:28:47.315 これは人々にもう少し明確さを提供するためのものです。
660 00:28:48.455 --> 00:28:50.275 しかしここでは、これは Dock Lane 変換です。
661 00:28:50.275 --> 00:28:53.355 つまりこれは、ここで起こることは、もしこの
662 00:28:53.755 --> 00:28:58.195 関数に任意のPDFバイト列を送ると、それは、ええと、
663 00:28:59.685 --> 00:29:01.535 そこからテキストを抽出して埋め込みます。
664 00:29:02.155 --> 00:29:06.655 それで、この、ええと、オブジェクトのリストがあるのがわかると思います
665 00:29:06.655 --> 00:29:08.615 それを、つまり、初期化して、
666 00:29:08.615 --> 00:29:10.495 それから、それは単にそれらに依存します。
667 00:29:10.675 --> 00:29:12.375 そして、ええと、それはdocument idに依存します。
668 00:29:12.915 --> 00:29:17.375 私たちが生成するchunk IDは、単に線形に、ええと、chunk、
669 00:29:17.435 --> 00:29:19.375 1, 2, 3, 4からnまでです。ええと、
670 00:29:19.955 --> 00:29:22.455 それからembeddingsですが、つまり、各embeddingは
671 00:29:22.555 --> 00:29:25.135 長さが、たしか584か何かだったと思います、忘れました、
672 00:29:25.275 --> 00:29:26.375 あるいは3 84だったかもしれません。
673 00:29:26.555 --> 00:29:29.095 ええと、これも忘れました。ええと、それで、
674 00:29:29.555 --> 00:29:30.935 それから実際のchunkテキストです。
675 00:29:31.355 --> 00:29:34.415 つまりそれが全部そこに入っていて、全部ここで宣言されているだけです。
676 00:29:34.435 --> 00:29:35.615 それでこれ全部、全部
677 00:29:40.705 --> 00:29:44.755 これ、つまり、だいたい50行ほどのclosureで
678 00:29:44.755 --> 00:29:47.475 これらを使ってragを出荷できるようになります。
679 00:29:47.545 --> 00:29:50.155 もちろん、これをデプロイするために書かなければならない
680 00:29:50.155 --> 00:29:51.595 インフラコードはたくさんありますよね？
681 00:29:51.655 --> 00:29:54.435 でもそれができると、MLエンジニアが本当に
682 00:29:54.435 --> 00:29:56.635 次々にragソリューションを出荷し始め、
683 00:29:56.975 --> 00:29:59.595 本番システムで提供できるようになります。ええと、
684 00:29:59.975 --> 00:30:01.755 さらにスケールさせることもできます。ええと、そして、
685 00:30:01.755 --> 00:30:03.995 そこではさらに議論されています。
686 00:30:05.495 --> 00:30:07.515 それで、データ取り込み、ええと、
687 00:30:07.615 --> 00:30:09.795 またはドキュメント取り込みですが、ええと、シンプルです。
688 00:30:09.795 --> 00:30:10.955 APIエンドポイントがあります。
689 00:30:10.955 --> 00:30:12.715 オンラインストアへのpush in rightがあり、
690 00:30:12.715 --> 00:30:15.515 materialize、materializeはbash向けの意味で、ええと、つまり、
691 00:30:15.945 --> 00:30:19.555 API向けのオンライン部門へのpush in rightで、ええと、
692 00:30:19.935 --> 00:30:22.595 つまり、実際にライブサービスで叩きたい場合で、
693 00:30:22.615 --> 00:30:24.995 そしてmaterializeを使うと、batchデータセットのようなもの、
694 00:30:24.995 --> 00:30:26.235 CSVのようなものを使ってそれができます。
695 00:30:26.815 --> 00:30:31.205 ええと、それだけです。だからそういうものが無料で手に入ります。
696 00:30:31.745 --> 00:30:34.475 ええと、はい、
697 00:30:35.135 --> 00:30:37.995 そしてこれはfeature serverから出てくるAPI docsで、
698 00:30:38.095 --> 00:30:40.395 つまり、open A API docsが、ええと、
699 00:30:40.395 --> 00:30:41.595 利用可能になります。これは良いですね。
700 00:30:41.655 --> 00:30:43.395 ええと、get online features、
701 00:30:43.395 --> 00:30:46.675 receive online documents、ええと、write to online storeが見えます。
702 00:30:46.675 --> 00:30:49.475 health checkがあり、最近このchat uiを追加しました。
703 00:30:49.575 --> 00:30:52.035 ええと、それによって、ある意味、ええと、つまり、
704 00:30:52.355 --> 00:30:53.675 MLエンジニアがすばやく立ち上げて
705 00:30:53.675 --> 00:30:56.355 いくつかのragシステムを書き始められるようになります。
706 00:30:56.695 --> 00:31:00.995 ええと、それで、ええと、ロードマップに入る前に
707 00:31:00.995 --> 00:31:02.315 これからデモに入ります。
708 00:31:02.455 --> 00:31:06.235 なので失礼、画面共有を止めます。では見てみましょう。
709 00:31:06.725 --> 00:31:09.635 これをライブでやってみます、うまくいくか見てみましょう。
710 00:31:16.235 --> 00:31:18.955 もしうまくいかなければ、ただその、ええと、
711 00:31:22.265 --> 00:31:22.925 その、ええと、
712 00:31:26.695 --> 00:31:27.315 notebookを共有します。
713 00:31:27.545 --> 00:31:32.255 オーケー。これは、えー、コマンドラインです。皆さん見えていますか？
714 00:31:32.315 --> 00:31:33.695 いいえ。それとも共有していますか？
715 00:31:34.195 --> 00:31:35.575 今、ターミナルを共有できます。
716 00:31:36.375 --> 00:31:38.585 オーケー。皆さん私のターミナルを見ています。はい。そうです。
717 00:31:38.975 --> 00:31:43.165 オーケー、いいですね。これは、えーと、
718 00:31:44.465 --> 00:31:45.485 料金構造です。
719 00:31:46.315 --> 00:31:48.165 pickle オプションがいくつかあります。ああ、なるほど。
720 00:31:48.385 --> 00:31:50.605 えーと、これがあります、
721 00:31:55.135 --> 00:31:57.625 この feature store YAML ファイルで、ここには、
722 00:31:59.235 --> 00:32:02.445 プロジェクト名とプロバイダーがあるだけです。
723 00:32:02.445 --> 00:32:04.325 Vis Lane を使ってローカルで実行されます、えー、
724 00:32:04.425 --> 00:32:07.965 そして online store、それから betting は 384 です。
725 00:32:08.185 --> 00:32:09.445 そして次のタイプは flat です。
726 00:32:10.065 --> 00:32:13.445 えー、この entity key serialization は implementation deal です。
727 00:32:13.445 --> 00:32:16.405 作業する必要はありません。私たちは認証 OIDC をサポートしています。
728 00:32:17.025 --> 00:32:20.605 えー、なので、そこには、えー、いくつかの
729 00:32:20.605 --> 00:32:22.125 心配しなくてよいものがあり、ドキュメント化されています。
730 00:32:22.185 --> 00:32:24.165 ですので、もし関心があれば、ドキュメントを
731 00:32:24.685 --> 00:32:26.565 見てみることをお勧めしますが、基本的には
732 00:32:26.565 --> 00:32:28.045 設定を定義する場所です、ということです。
733 00:32:29.115 --> 00:32:33.745 えー、それからこのサンプルの reboot を見て、
734 00:32:33.765 --> 00:32:36.585 今述べた内容を順に確認できます。それはすべて
735 00:32:36.585 --> 00:32:38.345 ここで私が言及したものです。
736 00:32:38.475 --> 00:32:40.005 embedding model を定義しています、
737 00:32:40.465 --> 00:32:41.885 最大トークン数を。
738 00:32:42.545 --> 00:32:46.805 えー、これは、えー、tokenize、embedding model、
739 00:32:46.805 --> 00:32:47.845 census transformer です。
740 00:32:47.915 --> 00:32:51.485 この Chunker、えー、これはテキストを embedding しています。
741 00:32:51.925 --> 00:32:55.525 実際これは chunk id をいくつか生成しています、えー、
742 00:32:56.005 --> 00:32:57.405 そのあたりはすでに一通り説明しました。
743 00:32:57.405 --> 00:33:01.255 繰り返しますが、これは、えー、これらの変換です。
744 00:33:01.255 --> 00:33:02.495 そしてこれを行うために feast で書く
745 00:33:02.495 --> 00:33:03.615 コマンドがいくつかあります。
746 00:33:03.635 --> 00:33:04.975 そして、feast apply と言います。
747 00:33:05.515 --> 00:33:07.215 えー、これはメタデータを登録します。
748 00:33:07.215 --> 00:33:08.895 動くか見てみましょう。警告は無視してください、
749 00:33:08.895 --> 00:33:10.255 問題ないことにしましょう。
750 00:33:10.955 --> 00:33:13.375 えー、見てみましょう。これはすべて Dock link 関連です。
751 00:33:13.375 --> 00:33:15.455 プロジェクト rags に変更を適用しています。
752 00:33:15.455 --> 00:33:18.455 ほら、これは実際に私たちが見慣れているはずのものです。
753 00:33:22.125 --> 00:33:24.545 そして Dock Link feature view の receipt infrastructure、
754 00:33:25.485 --> 00:33:26.745 えー、私たちが話したものです、
755 00:33:26.745 --> 00:33:28.385 これは本質的には batch feature view です。
756 00:33:28.525 --> 00:33:32.105 それで、えー、見てみましょう。
757 00:33:33.485 --> 00:33:36.025 では、この test workflow script を見ます。
758 00:33:36.715 --> 00:33:37.825 デモを見せるだけです。
759 00:33:38.005 --> 00:33:41.715 それで、ここで何が起きるかというと、私は
760 00:33:41.715 --> 00:33:43.155 この document data を読み込みます。
761 00:33:43.535 --> 00:33:48.435 実際にこの transform を適用します、えー、
762 00:33:50.325 --> 00:33:51.695 feature review、つまり
763 00:33:51.695 --> 00:33:53.335 実際にその場で変換を行うものです、
764 00:33:53.355 --> 00:33:54.895 あくまで例として。
765 00:33:55.235 --> 00:33:56.975 ええと、そこにバグがあって、それを、対処していきます。
766 00:33:57.035 --> 00:33:58.535 でも、ええと、それは、それで大丈夫です。
767 00:33:58.715 --> 00:34:02.655 ええと、それで私は、マテリアライズされた
768 00:34:02.655 --> 00:34:04.055 さまざまなタイプの埋め込みをログに記録します
769 00:34:04.075 --> 00:34:06.775 または、このデータベース、vus にアップロードされたものを。
770 00:34:07.765 --> 00:34:10.665 そしてこちらでは、同じことをしていますが、
771 00:34:10.665 --> 00:34:12.065 今度は別の feature view を使っています。
772 00:34:12.065 --> 00:34:16.025 これは、ええと、生のテキストそのものを書き込むものです。
773 00:34:16.085 --> 00:34:17.185 そして起こることとしては、それが
774 00:34:17.265 --> 00:34:18.385 その場で変換されます。
775 00:34:18.765 --> 00:34:20.425 ああ、なのでそれを見るのはちょっと面白いでしょう。
776 00:34:20.885 --> 00:34:23.145 そして、ええと、質問をして、
777 00:34:23.365 --> 00:34:27.945 それから rack top K 用のオンラインドキュメントを取得して、ええと、
778 00:34:28.445 --> 00:34:29.665 それから出力します。
779 00:34:31.845 --> 00:34:34.465 それからエンティティベースの retrieval があって、これは、まあ、
780 00:34:34.695 --> 00:34:36.585 この部分を示しています。
781 00:34:36.725 --> 00:34:39.425 あ、すみません、これは、はい、これは、ええと、
782 00:34:39.855 --> 00:34:41.705 これはそれから同じものを取得しています
783 00:34:42.445 --> 00:34:43.785 変換されたバージョンからで、
784 00:34:43.785 --> 00:34:45.745 そこでは単に query embedding を送るだけです。
785 00:34:45.805 --> 00:34:49.665 ええと、はい。なので私は、バッチ版と
786 00:34:50.045 --> 00:34:51.905 変換版の retrieval をしていて、同じものが得られますよね？
787 00:34:52.165 --> 00:34:53.625 これはただ、まあ、それが、それが、
788 00:34:53.625 --> 00:34:55.425 同等であることを示しているだけです。
789 00:34:56.045 --> 00:34:58.545 ええと、でも一方ではその場で変換できて、
790 00:34:58.545 --> 00:34:59.665 API のように使えます。
791 00:34:59.865 --> 00:35:01.105 なぜならそれこそがまさに
792 00:35:01.105 --> 00:35:02.145 本番環境でやりたいことだからです。
793 00:35:02.965 --> 00:35:05.905 そしてこれは、ええと、またエンティティ retrieval です。
794 00:35:06.285 --> 00:35:08.465 では試してみて、動いたか確認しましょう。
795 00:35:08.805 --> 00:35:10.785 ええと、test workflow。
796 00:35:14.545 --> 00:35:16.045 後悔させないでくださいね、
797 00:35:18.775 --> 00:35:20.555 でも1時間くらい前にテストして、そのときは動きました。
798 00:35:20.655 --> 00:35:22.755 なので、ええと、
799 00:35:23.205 --> 00:35:26.695 問題ないことを祈りましょう。
800 00:35:26.695 --> 00:35:27.695 少し時間がかかります。ええと、
801 00:35:28.865 --> 00:35:33.085 なぜなら、ええと、PDS journey を変換して、そうですね、
802 00:35:33.085 --> 00:35:34.645 事前計算された値を書き込んでいます、はい。
803 00:35:34.705 --> 00:35:37.835 そして p を変換しています、はい、何かしています。
804 00:35:40.315 --> 00:35:42.235 結論としては、もっと小さいデータを選ぶべきでした。
805 00:35:51.345 --> 00:35:53.265 おそらく進捗バーも入れるべきですね。
806 00:35:53.725 --> 00:35:54.725 それは役に立つでしょうし。
807 00:35:57.515 --> 00:35:58.565 はい、ようこそ。
808 00:35:59.035 --> 00:36:00.445 まあ、終わるまで待つしかないというのは
809 00:36:00.445 --> 00:36:01.885 ちょっと気まずいですね。
810 00:36:02.925 --> 00:36:04.125 このデモをやっていたときには、
811 00:36:04.165 --> 00:36:05.485 あまり考えてなくて、「ああ、動いてる」って感じでした。
812 00:36:05.595 --> 00:36:09.205 こう、うーん。小さな棒人間が
813 00:36:09.225 --> 00:36:10.845 ターミナルを横切って歩いていたら良かったなと思いました。
814 00:36:12.865 --> 00:36:15.165 ええと、でも、もしかしたらちょっとそこに便乗して。
815 00:36:15.225 --> 00:36:16.365 最後に聞きたい質問が
816 00:36:16.365 --> 00:36:17.565 ある方はいますか？
817 00:36:18.065 --> 00:36:20.205 ええと、チャットに直接、気軽に質問してください。
818 00:36:20.545 --> 00:36:21.545 ええと、なので私たちは、
819 00:36:24.775 --> 00:36:25.775 はい。皆さん質問がありますね。
820 00:36:25.775 --> 00:36:28.785 どうぞ遠慮なく、質問してください、ええ、喜んで
821 00:36:28.845 --> 00:36:31.815 たぶんターミナルが切れているのかな。
822 00:36:31.995 --> 00:36:34.895 いや、それは、あります、ええ、いや、そこにあります。
823 00:36:35.245 --> 00:36:37.735 ただ、いくつか計算をしているだけです。
824 00:36:37.755 --> 00:36:39.895 それで、何が起きているかというと実はこれらの、
825 00:36:40.035 --> 00:36:42.215 docking、そしてdockingの本当にすごいところは、
826 00:36:42.255 --> 00:36:44.975 ぜひ詳しく読んでみてほしいのですが、ええと、
827 00:36:45.245 --> 00:36:47.175 コンピュータビジョンを実行していて
828 00:36:47.315 --> 00:36:51.215 そして、ええ、小さなLLMを、ええと、ええ、
829 00:36:52.355 --> 00:36:53.735 変換中に使っています。
830 00:36:53.755 --> 00:36:56.455 つまりこのPDFを受け取って、ええと、そして、
831 00:36:56.455 --> 00:36:58.095 基本的にテキストを抽出しているわけです。
832 00:36:58.095 --> 00:37:00.855 でもどうやってそれをやるのか？それは、グラフも抽出して、
833 00:37:00.855 --> 00:37:03.655 そして、それをテキストのメタデータとして追加します。
834 00:37:04.035 --> 00:37:06.735 ええと、なので、ええ、それを全部やっているんです。
835 00:37:06.735 --> 00:37:08.415 だから実際かなり計算コストが高く、
836 00:37:08.415 --> 00:37:09.895 実際、数分かかります。
837 00:37:10.235 --> 00:37:13.615 ええと、それをやるのに普段しばらくかかるのを忘れていました。
838 00:37:13.675 --> 00:37:15.815 そして、ええ、まあ、
839 00:37:15.825 --> 00:37:17.495 ここで5分座っていることになりそうです。ええ、
840 00:37:17.835 --> 00:37:21.205 ところで、そのエラーはそれで大丈夫ですか
841 00:37:21.225 --> 00:37:23.245 それとも はい。大丈夫です。はい、
842 00:37:23.585 --> 00:37:24.585 問題ありません。ええと、
843 00:37:24.585 --> 00:37:27.125 token Indic、ほら、長さが
844 00:37:27.265 --> 00:37:28.405 best fightより長くない。
845 00:37:28.405 --> 00:37:30.665 はい、それは、それほど大きな問題ではありません。
846 00:37:30.925 --> 00:37:32.905 ええと、それは、
847 00:37:32.965 --> 00:37:35.385 その例から何も損ないません。
848 00:37:36.045 --> 00:37:38.125 ええと、はい。
849 00:37:38.785 --> 00:37:40.125 そしてdockingはただ
850 00:37:40.125 --> 00:37:41.685 実は以前はそれについて知らなかったので。
851 00:37:41.925 --> 00:37:43.805 完全にオープンソースみたいで、それから完全に
852 00:37:43.805 --> 00:37:44.805 オープンソース化されています。つまりこれは
853 00:37:44.805 --> 00:37:47.685 IBMによって作られたプロジェクトです。はい。
854 00:37:47.685 --> 00:37:48.965 ええ、Researchが、ええ、
855 00:37:49.225 --> 00:37:51.885 そして最近LFAI Foundationに寄贈しました。
856 00:37:52.195 --> 00:37:55.125 はい。ええと、なので完全にオープンソースで、オープンガバナンスです、ええ、
857 00:37:55.545 --> 00:37:57.685 まあ、そして私は、ええ、本当に素晴らしいツールだと思います。
858 00:37:57.685 --> 00:38:00.565 私たちはそれをfe、feature serversに追加しました。具体的には
859 00:38:00.565 --> 00:38:04.605 そのような、ええと、オープンソースの解析ツールを持つためです。そうすれば
860 00:38:04.605 --> 00:38:07.445 データサイエンティストやMLエンジニアが、
861 00:38:07.945 --> 00:38:10.525 本当に対処しなくても、行き詰まらずに済みます、ええと、
862 00:38:12.185 --> 00:38:14.825 どうやって自分のPDFを取り込んで、ええと、
863 00:38:15.525 --> 00:38:17.065 それらを抽出できるのか、と考え出すことに。
864 00:38:17.245 --> 00:38:19.105 ええと、通常のテキストでそれをやる方法はわかっていますし、
865 00:38:19.165 --> 00:38:20.785 多くの場合データはそういう形で来ます。
866 00:38:20.845 --> 00:38:22.225 でも、それが、それだけではありません。
867 00:38:23.045 --> 00:38:25.505 そしてそれは、例えば違う、つまりPDFはサポートしているけれど
868 00:38:25.505 --> 00:38:27.705 別の形式などもサポートしているんですか？
869 00:38:27.845 --> 00:38:30.545 しています。それは、本当にリッチな形式をたくさんサポートしています。
870 00:38:30.545 --> 00:38:32.225 そしてまた、まあ、ええ。ということで、こんな感じです。
871 00:38:32.285 --> 00:38:34.665 えー、うまくいきました。では、
872 00:38:34.665 --> 00:38:36.445 あなたに移りましょう。あなたに引き継いでもらいます。
873 00:38:37.115 --> 00:38:38.585 ええ、ありがたいです。
874 00:38:38.645 --> 00:38:40.705 ああ、retriever に問題がありますね、
875 00:38:40.705 --> 00:38:42.025 でもこの部分は、まあ大丈夫です。
876 00:38:42.025 --> 00:38:43.105 それは、ただのバグです。
877 00:38:43.245 --> 00:38:46.865 ここで見えるのは、えー、つまり、
878 00:38:47.165 --> 00:38:51.335 Dock Link の機能で、ええ、最初に渡したもの、
879 00:38:51.595 --> 00:38:54.695 えー、実際にちょっと、えー、コードを見に行って、えー、
880 00:38:56.705 --> 00:38:57.805 お見せしますね。
881 00:38:58.025 --> 00:39:02.705 えー、クエリ embedding
882 00:39:02.855 --> 00:39:04.105 で示したものは
883 00:39:04.445 --> 00:39:09.445 ここにありました
884 00:39:09.605 --> 00:39:10.785 この論文の名前は何ですか？
885 00:39:12.395 --> 00:39:15.705 これが私たちが尋ねた質問で、えー、
886 00:39:16.825 --> 00:39:17.885 そして references がここにあります。
887 00:39:18.025 --> 00:39:20.245 そして両方とも、えー、同じものを示しました。
888 00:39:20.585 --> 00:39:22.495 えー、そして
889 00:39:22.495 --> 00:39:24.935 なぜなら、繰り返しになりますが、こちらはこのようにバッチ変換されて
890 00:39:24.995 --> 00:39:27.295 アップロードされただけで、こちらは
891 00:39:27.295 --> 00:39:28.935 その場で変換されたものだったからです。
892 00:39:29.275 --> 00:39:30.815 時間がとてもかかった理由は、
893 00:39:30.815 --> 00:39:33.215 反復処理していたからで、たしか、これは、
894 00:39:33.255 --> 00:39:35.175 処理していた PDF が10個だったと思います。
895 00:39:35.215 --> 00:39:37.055 この例では1つだけにすべきでした、すみません。
896 00:39:37.435 --> 00:39:41.735 えー、でも、まあ、それらを、えー、chunk 化して
897 00:39:41.915 --> 00:39:43.135 そして embedding しました。
898 00:39:43.915 --> 00:39:45.135 これがその例です。
899 00:39:45.395 --> 00:39:46.895 えー、質問をすると、
900 00:39:46.915 --> 00:39:48.535 大量の references を返してくれます。
901 00:39:48.915 --> 00:39:50.335 たとえば、名前の付いた記事のようなものです。
902 00:39:50.355 --> 00:39:51.735 なので動作していますし、やるべきことをやっています。
903 00:39:52.115 --> 00:39:54.495 えー、さて、私たちが本当に楽しみにしていることは、えー、
904 00:39:54.645 --> 00:39:58.375 これに関して、そして、ええ、私たちが
905 00:39:58.375 --> 00:40:02.015 強化しようとしているのは、繰り返しになりますが、これを本当に卓越したものにし、
906 00:40:02.015 --> 00:40:03.975 ML エンジニアや人々にとって簡単にして、
907 00:40:03.995 --> 00:40:06.855 本当にスケールできる本番 RAG アプリケーションを出荷できるようにすることです。
908 00:40:07.355 --> 00:40:09.335 えー、なので、これについては、もう少し後で、
909 00:40:09.355 --> 00:40:10.655 もう少し詳しく入っていきます。
910 00:40:10.655 --> 00:40:12.175 もう一度画面を共有した後で。
911 00:40:12.675 --> 00:40:17.305 えー、はい、えー、ここで共有します。
912 00:40:21.385 --> 00:40:24.485 はい。えー、ingestion について話しました。
913 00:40:25.105 --> 00:40:26.805 それで、Feast のロードマップです。
914 00:40:26.805 --> 00:40:29.485 次に何をするのか？ より多くの NLP、つまり、繰り返しになりますが、
915 00:40:29.505 --> 00:40:32.085 私たちは FE を AI ユーザーが
916 00:40:32.225 --> 00:40:33.845 自分たちの RAG ソリューションをカスタマイズするための定番フレームワークにしたいのです。
917 00:40:34.025 --> 00:40:36.965 そしてそれは、viss へのさらなる投資を意味します。えー、viss は、つまり、
918 00:40:36.965 --> 00:40:38.965 繰り返しになりますが、並外れたデータベースです。
919 00:40:39.265 --> 00:40:41.405 えー、それは、ええ、えー、つまり、
920 00:40:41.545 --> 00:40:43.045 素晴らしいインラインの挙動、
921 00:40:43.625 --> 00:40:47.885 または pie mils light、えー、または mils light によるローカルの挙動を備えています。
922 00:40:47.945 --> 00:40:50.645 えー、それによってエンドユーザーが本当に簡単に
923 00:40:50.745 --> 00:40:52.005 立ち上げて実行を始められます。
924 00:40:52.225 --> 00:40:54.405 ええと、それは本当に重要だと思います。
925 00:40:54.605 --> 00:40:57.485 私が仕事をしていて、ええと、
926 00:40:57.665 --> 00:41:00.365 あるいはこうしたチームのいくつかを率いていて分かったことの多くは、ええと、それが、
927 00:41:00.365 --> 00:41:03.165 データサイエンティスト
928 00:41:03.165 --> 00:41:04.485 やエンドユーザーが始めるうえで摩擦が多いと、
929 00:41:04.715 --> 00:41:06.085 彼らはもう、使いたがらないということです。
930 00:41:06.265 --> 00:41:08.125 ええと、なので、ええと、
931 00:41:08.385 --> 00:41:10.845 少なくとも私たちは、その体験を非常に良くするために多く投資してきました。
932 00:41:10.865 --> 00:41:12.925 そして、そして Nobus は、ええ、ご存じの通り、そのために
933 00:41:12.925 --> 00:41:14.405 私たちのお気に入りのフレームワークの一つです。
934 00:41:14.865 --> 00:41:17.205 ええと、Nobus light のおかげで、ご存じの通り、
935 00:41:17.205 --> 00:41:19.405 コンテナについて
936 00:41:19.585 --> 00:41:21.005 あるいはどうデプロイするかをあまり考える必要がありません。
937 00:41:21.005 --> 00:41:23.085 ただ PIP install を実行して進められるのです。
938 00:41:23.545 --> 00:41:25.365 ええと、なので、だからそれが
939 00:41:25.365 --> 00:41:26.765 私たちがそれを本当に気に入っている点の一つです。
940 00:41:26.765 --> 00:41:28.565 そして繰り返しになりますが、私たちは今後もさらに多くを
941 00:41:28.605 --> 00:41:30.405 NLP、ええと、画像サポートに投資していきます。
942 00:41:30.425 --> 00:41:34.605 つまり、ご存じの通り、画像は、興味深いものです。
943 00:41:34.605 --> 00:41:36.365 なぜなら実際にはかなり類似している、
944 00:41:36.365 --> 00:41:40.245 あるいは同等だからです、ええと、nl、つまり、
945 00:41:40.245 --> 00:41:44.245 言語と、という意味では、ええと、しばしばメタデータが欲しくなります。
946 00:41:44.245 --> 00:41:46.325 そしてこれは、この話の中で私が控えめに述べすぎたと
947 00:41:46.325 --> 00:41:50.135 思うことの一つですが、ええと、feast では
948 00:41:50.135 --> 00:41:53.295 単なる文
949 00:41:53.435 --> 00:41:54.575 やトークンだけでなく、追加情報を保存できますよね？
950 00:41:55.075 --> 00:41:57.215 ええと、そしてそれに対して最適化できる豊かな構造が
951 00:41:57.215 --> 00:41:58.335 たくさんあることが分かっています。
952 00:41:58.335 --> 00:42:01.335 そして、そして実際にレコメンダーシステムで働いているなら、
953 00:42:01.355 --> 00:42:04.135 分かると思いますが、そして、基本的には RAG を
954 00:42:04.195 --> 00:42:06.975 レコメンダーまたはランキング検索システムであると還元できます。
955 00:42:07.875 --> 00:42:10.055 そして、非常に豊かなメタデータがたくさんあり、
956 00:42:10.055 --> 00:42:13.175 それを使って、ええと、
957 00:42:14.505 --> 00:42:17.795 単なるテキストそのものに加えて、このテキストを強化できます。
958 00:42:18.375 --> 00:42:19.475 それが意味するのは、例えば、
959 00:42:21.615 --> 00:42:24.235 基本的にはハイブリッドランキングのようなことができる、ということです。
960 00:42:24.255 --> 00:42:26.315 そして、異なる、ええと、
961 00:42:26.415 --> 00:42:28.195 テキストの部分を異なる形でランク付けできます。
962 00:42:28.695 --> 00:42:32.595 ええと、つまりタイトルがあれば、もし、
963 00:42:32.815 --> 00:42:37.135 その、ええと、ええと、ドキュメントの古さがあれば、
964 00:42:37.465 --> 00:42:39.775 これらはすべて、異なる重み付けに使えるものです。
965 00:42:40.155 --> 00:42:44.015 そして、re-ran と呼ばれるモデルをその上に構築することさえできます、ええと、
966 00:42:44.115 --> 00:42:45.495 これらを完全に最適化するために。
967 00:42:45.675 --> 00:42:47.775 ええと、そしてそれは私たちが
968 00:42:47.775 --> 00:42:49.335 カスタマイズを可能にするつもりの領域です。
969 00:42:49.675 --> 00:42:51.655 ええと、そして繰り返しますが、それによってファインチューニングできるようにするためです。
970 00:42:51.765 --> 00:42:55.015 なぜなら、ファインチューニングできる必要があるからです。そうすれば、
971 00:42:55.035 --> 00:42:57.535 サービング時に、どのパラメータが
972 00:42:57.595 --> 00:42:58.975 何で、どのコンテンツ片が
973 00:42:59.275 --> 00:43:01.095 そしてデータをどう構造化したいかが分かります。
974 00:43:01.315 --> 00:43:03.295 そして、そしてそれは非常に難しく、ほとんどコード化されてしまいます。
975 00:43:03.325 --> 00:43:06.135 それは、同じようなRAGではなくて、
976 00:43:06.235 --> 00:43:09.575 ただコンテキストに、ええと、放り込んで、
977 00:43:09.675 --> 00:43:10.735 何がうまくいくか見てみる、というものではありません。
978 00:43:10.835 --> 00:43:13.575 ええと、実際にははるかに最適化されたシステムです。
979 00:43:13.795 --> 00:43:17.455 ええと、だから私は、私は思うのですが、両方が存在する必要があり、
980 00:43:17.455 --> 00:43:19.295 最終的にはどちらも非常に強力でなければなりません。
981 00:43:19.355 --> 00:43:20.615 そしてLMSが良くなるにつれて、
982 00:43:20.615 --> 00:43:21.855 確かにそれも少し良くなるでしょう。
983 00:43:21.855 --> 00:43:26.655 しかし私の、私の、私の長期的な見方では、ええと、常に
984 00:43:26.655 --> 00:43:28.255 これらのシステムの一部をファインチューニングする必要があり、
985 00:43:28.255 --> 00:43:31.135 特に本当の規模に達すると、さらに1%
986 00:43:31.135 --> 00:43:33.495 または2%が大きな財務的影響をもたらします。
987 00:43:34.115 --> 00:43:38.175 ええと、それで、ええ、Batchのスケーリングについては、私たちはすでに、ええ、
988 00:43:38.465 --> 00:43:39.615 Sparkをオフラインストアとしてサポートしています。
989 00:43:39.615 --> 00:43:41.455 それについては言及しました。そしてバッチ変換については、
990 00:43:41.675 --> 00:43:44.055 将来的なある時点でRayを組み込むつもりです。ええ、
991 00:43:44.055 --> 00:43:46.175 他のメンテナーたちがその作業にかなり
992 00:43:46.175 --> 00:43:47.255 乗り気になっている時点でです。
993 00:43:47.755 --> 00:43:49.335 ええと、それからレイテンシ改善です。
994 00:43:49.495 --> 00:43:52.135 私は過去にFeast内の多くの計算
995 00:43:52.795 --> 00:43:55.575 とrefuレイテンシの最適化に時間を費やしました。ええ。
996 00:43:55.635 --> 00:43:57.775 そして私たちは引き続きそこに投資しています。ええと、
997 00:43:57.775 --> 00:44:00.135 なぜならFeastを本当に猛烈に速くしたいからです。
998 00:44:00.395 --> 00:44:01.695 ええと、私は以前、
999 00:44:01.695 --> 00:44:03.175 Fastという会社で働いていたのには理由があります。
1000 00:44:03.675 --> 00:44:07.575 ええと、私たちは速いものが好きなんです。ありがとうございます。
1001 00:44:08.155 --> 00:44:10.055 ええと、Feast Ragのブログ記事があり、
1002 00:44:10.055 --> 00:44:11.335 そこではもう少し詳しく、
1003 00:44:11.365 --> 00:44:13.935 FeastがRAGをサポートする価値提案とは何か、
1004 00:44:13.935 --> 00:44:15.535 そして私がなぜそれにこれほど時間を費やしたのかについて話しています。
1005 00:44:15.995 --> 00:44:17.335 ええと、私は偶然にも、
1006 00:44:17.375 --> 00:44:18.815 NLPのバックグラウンドがあります。ええ。
1007 00:44:18.815 --> 00:44:20.495 ですから、私がFeastのメンテナーになったとき、
1008 00:44:20.495 --> 00:44:22.615 実際、それは1年
1009 00:44:22.615 --> 00:44:23.695 半前にやると言っていたことで、
1010 00:44:23.715 --> 00:44:25.495 そして、ほぼやり終えました。
1011 00:44:25.555 --> 00:44:27.575 ええ、仕事はまだ終わっていませんが、かなり近づいています。
1012 00:44:28.115 --> 00:44:30.615 ええと、Feastのドキュメント、
1013 00:44:30.615 --> 00:44:33.045 Feastのウェブサイト、デモ付きのGitHub repo
1014 00:44:33.385 --> 00:44:35.165 そしてdockingデモ付きのGitHub repoへのリンクがいくつかあります。
1015 00:44:35.265 --> 00:44:38.765 つまり、vissを使ったBasic Ragだけに焦点を当てたものが1つあり、
1016 00:44:39.425 --> 00:44:41.165 そしてもう1つは、そうですね、ええ、
1017 00:44:41.595 --> 00:44:43.645 このdockingデモもVissで含まれています。
1018 00:44:43.665 --> 00:44:46.285 それで私は、私から、ええと、
1019 00:44:46.385 --> 00:44:48.965 Stephanieと、VISの皆さんに、私を招いて
1020 00:44:48.965 --> 00:44:51.325 話をし、Feastの福音を共有する機会をくださったことに大きな感謝を述べたいです。
1021 00:44:51.465 --> 00:44:53.925 ええと、これは、たくさんのragsを食べているロボットの
1022 00:44:53.925 --> 00:44:55.925 生成画像です。
1023 00:44:55.925 --> 00:44:57.365 言うなれば、ragsをfeastingしているわけです。
1024 00:44:57.665 --> 00:44:58.665 ええ、面白いと思いました。
1025 00:45:00.415 --> 00:45:03.165 どうもありがとうございました。そして私はそれが面白いと思います。ええ、
1026 00:45:03.695 --> 00:45:04.845 本当にありがとうございます
1027 00:45:04.845 --> 00:45:06.245 実に詳細なプレゼンテーションでした。
1028 00:45:06.545 --> 00:45:08.725 あの、見てください、チャットでも皆さん笑っていますし
1029 00:45:08.725 --> 00:45:10.845 チャットに書き込んでいるということは、本当に笑ったということです。
1030 00:45:11.505 --> 00:45:12.505 なので
1031 00:45:13.085 --> 00:45:17.525 思うのですが、ええと、皆さんから質問はありますか？
1032 00:45:18.065 --> 00:45:19.245 では手短に、
1033 00:45:19.245 --> 00:45:21.045 なければ、あなたが言及されたことで私の方に1つあるので
1034 00:45:21.045 --> 00:45:22.125 私から始めます。
1035 00:45:22.745 --> 00:45:25.525 ええと、何度か言及されましたよね、あの、
1036 00:45:25.525 --> 00:45:27.325 Feastの低レイテンシのようなことについて。
1037 00:45:28.105 --> 00:45:30.445 ええと、それは何で、正確にはどういう意味ですか？
1038 00:45:30.875 --> 00:45:33.085 通常ターゲットにしているものは何ですか
1039 00:45:33.305 --> 00:45:34.325 あなたなら、すみません。
1040 00:45:34.755 --> 00:45:36.125 はい、それは本当に素晴らしい質問です。
1041 00:45:36.245 --> 00:45:37.845 私の表現が曖昧で、もっと正確に言うべきでしたが、
1042 00:45:37.905 --> 00:45:39.725 でも、あの、私は思うんですが、つまり、もし、
1043 00:45:39.725 --> 00:45:42.045 オンラインで何かを提供しているなら、ええと、
1044 00:45:44.895 --> 00:45:47.825 通常、非常に大規模なスケールでは、こう言うことになります。
1045 00:45:47.825 --> 00:45:50.585 自分のレイテンシのパーセンタイル分布はどうなっているのか？
1046 00:45:50.585 --> 00:45:54.185 ですよね？その通りです。それで、ええと、通常、人々はP 99に注目します。
1047 00:45:54.385 --> 00:45:56.105 なぜならP 100では大変なことになりますが、
1048 00:45:56.205 --> 00:45:58.985 でも、P 99なら、それに向けて最適化しよう、ということです。
1049 00:45:59.605 --> 00:46:01.025 そしてデータストア
1050 00:46:01.025 --> 00:46:04.425 やインデックス戦略によって、異なるトレードオフになります。
1051 00:46:04.425 --> 00:46:05.665 そうですね、そして、私は思います
1052 00:46:05.665 --> 00:46:08.625 特にベクトル類似検索については、とても難しいです。
1053 00:46:09.085 --> 00:46:12.585 ええと、それはスケールが比例するからです
1054 00:46:12.585 --> 00:46:14.625 埋め込まれ、取得されるドキュメント数に。
1055 00:46:14.805 --> 00:46:15.985 ええと、なのでつまり
1056 00:46:16.055 --> 00:46:18.585 最終的に必ずぶつかるボトルネックがいくつかあります。
1057 00:46:18.585 --> 00:46:20.715 たとえば100件のドキュメントが欲しいとなると、まあ
1058 00:46:20.715 --> 00:46:23.915 それはかなり難しくなります、つまり、あなたは、
1059 00:46:23.915 --> 00:46:24.955 いくつかのボトルネックにぶつかることになります。
1060 00:46:24.955 --> 00:46:27.515 しかし基本的なエンティティ取得については、ええと、
1061 00:46:27.985 --> 00:46:29.195 私たちはそれを非常によく理解しています。
1062 00:46:29.375 --> 00:46:32.595 ですから、たとえばRedisキャッシュや、または、
1063 00:46:32.655 --> 00:46:34.555 あるいはRedisは非常に高い性能を発揮することになります
1064 00:46:34.555 --> 00:46:36.795 P 99で5ミリ秒を実現できます。
1065 00:46:37.135 --> 00:46:38.275 My SQLデータベースなら、
1066 00:46:38.275 --> 00:46:40.595 P 99でおよそ10ミリ秒にできます。
1067 00:46:41.175 --> 00:46:42.555 ええと、そして、
1068 00:46:42.695 --> 00:46:45.315 さらにそれを最適化し続ける方法はあります。
1069 00:46:45.335 --> 00:46:47.755 しかし、実際にはコード自体の中で、
1070 00:46:47.985 --> 00:46:50.515 なぜなら、ボトルネックになる要因のいくつかは
1071 00:46:50.515 --> 00:46:53.635 基本的にデータベースそのものによるものだからです。結局、
1072 00:46:53.635 --> 00:46:54.635 機能上の限界は
1073 00:46:54.635 --> 00:46:56.835 データベースがどれだけ速くデータベースから取得できるかです。
1074 00:46:56.835 --> 00:46:58.075 そしてそれを行います。
1075 00:46:58.535 --> 00:47:00.675 そして、戦略の1つは、
1076 00:47:00.755 --> 00:47:04.915 余計なことをしすぎない、非常に効率的で最適化されたコードを持つことです。
1077 00:47:04.935 --> 00:47:07.955 処理やシリアライズにかかりすぎていて、
1078 00:47:07.955 --> 00:47:10.555 デシリアライズや、その場でのデータ計算にも時間がかかります。
1079 00:47:11.215 --> 00:47:14.745 ええと、それから2つ目は事前計算です。
1080 00:47:14.845 --> 00:47:17.625 それで、Feast が本当に目指していることの多くは
1081 00:47:17.625 --> 00:47:18.705 事前計算です。
1082 00:47:18.965 --> 00:47:21.185 そして私たちの、私たちのドキュメントで、ええと、
1083 00:47:21.195 --> 00:47:24.545 話しているのは、事前計算が、つまり、ゴールドスタンダードだということです。
1084 00:47:24.605 --> 00:47:27.265 本当に良い顧客体験を望むなら、できるだけ多くを
1085 00:47:27.265 --> 00:47:29.685 事前計算してください。だからこそ私たちはバッチに投資しています。
1086 00:47:30.105 --> 00:47:32.765 具体例として、検索できるようにしたいドキュメントが
1087 00:47:32.765 --> 00:47:34.365 100万件あるとします。
1088 00:47:35.365 --> 00:47:37.705 それらをバッチで埋め込み化し、埋め込みを作って
1089 00:47:37.765 --> 00:47:40.865 可能な範囲でオンラインにアップロードする必要があります。
1090 00:47:41.065 --> 00:47:44.105 なぜなら、それを毎回その場でやろうとすると、
1091 00:47:44.765 --> 00:47:47.105 ターミナルで今まさに体験したことが起きるからです。
1092 00:47:47.115 --> 00:47:48.745 つまり、時間がかかるということです。
1093 00:47:48.895 --> 00:47:51.145 つまり、実行しなければならない計算に
1094 00:47:51.445 --> 00:47:53.465 縛られることになります。
1095 00:47:53.465 --> 00:47:55.465 もちろん、それらを、ええと、
1096 00:47:55.505 --> 00:47:57.945 並行して行って、少し効率化することはできたでしょう。
1097 00:47:58.205 --> 00:48:01.065 しかし実際には、その計算コストを支払わなければなりません。
1098 00:48:01.445 --> 00:48:06.145 だから、可能なら、ユーザーがあなたの、あなたの、ええと、あなたの
1099 00:48:06.145 --> 00:48:07.705 アプリケーションに来る前に支払ってください。
1100 00:48:07.725 --> 00:48:09.025 それが常に可能とは限りませんよね？
1101 00:48:09.025 --> 00:48:11.265 ユーザーが自分のドキュメントを
1102 00:48:11.285 --> 00:48:12.825 アップロードしてくるなら、その場合は待つ必要があります。
1103 00:48:12.945 --> 00:48:14.225 処理しなければならないからです。一度は必要です。
1104 00:48:14.285 --> 00:48:17.785 でも、アップロードしたい古いドキュメントがあり、
1105 00:48:17.965 --> 00:48:19.985 すべてのユーザーがアクセスできるようにしたいなら、
1106 00:48:20.135 --> 00:48:21.745 それは絶対に、ずっと前に
1107 00:48:21.745 --> 00:48:23.265 やっておくべきだったことです。
1108 00:48:23.725 --> 00:48:25.825 ええと、それから、それをアップロードするのです。
1109 00:48:25.965 --> 00:48:29.145 それで、ええと、ただ繰り返しますが、beast レイヤーでは、
1110 00:48:29.245 --> 00:48:32.425 私たちはコードベースを最適化し続けて、
1111 00:48:32.425 --> 00:48:34.105 できるだけ軽量で効率的にしていきます。
1112 00:48:35.765 --> 00:48:38.075 ありがとうございます。それから1つフォローアップすると、つまり、
1113 00:48:38.075 --> 00:48:40.315 使っていたのは、ええと、例えば
1114 00:48:40.315 --> 00:48:42.115 埋め込みモデルやチャンク化をそこで直接
1115 00:48:42.175 --> 00:48:43.315 どのようにカスタマイズするのでしょうか？
1116 00:48:43.315 --> 00:48:45.635 それは docking レベルのようなところで行うのですか、
1117 00:48:45.775 --> 00:48:46.955 それともどこで機能するのでしょうか、もし、
1118 00:48:47.135 --> 00:48:49.675 できます。docking には、実際にカスタマイズできる、ええと、
1119 00:48:49.815 --> 00:48:51.915 非常に幅広い、ええと、能力があります。
1120 00:48:51.915 --> 00:48:54.555 それで、ええと、その docking のすべてのパラメータの
1121 00:48:54.555 --> 00:48:56.235 全体像を私が知っているわけではありませんが、
1122 00:48:56.235 --> 00:48:58.275 それらはドキュメント化されていて利用可能です。しゃれのつもりです。
1123 00:48:58.615 --> 00:49:02.595 ええと、そして、私が言いたいのは、もしあなたが、
1124 00:49:03.775 --> 00:49:06.475 もしあなたが、例えば「まあ、
1125 00:49:06.475 --> 00:49:08.635 自分のデータは donly にうまく合わない」というサブセットに入らないなら、それは実際には一部です
1126 00:49:08.635 --> 00:49:12.485 Feast の要点は、どんなテキストデータを持っていても、
1127 00:49:12.545 --> 00:49:15.325 それが単なるテキストであるなら、これが Feast の作られた目的であり、
1128 00:49:15.325 --> 00:49:17.725 使いたい sentence transformer を何でも選べて、
1129 00:49:17.725 --> 00:49:20.365 使いたい PyTorch コードを何でも、ええと、
1130 00:49:21.165 --> 00:49:24.165 使いたい tokenization 戦略を何でも選べて、そのすべてを
1131 00:49:24.165 --> 00:49:26.605 実行できるということです。なぜなら、あなたには、
1132 00:49:26.605 --> 00:49:27.925 ほら、何でも提供できると言えるツールキットがあるからです。
1133 00:49:27.945 --> 00:49:30.045 任意の関数を実行できます。
1134 00:49:30.385 --> 00:49:32.845 ええと、feature transformations の中で他の APIs を呼び出すことは
1135 00:49:32.845 --> 00:49:34.045 おすすめしません。
1136 00:49:34.235 --> 00:49:36.005 そうする人もいますし、それはそれで構いません。
1137 00:49:36.425 --> 00:49:38.925 ええと、でも、そういうところから、
1138 00:49:39.545 --> 00:49:41.405 レイテンシを持ち込み始め、
1139 00:49:41.405 --> 00:49:43.125 実際にシステムがより複雑になっていきます。
1140 00:49:43.265 --> 00:49:47.125 でも、ええと、その詳細は置いておくとして、ええと、
1141 00:49:48.105 --> 00:49:50.805 Feast の柔軟性というのは、つまり、ML engineers が、
1142 00:49:51.145 --> 00:49:54.125 こうしたものをどう設計するかについて非常に豊富なドメイン知識を持つ
1143 00:49:54.875 --> 00:49:58.445 専門家であることが多く、ええと、ここで本当に
1144 00:49:58.445 --> 00:49:59.765 舵を取れるという点にあります。
1145 00:50:00.395 --> 00:50:01.485 わかりました。それで、はい、
1146 00:50:01.765 --> 00:50:03.605 実は追加で、もう少し Phil
1147 00:50:03.605 --> 00:50:05.005 哲学的なレベルの話なんですが、すみません。
1148 00:50:05.585 --> 00:50:08.445 ええと、あなた方の主なユーザーは ML engineers ですよね。
1149 00:50:08.515 --> 00:50:10.965 私自身が ML engineer だった数年前には、
1150 00:50:10.965 --> 00:50:13.245 ご存じの通り、とても人気がありました。
1151 00:50:14.065 --> 00:50:16.085 今はどう機能していると見ていますか、
1152 00:50:16.085 --> 00:50:18.485 新しい AI engineers との関係では、つまり、
1153 00:50:18.485 --> 00:50:21.765 彼らは多くの、いわゆる API calls や
1154 00:50:21.825 --> 00:50:23.325 LMS を直接使ったりしていますよね。
1155 00:50:23.325 --> 00:50:25.325 Feast と AI engineers、そして人間のエンジニアの
1156 00:50:25.325 --> 00:50:27.005 未来をどのように見ていますか？
1157 00:50:27.555 --> 00:50:28.725 ええ、それは本当に良い質問です。
1158 00:50:28.965 --> 00:50:31.525 私たちはオープンだと思いますし、間違いなく、つまり、私は、
1159 00:50:31.645 --> 00:50:33.765 AI engineers に対応するのが大好きです。
1160 00:50:33.885 --> 00:50:35.325 本当にそうしたいです。思うに、ええと、
1161 00:50:35.705 --> 00:50:37.685 そしてもちろん、私は、ええと、
1162 00:50:37.695 --> 00:50:40.965 CHIP の本 AI engineering を共有しなければならないのですが、ええと、その中で、私は、
1163 00:50:40.965 --> 00:50:43.285 これについてよく話していて、彼女は
1164 00:50:44.665 --> 00:50:46.845 AI engineering は ML engineering から生まれた、と述べています。
1165 00:50:46.995 --> 00:50:49.245 はい。本質的には、もう foundation model を
1166 00:50:49.245 --> 00:50:50.685 トレーニングする必要がないということです。
1167 00:50:50.745 --> 00:50:52.125 それを単なる endpoint として扱えます。
1168 00:50:52.265 --> 00:50:54.125 しかし、その他すべての、そして彼女も本の中でそう言っていますし、
1169 00:50:54.125 --> 00:50:56.445 私も自分が書いたいくつかの社内ペーパーで引用したのですが、
1170 00:50:57.985 --> 00:50:59.245 他の問題はすべてまだ残っています。
1171 00:50:59.625 --> 00:51:02.605 Feast は inference のためのものではありません。Feast はデータのためのものです。
1172 00:51:02.905 --> 00:51:04.605 ですから、私たちが直面する Feast の問題は
1173 00:51:04.645 --> 00:51:06.085 すべて存在しています。
1174 00:51:06.385 --> 00:51:09.565 そして他のフレームワークには、おそらく私たちが持っている10年分の
1175 00:51:09.585 --> 00:51:10.645 知識と
1176 00:51:10.645 --> 00:51:13.405 傷跡、ええと、私たちが培ってきたものがないのかもしれません、
1177 00:51:13.405 --> 00:51:14.805 これらの本番システムを構築する上で。
1178 00:51:15.425 --> 00:51:18.005 ええと、でも、それは、あの、多くの
1179 00:51:18.005 --> 00:51:19.365 そうしたものは Feast ではすぐに使えます。
1180 00:51:19.365 --> 00:51:22.205 でも Feast の課題は、
1181 00:51:22.205 --> 00:51:24.965 ML エンジニアリングの言語
1182 00:51:24.965 --> 00:51:29.165 や専門用語にかなり根ざしているので、
1183 00:51:29.355 --> 00:51:31.605 たとえば、あの、AI エンジニアには必ずしもすぐには響かないことだと思います。
1184 00:51:31.625 --> 00:51:33.965 それで、あの、マーケティング的な観点としては、ねえ、
1185 00:51:33.965 --> 00:51:35.085 そのギャップを埋められるかな？ということです。
1186 00:51:35.565 --> 00:51:36.965 それが本当にできるかは分かりませんが、
1187 00:51:37.025 --> 00:51:39.805 でも、私たちが引き続き構築を進めて、
1188 00:51:39.945 --> 00:51:42.565 そうした人たちの成功も後押しできることを願っています。
1189 00:51:43.145 --> 00:51:46.325 ええ、もちろん歓迎していますし、私がこのドキュメントを作り込んだ理由の一部は、
1190 00:51:46.325 --> 00:51:48.805 そして、私たちが行ってきたデモも、実際に、
1191 00:51:49.425 --> 00:51:53.445 AI エンジニアのところへ行って、ほら、
1192 00:51:53.445 --> 00:51:54.805 もし本当に、本当に高度なことをやりたいなら、
1193 00:51:54.805 --> 00:51:56.565 そこへの道筋はこれです、と言うためなんです。
1194 00:51:57.145 --> 00:51:58.365 ここにその道があります。
1195 00:51:58.785 --> 00:52:03.415 でも私の、強い確信を持っている賭けは、実際には
1196 00:52:03.415 --> 00:52:05.775 ML エンジニアの数は増え続けるということです
1197 00:52:06.125 --> 00:52:07.735 AI エンジニアが増えることによって。
1198 00:52:07.895 --> 00:52:10.135 というのも、次第に、ああ、実は自分は
1199 00:52:10.535 --> 00:52:12.255 こうした調整を全部やりたいし、
1200 00:52:12.275 --> 00:52:14.815 こうした追加機能や仕掛けを全部載せたいんだ、
1201 00:52:14.815 --> 00:52:17.815 なぜならその 2% が今や本当に価値を持ち始めるからだ、
1202 00:52:17.835 --> 00:52:19.975 そして AI エンジニアリングは本当にそれを可能にするんだ、と気づき始めるからです。
1203 00:52:20.035 --> 00:52:23.725 それで、ええ、それが私の見方のようなものです。
1204 00:52:23.725 --> 00:52:25.205 でも、でもそれは、これらのものには
1205 00:52:25.205 --> 00:52:26.885 最初に支払わなければならないコストがかなり多くあります
1206 00:52:26.885 --> 00:52:29.205 単に、たとえば、その、
1207 00:52:30.315 --> 00:52:32.045 エンドポイントか何かを呼び出す、みたいなことに比べると、そうでしょう？
1208 00:52:32.045 --> 00:52:33.445 あるいは単に Pandas を使って
1209 00:52:33.445 --> 00:52:35.685 それを何かに流し込む、といったことですよね。
1210 00:52:35.705 --> 00:52:37.525 あるいは face、ですよね？こうしたものすべてです。
1211 00:52:37.865 --> 00:52:39.125 だから、私は認めています
1212 00:52:39.125 --> 00:52:41.045 それはエンジニアリング上の課題が増えるということを。
1213 00:52:41.045 --> 00:52:42.565 とはいえ、私たちは
1214 00:52:42.565 --> 00:52:44.085 人々が始めやすいように、かなり簡単にしようとしています。
1215 00:52:45.035 --> 00:52:46.445 いいですね。どうもありがとうございます。
1216 00:52:46.785 --> 00:52:48.565 そして、ちょっと待って、でもそうですね、願わくば
1217 00:52:48.565 --> 00:52:51.285 それ以外でも、あの、たくさんの
1218 00:52:51.285 --> 00:52:54.285 AI エンジニアがいて、多くの人が、あの、
1219 00:52:54.305 --> 00:52:55.445 Feast を使いに来ることになるといいですね。
1220 00:52:55.705 --> 00:52:58.165 あの、実は私自身も数年前に使っていたので、
1221 00:52:58.165 --> 00:53:00.205 今もまだここにあって、あの、
1222 00:53:00.255 --> 00:53:01.405 しっかり生き続けているのを見るのは嬉しいですし、その、
1223 00:53:02.355 --> 00:53:03.965 ええ、取り組んでいますよ。これは、あの、
1224 00:53:03.965 --> 00:53:04.965 ええ。
1225 00:53:05.825 --> 00:53:08.045 そして、はい、改めて皆さんへ。これは録画されています。
1226 00:53:08.385 --> 00:53:10.845 あの、編集などが終わったら
1227 00:53:10.845 --> 00:53:12.085 数日後に共有します。
1228 00:53:12.085 --> 00:53:13.725 ですので、もしご友人にも送りたい場合は、
1229 00:53:14.505 --> 00:53:15.925 ええ、どうぞご自由に。
1230 00:53:15.925 --> 00:53:17.245 Arthur、素晴らしいプレゼンテーションでした。
1231 00:53:17.265 --> 00:53:18.725 本当にありがとうございました、F Francisco
1232 00:53:19.705 --> 00:53:22.645 そして、いつかお会いできることを願っています。
1233 00:53:22.825 --> 00:53:25.330 また、何人かの方々にもfeastを使っていただき、
1234 00:53:25.425 --> 00:53:26.525 その良さを実感していただければと思います。
1235 00:53:27.735 --> 00:53:29.085 ありがとうございます。本当にありがとうございました。
1236 00:53:29.215 --> 00:53:31.925 皆さん、ありがとうございました。そして、世界のどこにいても、素敵な朝、午後、
1237 00:53:31.945 --> 00:53:33.285 あるいは夜をお過ごしください。
1238 00:53:33.665 --> 00:53:34.005 またお会いしましょう。
Join the Webinar
Loading...
Meet the Speaker
Join the session for live Q&A with the speaker
Francisco Javier Arceo
Senior Principal Software Engineer
Francisco Javier Arceo has spent over a decade working in AI/ML, software, and fintech at AIG, the Commonwealth Bank of Australia, Goldman Sachs, Fast, Affirm, and Red Hat in roles spanning software, data engineering, credit, fraud, data science, and machine learning. He holds graduate degrees in Economics & Statistics and Data Science & Machine Learning from Columbia University in the City of New York and Clemson University. He is a maintainer for Feast, the open source feature store and a Steering Committee member for Kubeflow, the open source ecosystem of Kubernetes components for AI/ML.