JupyterLabのお気に入りの場所に来て､ コーディングの準備をしている｡
まず目につくのは､ 2日目のJupyter Notebookがないことだろう｡
実際､ 2日目のJupyterノートブックが5つある｡
また､ いつもよりノートブックを読むスピードが少し速くなるかもしれない｡
さて､ 今日は商品の価格を推定するためのより複雑なアプローチを構築します｡
ええと､ 今日の最大のポイントは､ 同じことをするためのラグ・パイプライン・ソリューションにアプローチしようとすることだ｡
直感的には､ これはラグにとって本当に素晴らしいユースケースだと思う｡
トレーニング・データ・セットには40万点の商品の価格がある｡
そのすべてをデータストアに置いて､ モデルを呼び出すときに､ 似たような製品をいくつか与えて､ この電動歯ブラシの価格を教えてください､
と言ったらどうだろう？
ちなみに､ ここに学習データから似たような電動歯ブラシを5つ選び､ それをモデルに与えて助けてもらう｡
そのためにフロンティア・モデルを使うのはまったく理にかなっている｡
そして､ いくつかの類似点を武器に､ 我々はフロンティアモデルに大きな先鞭をつけていることを想像してほしい｡
正確なデータの宝庫を手に入れたのだから｡
だから､ スウィートスポットにぴったりなんだ｡
そこで､ このノート､ 2. 0ノートブックの8週目のフォルダに､
40万トレーニング・データ・ポイントを含むベクトル・データ・ストアを作成する｡
だから､ それは大きなことなんだ｡
第5週よりもずっと多い｡
次のノートでは2日目｡ 1.
2Dで視覚化し､ 次に3Dで視覚化する｡
これがクイックノートだ｡
でも､ 2日目にこういったことを肌で感じられるのは素晴らしいことだ｡ 3.
そしてラグ・パイプラインを構築し､ テストする｡
そして2日目｡ 4 これが1 in 1ノートで多くのことを行っているところです｡
第6週に見たランダムフォレスト・プロセッサーを復活させる｡
そして､ しかし､ 我々はその改良版をやるつもりだ｡
そして､ すべてのモデルを可能にするアンサンブルと呼ばれるものを構築する｡
基本的には､ 一緒に投票するようなものだと考えればいい｡
彼らは一緒に問題に取り組んでいて､ その中から最良の結果をもたらす直線的な組み合わせを選んでいるのだ｡
だから､ 乗り切らなければならないことがたくさんある｡
私たちはすでに､ 専門のLLMという形で強力な製品プロセッサを構築していることをお伝えしたかったのです｡
それなのに､ なぜこんなに時間をかけているのだろう？
答えは簡単だ｡
さっき言ったとおりだ｡
これは､ 自分の専門性を確固たるものにすることだと考えている｡
ボロ雑巾でもっと練習できるようにするためだ｡
同じプロジェクトに携わりながら､ エージェント・ベースの機能を構築する他の種類の側面について､ より多くの練習を積むことができる｡
だから､ 私たちは自分たちが何をしているのかわかっているし､ 満足している｡
だから､ 私たちがこれからやろうとしていることへのモチベーションを高めてもらえればと思う｡
さて､ これ以上説明することなく､ いくつかのインポート環境変数を実行し､ 私たちが知っている顔を抱きしめてログインする｡
そしてまた､ トレーニング・データを読み込むつもりだ｡ 単純化するために､ 以前から持っているピックル・ファイルをトレーニング・データに読み込む｡
そこで､ トレーニング・データの最初のポイントである燃料ポンプ・モジュールを見てみよう｡
これを覚えていれば､ プロンプトを呼ぶことができる｡
そして､ トレーニングでおなじみのプロンプトが表示される｡
1ドル単位でいくらかかったか｡
そして､ 価格と価値がそこにある｡
オーケー｡
これでChromaデータストアが完成した｡
5週目にこのストアを作ったんだけど､
123個のドキュメントがあったのを覚えているかな｡
そこで今回は､ 400,000ドキュメントのクロマ・データストアを作成する｡
多いね｡
チャンクアップするつもりはない｡
もちろん､ その必要はない｡
これらはすでに小さな塊だ｡
各製品は､ それぞれのアイテムとしてクロマに入る｡
だから､ ラングチェーンをこのボロパイプラインに使うつもりはない｡
ええと､ ラングチェーンは良い､ 有用な抽象化を与えてくれるが､ その必要はない｡
そして､ 今のような熟練したレベルになれば､ Llmsを直接扱うだけでよくなり､
その上に構築される抽象化レイヤーは必ずしも必要ではなくなる｡
だから､ そうするつもりなんだ｡
クロマデータベースを作成します｡
ええと､ 私はもっと早くその定数を外していたかもしれない｡
今すぐそうしよう｡
謝罪する｡
ええと､ ここにもうひとつ､ DBイコール商品アンダースコア・ベクトル・ストアの定数を追加します｡
このノートを使いやすくするために整理していたんだけど､ 整理しすぎたんだ｡
スペルが正しければ､ 私は製品を持っている｡
ベクターストア
これでよし｡
よし､ じゃあ戻ろう｡
一瞬の気晴らし｡
そこで､ そのパスでクロマ・データ・ストアを作成する｡
これでよし｡
存在するかどうかをチェックし､ すでに存在する場合は削除する｡
私はそれを実行するつもりはない｡
それは私が作成したこの製品ベクターストアを削除します｡
そして少し時間がかかる｡
それほど時間はかからなかったけど｡
でも､ これはあなた自身に任せるわ｡
そこで私たちは､ 新しい別のタイプのエンベッディングを使おうとしている｡
私たちはセンテンス・トランスフォーマーというものを使おうと思っている｡
これは､ テキストチャンクを384次元にマッピングするハグフェイスの便利なモデルだ｡
それに､ セマンティック検索などには理想的だ｡
このベクトル埋め込みを生成するのは変換モデルだ｡
以前､ ラグ・パイプラインを構築したときにOpenAIのエンベッディングを使ったことを覚えているかもしれない｡
だから､ この2つを一緒に比べてみると､ このハグしている顔のほうは､ あー､
次元が違う｡
だから､ OpenAIのエンベッディングほど正確ではないだろう｡
でも､ 無料だし､ 速いし､ ローカルで動かせる｡
この最後のポイントは非常に重要だ｡
例えば､ 5週目に私が指定したプロジェクトに取り組んでいて､ Eメールなど自分のものを使って自分だけのラグ・データベースを構築しようとしているとする｡
OpenAIにすべてを送信するのは､ 安全であるべきとはいえ避けたいかもしれない｡
そこで､ ハギング・フェイスのモデルをロードする｡
これは､ 将来的には無視してもいいような警告を与えている｡
このモデルを作成したら､ model dot encodeを呼び出すことができます｡
テキスト文書のリストを渡す｡
返ってくるのはnumpyの配列だ｡
そして､ その中から最初の1枚を抜き取るだけで､ 私のベクトルを得ることができる｡
そして､ かなり早かった｡
そして､ バルクでもうまく機能する｡
このベクトルの長さを見ると､ 384次元あることがわかる｡
印刷すればいい｡
大きな古いベクトルになるだろう｡
あれだ｡
だから､ そのベクトルは､ ある意味では､ 多次元的な反映である方法で､ 数字でうまくハイそこに表している
従った LMに｡
だから､ それは......その......遊んで､ 感覚をつかむ価値がある｡
つまり､ これから書くユーティリティ・メソッドの説明は､ アイテム（項目のひとつ）を受け取り､
それを単なるテキストの塊に変えるものだ｡
最初のトレーニングポイントを見て､ そのプロンプトを見ると､
プロンプトはこのように表示されます｡
その代わりに､ その商品の説明を呼び出すと､ 同じものが表示されるだけだが､
前面に何も表示されず､ 価格も表示されない｡
そのデータをベクター・データ・ストアに格納する｡
そのコードを実行すると､ しばらく時間がかかる｡
そして､ それが完成する頃には､ ベクター・データ・ストアに登録され､ ビジネスの準備が整う｡
すでに実行したので､ ベクター・データ・ストアが作成されている｡
左側に見える｡
今すぐそうすべきだ｡
それが終わったら､ また次のビデオで会おう｡