Join the Webinar
Loading...
セッションについて
LangChainはLLM向けのアプリケーション開発フレームワークです。アプリケーション開発を支援するために、LangChain内のインテグレーション、ユースケース、新しいツールについて議論します。また、検索のためにコードやドキュメントをコンテキストを考慮して分割するさまざまなアプローチについても取り上げます。
学べること:
- LangChainとは何か？
- 人気のインテグレーションとユースケース
- チャンキング戦略
本日は、本日のセッション「Lang Chain を使った l l m アプリケーションの構築」と、ゲストスピーカーの Lance Martin をご紹介できることを嬉しく思います。Lance は Lang Chain のソフトウェアエンジニアで、応用機械学習のバックグラウンドを持っています。Lang chain 以前は、Lance は自動運転車、トラック、配送ロボット向けの認識分野で、マネージャーおよび認識リードとして5年以上従事していました。自動運転に携わる前は、Stanford で PhD を取得しました。Lance には、Zillows の開発者アドボケイトである私の同僚 Gin Tang も同席しています。Lance、そして Yuin、ようこそ。
では、ええと、ここから始めてもいいと思います。ええ、ここに来られて嬉しいです。ええ、Yuin と私は、ええ、数か月にわたってさまざまなプロジェクトやアイデアについて話してきました。ですから、ついにここに来て皆さんにお話しできるのは素晴らしいことです。ええと、導入として、Lang Chain とは何でしょうか？それは、LM を活用したアプリケーションをできるだけ簡単に開発できるようにするアプリケーション開発フレームワークです。そしてそれは、ええと、だいたい3つのレイヤーに分けて考えることができます。
ええと、基盤となるプラットフォームがあり、現在は Lang Smith と呼ばれていて、アプリケーションのデバッグ、テスト、監視のためのツールを備えています。この講演ではその例をたくさん紹介します。それから、ビルディングブロックのオープンソースライブラリもあり、多くのインテグレーションがあります。Viss もその1つで、さまざまなチェーン、さまざまな LMSs があります。それらすべてについて説明します。そして一番上にはユースケース、つまり実際にそれを使ってやりたいことがあり、それについても説明していきます。
ええと、少し文脈として言うと、事前学習済みの LLMs が物事を学ぶ一般的な方法は、おそらく2つあります。1つは重みを更新することです。重みの更新は、テスト前に詰め込むようなものだと考えられます。ええ、ファインチューニングの場合、与えられた指示に対して知識を詰め込んでいるわけですが、事実の想起には実際には悪いという良い証拠がたくさんあります。下にいくつかリンクを載せておきますので、スライドを見るときに閲覧できますが、それは実際に幻覚を増やす可能性があります。ただし、抽出や Texas SQL のようなタスク、つまり入力と出力のペアのコンテキストを変更するようなものには有効です。
一方で、もちろん情報を与えてプロンプティングすることもできます。これは検索、拡張生成、または検索ドキュメントをプロンプトに詰め込むことです。事実の想起には非常に有効です。ですから、これをうまくまとめると、any scale がこのトピックに関する優れたブログ記事で示しているように、ファインチューニングは事実ではなく形式のためのもの、ということになります。
これは、ファインチューニングと検索について考えるときに覚えておくべきことです。検索についてもう少し言うと、一方には、事実上、多くの情報を重みに詰め込んだ事前学習済みの LLMs があります。もう一方には、情報を検索するだけの検索エンジンがあります。そしてその中間に、検索拡張 LLMs、または生成があります。そこでは、実際に何らかのソースからドキュメントを検索します。viss もその1つです。そしてそれを l LM の作業記憶またはコンテキストに詰め込み、タスクを実行させます。今日はこれを可能にする多くのツールについて話します。また最後にファインチューニングについても話し、どのような場合に一方を選ぶかについても説明します。
ええと、まずビルディングブロックです。ドキュメントローダー。これは、実質的にどんな検索アプリケーションでも最初のステップであり、ドキュメントを取得する必要があります。そして、簡単に言うと、私たちには多くのインテグレーションがあります。非構造化データと構造化された独自データの両方に対応できます。ローカルファイル、ローカルテキスト、または公開データ、アーカイブ論文、Twitter、Wikipedia などです。
ええと、これはデータにアクセスして、それを検索に使用できるシステムに入力する方法のようなものです。ええと、現在はテキストスプリッターもあります。これらは、LLMのコンテキストウィンドウが限られているため、しばしば必要になります。一般的なLLMのプロンプトに任意の数のトークンをただ詰め込むことはできません。これはさまざまで、その点については後で話します。しかし、テキスト分割は、大量のテキストを取得し、それらを分割して、それを埋め込み、ベクトルストアに保存する場合によく使われます。
これは検索における非常に一般的な流れで、以降のスライドでそのことについて話していきます。ええと、また注目すべき点として、ある種の工夫を持つさまざまなスプリッターが多数あります。その1つはコンテキストを保持する分割で、ソースドキュメントを取得してチャンクに分割する際に、各チャンクが元のどこから来たのかに関するタグを保持します。たとえばコードを扱っている場合、各コードチャンクには、markdownファイル内でそれが由来する関数またはクラスを示す属性があります。あるいはPDF内のヘッダーや、セクション要約またはセクション部分のようなものです。
そしてこれは、検索や特定のアプリケーションで非常に有用です。ドキュメントの特定の部分について質問したい場合、それを指定する方法があり、ドキュメントのそれらの部分だけを検索できます。この点については後で少し話すかもしれませんが、ここでの重要なポイントは、元のドキュメントからコンテキストを保持するようなドキュメント分割の方法がいくつかあるということです。ええと、ここから少し面白くなります。埋め込みとベクトルストアがあり、もちろんここがVUSの出番のようなところです。
ええと、つまりもちろんロードと分割があり、各分割を取り出して埋め込みを行います。これは基本的に、それを検索しやすい表現のようなものにマッピングすることで、それを保存します。そしてここで注目できるように、L changeは多くの異なる埋め込みやプロバイダーと統合されています。ここで見られるように、埋め込みについてはもちろんホスト型埋め込み、open AIのホスト型ベクトルストアがありますが、たとえばプライベートにすることもできます。つまり、デバイス上の埋め込みを、ECなしで、たとえばベクトルストア側ではchromaを使ってデバイス上で行うことができます。ええと、運用方法に関して柔軟性があります。
プライベート専用でデバイス上のみを望む人もおり、それをサポートしています。あるいは、ホスト型にはスケーリングや速度など多くの利点があるため、もちろんそこにも統合があります。ええと、LLMは、この検索拡張生成の流れにおいて、ある意味アプリケーションの知識センター、知識コアのようなものです。そしてLMS向けに多くの統合があり、現在の状況はこのようになっています。現在の最先端はG PT fourです。
ええと、コンテキストウィンドウは32 Kトークンまで上がり、そこにコストが表示されています。特にanthropics CLO twoはG PT fourにかなり近く、ええと、トークンあたりではより安く、そこにリンクを載せています。それを見ることができます。したがって、少し興味深い点です。ええと、100 Kトークンというより大きなコンテキストウィンドウがあり、これはかなり大きく、およそPDFの75ページに相当します。
ええと、それに加えて、最近非常に人気になったオープンソースモデルがいくつかあります。LAMA tubing oneのコストは無料で、これは素晴らしいことです。700億のバリアントは、コーディングを除くすべてにおいてGBT 3. 5とほぼ同等です。下にそれを示しています。
この最後の列を見ると、LAMA twoのコーディングスコアは29. 9で、GBD threefiveは48. 1です。これは、エージェントやその他のことにおいて、興味深い含意を持つかもしれません。しかし別の、この点の別のポイントは、言語面ではLAMA twoは実際にはGBT three、3.
5とほぼ同じくらい優れているということです。700億の、ええと、パラメータバリアントでは。これは本当にすごいことです。無料で使えるものを持つことができます。そのモデルは実際にはラップトップ上では少し難しいですが、原理的には、十分なメモリがあれば、無料で使えるオープンソースの、ほぼGBD three fiveレベルのモデルを持つことが可能です。ええと、それは、あなたのものです。完全にプライベートです。
それはかなりクールですね。過去1年でオープンソースのエコシステムに何が起こったのかは、ちょっと注目に値します。つまり、ほんの1年前です。ここ左側に見えるような O P T のようなモデルがありましたが、最先端には大きく遅れていました。そして1年で LAMA two が登場しました。これは今言ったように、GBD three five にかなり近いものです。ここで見える大きな違いの1つは、ベースモデルです。
つまり、学習トークン数は約2000億から2兆へと増えました。これは非常に重要なポイントの1つです。もう1つはファインチューニングで、これについては後で話しますが、実際には、これから取り上げる多くのテクニックがあることが分かっています。えー、命令チューニングされたベース LLM は、少なくとも見かけ上の性能では、check T bt check T B T や GPT three five のような非常に高品質な、いわゆる汎用モデルにかなり近い、あるいは匹敵するところまで行けます。えー、それについても少し話します。
そこにはいくつかニュアンスがあります。実際に同じくらい優れているのか、それとも単にそれっぽいだけなのか、という点です。というのも、多くの場合それらは実際にはファインチューニングされていて、命令数を見れば分かります。しばしば shat BT の対話でファインチューニングされているため、えー、本当にその品質レベルにあるのかどうかについてはいくつか疑問がありますが、少なくともチャットの振る舞いはかなりうまく模倣しています。そして今はもちろん LAMA two のファインチューニングにも多くの活動があります。というわけで、それがオープンソースモデルの状況です。えー、これは面白い例です。
これは私の MacBook 上で動いている LAMA two です。私は M two max 32 gig を持っています。なので、これは、まあ、より良い MacBook ですが、見ての通り、これは毎秒50トークンで動きます。ほぼリアルタイムです。かなり素晴らしいです。
えー、そしてこれは完全にプライベートで無料です。えー、私たちには integration sub があり、すべてのインテグレーションを閲覧できます。そこにあまり時間をかけたくありません。最後の質問の時間を残しておきたいので。えー、でもユースケースについて少し話しましょう。
RAG、検索拡張生成について話しましたが、これは典型的なユースケースの1つです。ドキュメントから始めて、それらを分割し、埋め込み、保存し、それから検索します。ここで起こっていることは、質問を受け取り、その質問を埋め込み、ベクターストア内のすべての分割も埋め込まれている、ということです。類似度検索、クロス埋め込み、コサイン類似度を行えます。非常に高速な埋め込みルックアップを行う方法はたくさんあり、先ほど話したように、質問に関連する適切な分割を取得します。
それらを l m のプロンプトに詰め込むと、答えが得られます。これはかなりうまく機能する良いフローです。私たちには、より多く、または少なく選べるいくつかの抽象化レベルがあります。これは ang chain でもかなり話題に上がっていることで、抽象化されすぎているという懸念は理解しています。重要な点は、使えるツールが異なり、ライブラリの中にも使える異なる部分があるということだと思います。
もっと制御したい場合は、low QA chain のようなものを使うと、他の部分を完全に独立して管理できます。エンドツーエンドのパイプラインのようなものが欲しい場合は、すべてをやってくれるようなものも用意しています。なので、あなたのレベルや関心などによります。ただしポイントは、私たちは多くの抽象化レイヤーをサポートしているということです。ここで少し Lang Smith を紹介します。
ここで起きていることは、Lang Smith は先ほど言ったように、可観測性やデバッグのためのツールだということです。そしてここで見えるのは左側で、こうしたパイプラインの1つを実行すると、Lang Smith が内部で実際に起こったすべてのトレースを表示し、自動的にログに記録してくれるということです。なので、実際に何が起こっているのかを見たい場合にはかなり便利です。リンク、トレースを見て、ほら、ここで chat open AI calls まで下に行けます。これは実行中で、GT three five を実行しています。何が入っているのかを正確に見ることができます。
これはちょっとクールです。つまり、これがプロンプトで、やっていることは、次のコンテキストを使ってユーザーの質問に答える、というだけだとわかります。答えがわからない場合は、わからないと言うだけです。そしてここには文字どおり、ベクトルストアから取得したチャンクがあります。これは mildness かもしれなくて、トレース内でここに実行されているのが見えます。
私のマウスが見えるかわかりませんが、私はトレースの方を見ています。retriever が実行されて、その内容が取得されます。Documents chain は取得された docs の内容をプロンプトに取り込み、ここで見えるように、これが docs、これが質問です。そして LLM が docs に基づいてレスポンスを生成します。つまり、Lang Smith のようなツールを使うと、実際に何が取得されているのか、何が起きているのかを非常に簡単に監査できます。
ええと、つまりここで私が強調したいのはそういうことです。さて、チャットは、今メモリについて話したことの一種のバリエーションです。retrieval plus chat も可能です。つまり、多くの retrieval-augmented generation アプリケーションでは、会話履歴をある種永続化して保持するチャットも有効にしています。ここでそれが見えます。
ここには永続化されたチャット履歴があります。それがすべてプロンプトに渡されます。LMM はその履歴全体を持っています。文のようなものを曖昧性解消できて、何を参照しているのかを理解できます。ええと、そうですね、その文はどこでしたっけ？はい、この文です。
I love programming. つまり、それが Chad の利点です。これはかなり直感的だと思います。さて、要約は私たちがかなり多く取り組んできたもう一つの分野で、これは一般的なアプリケーションです。たとえば大量のドキュメント群から始める場合、それらを要約したくなるかもしれませんし、その方法はたくさんあります。
要するに、コンテキストウィンドウに収まるなら、そのまま詰め込めばよく、100K コンテキストウィンドウのモデルなら、それは PDF 75 ページ分で、かなり優れています。しかし収まらない場合には、いくつかのトリックがあります。一つは、ドキュメントを取り、分割し、埋め込み、クラスタリングすることです。つまり、類似した埋め込みを一緒にクラスタリングし、それらのクラスタをサンプリングして、そのサンプルクラスタを NEL に渡します。そうすれば、要約したい本質的なチャンクやクラスタを保ちながら、サイズを大幅に減らせるかもしれません。各クラスタを要約できます。
また、私たちが MapReduce と呼んでいることもできます。ドキュメントを分割し、各チャンクを要約し、それから基本的にその要約群を要約します。ここでユースケースをお見せします。lang chain ではドキュメント内で多くのユーザー質問を受け取っており、それらは ible というサービスによって取得されています。ええと、そこで私たちは 30,000 件のユーザー質問を取り、MapReduce とクラスタリングを使った要約パイプラインに、いくつかの異なる LLM を用いて流しました。
そしてここで、MapReduce で見られた結果が見えます。私たちは、主なテーマや質問は何か、人々は何に最も混乱しているのか、ということを尋ねました。そして、MAP Duce plus OpenAI を使い、Anthropic and Map Duce を使い、OpenAI and clustering を使ったことがわかります。かなり妥当な一致があり、これは良いことです。ええと、しかしこれは、通常は独立して扱いきれないような巨大なデータコーパスを見て、LLM を使って何が起きているのかを統合するための、とても良い方法を与えてくれます。また、各カテゴリで例となる質問を LLM に生成させることもできます。たとえば上位 5 つの質問を出して、と言えば、それをやってくれます。つまり要約は、こうしたケース、つまり明らかに大規模なドキュメント群の要約、大量の PDF の要約、このようなもの、ユーザー質問、サポートチケットなどに非常に有用で、その種のアプリケーションにとって非常に役立ちます。
アプリケーションです。ええと、抽出もまた主要なユースケースです。もし誰かが LLM に JSON 出力を出させようとプロンプトすることに時間を費やしたことがあるなら、その抽出の苦痛を知っているでしょう。簡単ではありません。そこで、ここ数か月で function calling が登場し、これを行うための本当に良い方法になっています。
ええと、OpenAI は function calling をサポートしています。ええと、Claude は Anthropic のものです。Claude は、オープンソースモデルも台頭していますが、ここに良い例があります。入力文とスキーマが与えられると、この function call を行うことができます。これは情報抽出 function で、スキーマに従って情報を抽出し、欲しいものを取り出せます。ではもう一度 Lang Smith を見てみましょう。何が起きているかはここにあります。これは function call からの出力で、こちらがプロンプトです。
基本的には、文章中の関連エンティティを抽出して保存します。この function を使います。ええと、そしてこれがその文章です。つまりこれは実際に LLM に、その function を実際に使うよう伝えています。これは function calling であり、その function は独立した引数として LLM に渡されます。なので、これはうまいトリックです。
これらの function を指定し、それを function calling をサポートする LLM に渡し、プロンプトで呼び出せます。モデルは、適切に指示されればその function を使うことを理解します。そして、JSON 形式や Pydantic のデータクラスに従った、非常に一貫性のある高品質な出力を得られることがわかります。ええ、かなり柔軟です。これは人々が本当に好むもう一つの応用領域です。
皆さんはどうかわかりませんが、私はしばらくソフトウェアエンジニアをやっています。私は間違いなく SQL があまり得意ではありません。SQL を書くのが好きではありません。ええ、そして今では、自然言語から LLM に SQL を実際に書かせることができる、素晴らしい機能がたくさんあります。
ええと、つまり質問やテキストから SQL へ変換することは、非常に一般的で人気のあるアプリケーションです。ええと、また、クエリの実行だけでなく、エージェントの場合には多数のクエリの実行も自動化できる chain や agent もあります。これについては少し後で話しますが、これは実際に見てみるとけっこう面白いです。このトピックについては下にリンクしている興味深い論文がいくつかありますが、人々が見つけたのは、プロンプトの中で LLM に、基本的にこのテーブルには何が含まれているか、そして行がどのように見えるかを示す select 文の例をいくつか与えると、text to SQL でかなり良い性能が得られるということです。それを与えてから質問を与えると、それをかなり効果的に SQL に変換できます。
ええと、その論文ではこれについて述べていて、非常に興味深いのですが、これはまさに私たちがやっていることです。つまり基本的に LLM にテーブルを渡します。ええと、そして裏側で起こるのは、基本的に LangChain がこの抽出を行い、その情報をプロンプトの LLM に渡すということです。つまり LLM は SQL 生成を行うときに、テーブル定義と数行の選択結果にアクセスできます。そしてそこから、ええ、SQL クエリを生成できます。
ええと、次に agent ですが、これはここで話す最後の大きなテーマのようなものになります。これはここ数か月、非常に高い関心を集めているトピックです。ええと、agent について考える簡単な方法があるかもしれません。基本的な LLM にはツールがなく、メモリもありません。LLM にツールへのアクセスを与えることができます。
LLM に API のようなものへのアクセスを与えることができます。ええと、実際に私たちにはそれを行う chain がいくつもあります。ええと、たとえば LLM に検索、検索 function へのアクセスを与えることができます。そしてそれは単にツールへのアクセスを与えているだけです。つまりそれがツールの部分です。
LLM にメモリを与えることもできます。つまりそれは chat のようなものですよね？それについて話しました。LLM がある種の短期記憶を持ち、chat bot の chat や memory と tools、あるいは agents を持っているなら、それが考え方としては簡単かもしれません。この二つの原則を組み合わせているのです。そしてこのエコシステムにはいくつか異なる種類の要素があります。LangChain には、ツール側で agent をサポートするための統合がたくさんあります。さまざまな tool や toolkit、Google search、Gmail、pandas、その他メモリのためにやりたいかもしれない多くのもの、もちろん vector store があります。
VUSs は、長期的な記憶の選択肢の一つとして考えられます。チャットに使われる短期記憶にはバッファのようなものがあり、それからさまざまな種類のエージェントがたくさんあります。今日は action agents について話します。シミュレーションに関する興味深い研究はたくさんあります。ここでは gener agents の論文が非常に興味深く、実際にエージェントにある種の個性を持たせ、ゲーム環境内で実質的に MPCs として振る舞わせることができます。
ええと、それから autonomous agents は、より長期的な計画期間を持つものに近く、auto G P t や baby A G I のようなものです。そして、エージェントに必要な推論行動をサポートするために、さまざまな l l M 統合があります。action agents について簡単に話しましょう。ええと、React は最初に登場した、そして最も人気のある actionagents の一つのようなものでした。ええと、これを簡単に考えると、標準的な prompting を行う l l M は、必ずしも chainof thought prompting による多段階推論を示すわけではありません。
これについては、興味深い pay up logs や研究がたくさんあります。IT LMS は多段階推論を行うことができます。ええと、そしてこれはつまり、lmm に自分の作業過程を示すよう条件付けしているということです。多くの場合、これは think、please think step by step のような、ええと、prompt に含められるタグのようなものです。それが chain of thought です。
Prompting は、作業過程を示すよう条件付けしているだけです。特定のタスクで性能が向上するという経験的証拠がたくさんあります。一方で、エージェントにツール使用を通じた actionobservation によって学習させる研究も多く行われてきました。これは Google から出た興味深い研究で、Sayan 論文では、基本的に L L M にロボット用のツールセットのようなものを装備し、環境と相互作用して観測を返してもらうことができますが、必ずしも多段階推論を行うわけではありません。そこで react は、この二つを一緒にする、つまりエージェントにツールへのアクセスを与え、多段階推論を可能にするというアイデアでした。
では、具体例を示しましょう。例がないとこれはかなり抽象的なので。これは実際に先ほど示した SQL React エージェントです。そして左側の trace を見ると、それが行っていることが分かります。SQL データベースのテーブルを取得するためにツールを使いました。つまり SS Q L DB list tables がテーブルのリストを返します。
ここで prompt に渡されているのが見えますが、ええと、その action からの observation は、ここにある SQL DB 内のすべてのテーブルのリストです。上のほうに action i が見えます、私のマーカーが見えるならですが。ツール／action の矢印が指しているように、これが私が実行した action で、これがその action からの observation です。つまり action は SQL DB list tables です。Observation は、これが私の tables です、そして thought がこのシーケンスの次のステップです。
thought は、invoicing と customer のテーブルの schema を query すべきだ、というものです。新しい action を定義し、その actioninput は invoice と customer で、それが SQL DB schema に渡されます。元の質問は実際ここでは見えません、ええと、あ、すみません、ここに input が見えます。国ごとの total sales を一覧にし、どの国の顧客が最も多く使ったか、です。そしてそれに取り組んでいるわけです。ええと、基本的には tools を使って actions を形成しているのが分かります。
それらの tools は observations を返し、それから次に何をすべきかを考えています。これがまさにこれらのエージェントの動作の仕方です。ええと、これで内部で実際に何が起きているのかについて、ある程度 hands-on な理解が得られるといいのですが。ええと、一つ注記しておくと、agents を使ったことがある人なら、おそらく同じことを経験しているでしょう。これらは最も信頼性が高いわけではありません。
ええと、そして私たちは実際に、ある種の agent のユースケースを持っていました。Web research のようなことをしたい、ええと、agent に質問をすると、それが web を探索して関連 documents を集め、それらを nice report にまとめてくれる、というものです。これについては興味深い open source の取り組みがいくつかあります。G B T researchers です。一つの例として、私たちはこれを取り上げて、実際のところ、この特定のユースケースには retriever で十分であることが分かりました。
ええと、それはエージェントよりもはるかに信頼性が高かったです。ですので、これは、必ずしも常にエージェントが必要なわけではないという注意喚起だと思います。ええと、このケースでは、リトリーバーが検索を実行し、ええ、基本的にHTMLページを読んだりスクレイピングしたりして、それらを変換し、ベクトルストアに保存できます。例えばvisでもよく、質問に関連するチャンクを取得し、それらを要約する、起きていることはそれだけです。ええと、実際にこれを行うホスト型アプリがあります。
こちらが例です、intro Web Explorer。ええと、すべてオープンソースです。リンクはここ下にあります。ご覧のとおり、ここでは、Web検索からあなたの質問に対する回答が生成されています。ソースを得るために調べ上げたすべてのページなども表示されます。
つまりポイントは、私たちはエージェントから始めて、最終的にリトリーバーに行き着いたということで、そして、場合によってはリトリーバーのほうが信頼性が高くなければならないことがわかりました。これは、この特定のアプリケーションに必要なもののほぼすべてです。ええと、では最後のセクションですが、質問のために多くの時間を残しておきたいと思います。なので、少し手短に進めます。ツールと、特にLang Smithについて話します。
Lang Smithのトレースはたくさん見てきました。ええと、ただ繰り返しになりますが、ファインチューニングと、ええと、プロンプティングまたはリトリーバルとの違いについて、この点を強調します。そして、Lang Smithを使ってファインチューニングに関するケーススタディをどのように行うかをお見せします。なお、ファインチューニングはタスク形式の抽出のようなものに非常に適していると話しました。リトリーバルや事実の想起のようなものにはあまり向いておらず、その場合はリトリーバル拡張生成のほうが通常ははるかに優れています。繰り返しになりますが、ソースは下にリンクしています。
そこで私たちは抽出タスクに焦点を当てます。このタスクはやや難解ですが、ナレッジグラフのトリプルの抽出です。もしナレッジグラフを構築したことがあるなら、通常これらは主語・述語・目的語のトリプルから構築されます。そして私たちは、LLMがこの抽出をどれくらいうまく行えるのか見てみたいと思いました。そこで実際に、オープンソースで無料利用できるplaygroundをここに用意しており、任意のテキストを渡すと、このトリプル抽出を実行します。下にトリプルが表示されているのが見えます。実際に私たちはこの例をたくさん収集しました。これは数週間前に公開しました。
多くの人がこれを試し、さまざまな入力、さまざまな、ええ、テキスト入力をアプリに入れました。そしてここ下にこのフィードバックボタンが見えます。ここでLang Smithが登場します。これはLang Smithプロジェクトに接続されており、Lang Smith Connectがそれらすべての出力を収集します。それを、ユーザーが操作しているアプリ内のすべてのユーザー出力、またはすべてのlmm生成だと想像してください。
ユーザーが賛成・反対のフィードバックを与えられると想像してください。それをLang Smithで受け取り、悪いフィードバックでフィルタリングして、よし、LMSがうまくできていない箇所はすべてここだ、そしてそれを改善するためにN L Mをファインチューニングしてみよう、と言えます。これは一種の例示的なケースです。LangSmith内で、これらの生成を比較的大規模に収集できます。悪い生成をすべてクエリしたい場合など、このクエリを実行できますし、データセットを構築でき、それらをLangSmith内ですべて確認してクリーンアップできます。
そしてそれが、こちらで示しているものです。ファインチューニングの部分については、実質的にデータセットを取り、それをトレーニングセットとテストセットに分割し、評価のためにテストします。これもLang Smithがトレーニングセットを可能にします。必要であれば、さらに合成データを作成することもできます。ここではあまり詳しく話しませんが、それもまた興味深い選択肢です。そしてファインチューニングできます。
つまりこれは一種のフローです。Lang Smithを使うと、アプリケーションが動いている場合、それらすべての生成を簡単に収集し、関心のあるさまざまなものに応じてフィルタリングできます。時間かもしれませんし、ユーザーフィードバックかもしれません。それらからデータセットを構築し、そのデータセットを検査してクリーンアップできます。そしてそれらは、あなたがやりたいさまざまなことのために準備されます。1つは評価、もう1つはファインチューニングです。
ええと、私たちの場合は、こういう例があります。このトリプル抽出の課題に取り組み、いくつか異なることを試しました。まず、GBT four と GBT threefive に対して few shop prompting を試しました。base LAMA two seven B を試し、fine tuned lama と fine tuned GBD three five も試しました。これは実際、2、3日前に出たばかりです。chat G B T をファインチューニングできる機能は、とても興味深いです。
それらすべてを Lang Smith で評価しました。Lang Smith は、パフォーマンスについて 0 から 100 までの指標を提供してくれます。そして少し面白いのは、それらすべての evals を監査するための非常に良い方法を提供してくれることです。ここで見えているのはだいたいこういうものです。ドリルインすると、各生成について、その特定の生成のスコアがここに表示され、さらに詳しく掘り下げることもできます。それはすぐにお見せしますし、結論についても話しますが、これは一種のスタックランクを示してくれます。
実際には、few shot G B T が最良で、fine tuned GBD three five が2番目、fine tuned LAMA two が3番目、few shot gbd three、ええと three five が4番目、lama two base fit でした。実際、これはだいたい予想どおりの結果でした。これについてはもう少し詳しく後で話します。まず、ファインチューニングで何が起きているのかをお見せしたいと思います。これはちょっと面白くて、見えるかわかりませんが、これは base laude chat です。
私たちが欲しい回答は、こうした非常に具体的に抽出されたクラスターのようなものだとわかります。基本的にはほとんど J ss o n のようなもので、subject object relation が欲しいわけです、そうですよね？Subject object relation です。ベースラインモデルはそれを知らないので、このようなくだけた形で答えます。ここでの質問は、「この時点で Simpson は Brentwood の自宅に戻り、警察に投降していた」というものです。これはおそらく OJ Simpson についての話です。
ええと、モデルは Homer Simpson を subject として幻覚し、subject は Homer Simpson、object は police、relation は surrenders だと言います。こういう幻覚を起こすわけです。出力がこのような会話調のスタイルになっているのがわかります。これは私たちが望むものではありません。ごくわずかなファインチューニングだけで、かなり近づけることができます。まだ完璧ではありませんし、その点については話せますが、私たちが望む出力スタイルにはずっと近くなっています。
ええと、これはたった千件ほどの instructions でファインチューニングしただけです。ええと、100 と CoLab では、これは5分ほどしかかかりません。とても速いです。意図した出力にかなり近づけられることがわかります。ええと、ではまとめると、質問に移れると思います。
ええと、blank Smith はファインチューニングのワークフローにおけるいくつかの痛点に対処する助けになります。ええと、データ収集、評価、結果の検査です。先ほど言ったように、ええと、ファインチューニングに着手する前に、rag や few shot prompting は必ず最初に検討すべきだとわかりました。G P D four の few shot prompting が実際には最も良いパフォーマンスでした。ただし、より小さく、よりソースなモデルをファインチューニングしても、はるかに大きな汎用モデルを上回れないわけではありません。ええと、fine tuned LAMA chat は実際には GBD three five より優れています。
ですので、それらは、文献や最近のブログ記事で他でも報告されていることと一致しています。ええと、そして Lang Smith がファインチューニングのような実践的なアプリケーションでどのように機能するかの雰囲気も伝わるかもしれません。ええと、それではここで終わりにして、質問を受け付けようと思います。質問をどうぞ。まだ30分しか経っていないと思うので、時間はたっぷりあります。
たぶん私は話すのをやめて、ええと、何か質問やもっと議論したいトピックがあれば場を開きます。素晴らしいです、はい、ありがとうございます。ええと、lane chain におけるこの Ll M アプリ構築に関して起きていること全般について、本当に良い概要でした。ええと、私にはかなりたくさん質問があります。ええと、まずはチャットで皆さんに質問してもらおうと思いますが、ええと、次の1分くらいで質問が入力されなければ、私がどんどん質問し始めます。はい。
わかりました。まだポップアップは見えていないので、このプレゼンテーションには、もっと深く掘り下げたい部分がいくつかあると思います。ええ、それで私が聞きたかったことの一つは、なぜこれらのエージェントはそれほど信頼性が高くないのか、ということでした。もう少し詳しく話していただけますか。なぜ時々エージェントが、ええと、異なる手順を示したり、あるいは、うーん、ええと、時にはその手順を実行できなかったりするのか、例えば手順を繰り返してしまって、それで、ああこれはあまり役に立たないな、となることがあります。そのあたりについて、ええと、もう少し話していただけますか？ええ、まず一つ指摘しておくと、経験的に見て、私はエージェントの部分を経験的に探しているところですが、私たちが見てきたことの一つは、例えばオープンソースのLAMAモデルを使ったエージェントは、ホスト型の、ええと、クローズドソースのプロプライエタリモデルを使ったエージェントよりも明らかに劣るということです。
これについて私が聞いた仮説の一つは、それらがかなり劣っているというものです。そしてデータを示しているところに戻りますが、それらは、ええと、コーディングにおいてかなり劣っており、そこには、コーディング能力、あるいはコーディングに存在するような構造化された推論が、エージェントの挙動にとってかなり重要なものなのではないかという推測があります。それが一つの筋道かもしれません。うーん、二つ目の筋道ですが、率直に言って私はエージェントの専門家ではありません。実際、私はエージェントについてそれほど多くの作業をしてきたわけではありません。
うーん、なので、この分野でより深い専門知識を持つ方々に委ねたいと思います。うーん、ただ率直に言うと、私がエージェントを扱ってきた中で、その内部で何をしているのかを実際に検査することの難しさが、主な課題の一つだと感じました。そしてそれは実際、最近のblank Smithの主な動機の一つでもあります。ここでは実際に、そのトレースと進行を見て、もし行き詰まった場合に、どこで行き詰まったのかを理解できますし、なぜかという問いに必ずしも答えるわけではありませんが、物事がどこで正確におかしくなっているのかを理解する助けにはなります。うーん、それは私がエージェントを扱ってきたときに欠けている要素だと感じました。うーん、なので、一つ目は、コーディングという形での論理的推論が、エージェントにとって非常に重要だと経験的に見てきたものの一つであることは確かだと思います。
二つ目は、実際にトレースできる能力です。それは実装上の問題である可能性もありますし、実際にLMSが混乱しているようなことかもしれません。そして率直に言って、特に誰かのLang Smithを使ってエージェントに入っていくプロンプトを検査できることは非常に役立つと感じました。私はこれを生成エージェント、より最近のシミュレーションエージェントでかなり行ってきましたが、なぜ、どこで混乱しているのかをデバッグする助けとして、実際にプロンプトに何が入っているのかを見るのは非常に役に立ちます。エージェントがどこで、なぜ道を外れるのかについては非常に微妙だと思います。良い可観測性が出発点のようなものだと思います。うーん、今のところ言えるのはそのくらいかもしれません。
いいですね。うーん、ええ、では今、qaにいくつか質問が出てきています。では、ええと、プロンプトの自動評価について話したいですか？見てみましょう、特にプロンプトについてですか？まあ、そうですね、たぶんeval全般についてです。というのも、私も実はeval全般について聞きたいと思っていました。なので、これは両方について話す良い機会になると思います。Evalsは良いトピックです。
それで、私は実は数か月前にAuto Evaluatorというオープンソースのevalアプリを公開しました。そこでの主な直感は、LLM自体に回答を採点させることができる、というものでした。つまり、生成結果と出力文が与えられた場合、L L Mはそれらを見て、それが正確かどうかを推論できます。これはかなり大きなトピックです。実際、これについてはかなり良いopen AI cookbooksがいくつかあります。少し前にセミナーを行いました。
OpenAIの人たちは基本的に、LLMは識別をかなり効果的に行えると主張していました。つまり、ある文、生成結果、そして正解文のようなものが与えられれば、それらをかなり効果的に比較して、これらは事実的に一貫していると言える、ということです。さて、ここで私たちが行っている多くの評価の中心的な考え方は、LLMベースの採点者、通常はGPT-4のようなものです。ここで起きていることは、たとえばこれらのアプリケーションでは、これはこれらのトリプルを出力していることを思い出してください。なので、ここにいくつかの例があるのが見えると思います。これを明示的に見てみましょう。
ここにあるのはmelonsの出力のようなもので、基本的にはこの構造化された、ええと、リストで、ええと、subject object relation、subject object relationがあります。そして参照出力があります。LLMはこれら2つの出力生成を見て、それらがどの程度一貫しているかを評価します。そこには多くの疑問があります。実際、私たちのものをぜひ確認してください。私たちはcollabをオープンソース化しています。
実際に、私たちが使用している採点プロンプトを見ることができ、それを調整することももちろんできます。L L Mを介した評価と採点については多くの疑問があると思いますが、少なくとも私たちが正確に何をしているのかは見ることができます。ええと、要点は、非常に具体的な採点プロンプトを持つLLM採点者を使っているということです。ええと、それはLLM出力と参照の間の一貫性を評価しています。ここにプロンプティングが関わってきます。もちろん、プロンプトを調整して異なる生成結果を出すことができるからです。
実際、私たちはそれをかなり行いましたし、それらの生成結果に対して採点を行い、最も品質の高いプロンプトを決定することができます。これは実際に私たちがかなり行ったことです。ええと、それで、それで評価については十分ですか、それとももう少し深く掘り下げたいですか？もう少し深く？ええと、これは評価について本当に良いカバーだと思います。たとえば、他の人たちが、LLMを使って他のLLM出力を評価するこうした種類のことについてかなり話しているのを聞いたことがありますし、質問した人もその回答にかなり満足しているようです。ええと、次の質問は、ええと、出力のスコアリングや判断のためのデータラベリングツールの使用についてです。
何か考えやコメントはありますか？はい、それは素晴らしいトピックです。最も難しい部分は、つまり、MLをやったことがある人ならある程度わかると思います。MLプロジェクトの厳しい部分はデータの取得で、それが常に最も難しい部分です。そして実際に非常に興味深いのは、下にこれらのノートブックがあり、LLMのファインチューニング自体はかなり簡単だということです。単一のA100、あるいはT4 GPUでも、ええと、指示の内容によりますが15分でできます。
つまりA100では、このタスクについて1,015百件の指示で、5分未満くらいでファインチューニングできました。はい、ファインチューニングの部分は簡単です。面倒で難しいのはデータと評価です。つまり、高品質なグラウンドトゥルースを得ることは、このためには常に最重要です。私たちは、ええと、最終的には公開データを使いました。
つまり、物事を単純に保つために、オープンソースのトリプルデータセットを使いました。一部には、ここに戻るとわかるように、LLMにトリプルを生成させるだけでは基本的に十分ではないとわかったからです。ええと、ここで、もし本当に重要で、これが単なるデモでなかったなら、データラベリングが入ってきた可能性があります。おそらく何らかのものを取得したでしょうし、ラベリングはたくさんあります。私は過去にScaleとかなり仕事をしてきました。ええと、おそらく、はい、合成データを補完するために人間のアノテーションを取得したでしょう。
ここにはおそらく2つの異なる流れがあります。1つは、高品質な人間によるアノテーションを得ることは、どんなプロジェクトにとっても確かに素晴らしいアイデアだということです。合成ラベルは非常に興味深いトピック領域です。望むなら、その深い沼に踏み込むこともできます。結果にはばらつきがあるのを見てきましたが、この場合は非常にうまく機能する可能性があります。
試してみたのですが、実際、私たちのtrueラベルの正確な出力フォーマットに合わせるのはかなり大変でした。syntheticにはいくつか微妙な点がありますが、常に高品質なアノテーションをどう得るかを考えるべきで、人手によるラベリングはスケールさせるうえで素晴らしい選択肢だと思います。もちろん多くのサービスがあるのは知っていますし、率直に言って以前それらと仕事をしたこともあります。とても優れています。ええと、特に高品質なevalセットを作るとなると、そこがいつも一番難しい部分です。
はい、はい、つまり私はn MLで働いたことがあり、完全に同意します。つまり、人々がこのことについて私に尋ねると、私は、そうですね、一番重要なのは良質なデータを持つことです、ですよね？と言います。彼らはそうします。ええ。ええと、はい。では次の質問は、ええと、誰かが分割にLLMを使っているというものです。ええと、でも、知りたいのは、ああ待ってください、彼らは、私たちが、そのl l mモデルにテキストを分割させ、semantic bound boundariesを作らせていると言っています。おそらくこの単語はそういう意味だと思います。
ええと、分割やchunkingを行うためにl mモデルを使うことについて、どう思いますか？それは興味深いですね。私は見たことがなく、なぜなのか知りたいです。ええと、直感としては、おそらく似たテキストをまとめたいということは理解できます。これを行う方法はたくさんあります。ええと、まず一つメモしておきます。
実は私たちには、そして、私は、その、共有しますが、実際ここにリンクされていますが、コード向けにある種のintelligence splittingを行うsplitterがあります。そこでは、分割プロセス自体の中で、ええと、classesやfunctionsをまとめたままにします。つまり、これはあなたが言っていることに近い一例です。もう一つは、分割するこのコンテキストでmetadataを保持するということです。たとえば、このP D Fを分割したとして、長いabstractがあると想像してください。それを3つのチャンクに分けます。それらのチャンクには依然としてabstractタグが付いています。
そのため、retrievalでいつでもmetadata filterを使えるので、それらを復元できます。ですから実際には、L l Mに分割させるよりも、このアプローチのほうがおそらく理にかなっていると思います。ええと、ただし、なぜlmmに分割させたいのか、その根拠についてもっと聞くことには前向きです。非常に高品質なmetadata、ええと、基本的にはこれらの種類のツールの一つを使ってチャンクへのattributionを得られるなら、metadata filteringでいつでもそれらを復元できます。はい。
なので、ええと、同意します。ええと、Mason、皆さんがなぜこれをやっているのかについて、もう少しコメントをチャットに落としてくれると、すごくありがたいです。ええと、私個人としても、これは、そうですね、ええと、ある種コスト最適化の観点からも、また、ええと、アーキテクチャ／構造のような観点からも同意します。ええと、次の質問は、G P T 3. 5 slash LAMA twoのfine tuningに使われたタスクとデータ量について、もう少し共有していただけますか？はい。two shotと比べて、またそれがどのタイプのfine tuningだったのか？prompt tuningだったのか、それとも他のparameter efficient fine tuningだったのか、それともend-to-endのものだったのか？はい、その通りです。
では、実はここでこれらのスライドを共有します。blog postsとcollabsはすべてそこにあります。要するに、タスクはこれです。タスクはtriple extractionです。つまり、テキストのチャンクが与えられ、そこからknowledge craft triplesを抽出します。つまり、それがタスク定義です。これについては、品質にばらつきのあるopen source data setsがいくつかあります。
最終的に私たちはtwo carとBenchy carb and benchyを使いました。そして基本的には、train setにsentenceの1500例、ええと、alpha triple pairsがあり、test setに100例ありました。ええと、fine tuningに関しては、LAMA two 70chat modelを使いました。これを単一のA 100 G P U上のCoLabで行いました。Q Lauraを使ったparameter efficient fine tuningを使っています。つまり、モデルのweightsはすべてfour bitで、それは素晴らしいことです。
メモリにちょうど収められます、特に100の範囲内なら、T4でも動きますよね？そして実際に保存しているのは重みのごく一部、おそらく全体の重みの約1%くらいで、基本的にはモデル自体に注入されるアダプターの重みです。つまり実際に保存しているのはそれだけで、すべての計算はFB16で行われます。そしてその2つの低ランク重みもFB 16で保存されます。最後にモデルを再構築し、それをすべてFB 16で保存し、それに対して推論や評価を実行します。起きていることは本当にそれだけです。
なので繰り返すと、7 billionのチャットモデル、laudeチャットモデルがあります。それをメモリにロードするために4 bit quantizationを使っています。するとメモリフットプリントは10ギガ未満くらいのオーダーになります。素晴らしいです。G P U vramに簡単に収まります。parameter efficient fine tuningを行い、パラメータのごく一部、おそらく約1%をfine tuningし、それをFB 16で保存し、フルモデルをFP 16で再構築して保存する、それだけです。
速いですし、それほど高くありません。性能は間違いなく改善しました。もっと良くしたいなら、良くするためのアイデアは山ほどあります。これは単なる簡単なデモでしたが、でもクールです。こういうものがCoLabで動きます。
とても利用しやすいです。ええと、それほど多くの例は必要ありません。重要なのは例の品質だと思います。ええと、今の作業は私が全部やりました。私の同僚がopen AIのものをやって、それがちょうど2日前に出ました。
彼はその特定のものにはより少ない数のinstructionを使いました。たしか、たった、ええと、500とかそのくらいだったと思います。私は、私は戻って確認するべきですね。それは文字通り昨日、最後の最後に追加されたものです。なので、その作業をあまり注意深く見ていませんでしたが、それについても別のnotebookがあります。ええと、そしてかなりout of the boxのようでした。
その場合、parameter efficient関連のことは何も心配しなくてよいと思います。私の理解する限りでは、そうですね、望むなら今一緒にnotebookを見てもいいですが、そのデータをopenに送るだけだと思います。fine tuningは向こう側でやってくれるはずで、その後おそらくモデルcheckpointか何かのhashが返ってくるのだと思います。その方がさらに簡単だと思います。ええと、要するにlama fine tuningはCoLabで非常にうまく動きます。
ええと、A 100があれば13 billion parameter modelもできます。ええと、それにDVD 3. 5のfine tuningも、私の同僚は1時間くらいで終わらせたので、かなり些細なことだと思います。ええ、すごいですね。なので、これらはどちらも検討すべき非常に良い選択肢です。
ただ繰り返しますが、私たちの結論を強調したいです。常にまずより単純な方法を見てください。常にまずragを見て、few shot promptingを見てください。そういったものだけで必要なものが得られることはよくあります。本当にfine tuneが必要なときでも、事実検索のためにfine tuneしないでください。fine tuneは、抽出やtriples、要約、あるいは特定の話し方のスタイル、いわばstyle transferのような形式に関するものにより向いています。
それらはすべて良いfine tuningタスクです。でも、はい、もっと話せます。これは、これは素晴らしいトピックです。はい。ええと、ありがとうございます。
それはかなり、つまり、それについて非常に包括的な回答でした。ええと、わかりました。LLMに対するguardrailsのpolicy enforcementについてはどうですか？何か考えやコメントはありますか？はい、それは良いトピック領域です。つまり、RAsの、ええと、guardrails libraryは、人気があります。ええと、検討するには興味深いと思います。
私は個人的にはほとんど使ったことがありません。ええと、でも魅力的に見えます。1つ指摘しておきたいのはhallucinationsの話題についてで、retrieval augment generationの部分に戻ると、こうしたpromptを構成するときに、L l mに伝えますよね？適切なcontextの断片を使って質問に答えなさい。答えがわかるなら、ただわからないと言い、何かをでっち上げようとしないでください、と。私の経験では、これはhallucinationsの管理にかなり有効です。もちろん、それが絶対確実だと主張するつもりはありません。
私は、これについてはその上にガードレールを設けることを考えるのが賢明かもしれないと思います。率直に言って、Lang Smith を使うにせよ、そうでないにせよ、評価を構築したり、評価を慎重に実行したりして、アプリケーションがどこで範囲外に出るのかを理解することが、おそらく私が最初にやることだと思います。そのうえで、では、それがプロンプトで対処できるなら、自分のアプリケーションの上に追加のガードレールが欲しいかもしれない、と考えます。それについて言うなら、おそらくそんなところです。ただ私の感覚では、RAG では実際にはすでに、ハルシネーションをかなり制限するようにモデルにプロンプトしていると思います。
ええと、評価によって、どこから漏れ出しているのかが分かり、それに応じて対処することになるかもしれません。場合によってはガードレールで、ということです。ええ、ええ、つまり、RAG で通常やっているのは、ええと、例えば、L L M の temperature をゼロに設定していて、基本的には結果を人間が読めるコンテキストに構造化するためだけに使っている、ということです。その通りです。ええ。わかりました。
それで、誰かが質問しています。ノードコード機能はありますか、それともすべてコードを書く必要がありますか、ありますか、私は、私は、これは実際にはノーコード機能があるかどうかを聞いているのだと思います。ええと、あるいは、そうですね、ノーコード機能があるかどうか、基本的にはそう聞いているようです。わかりました。Lang Chain 全般についてですが、ええと、実際にそれを提供しているオープンソースプロジェクトをいくつか見たことがありますが、今は具体的に思い出せません。探してみるとよいと思います。正直に言うと、それが非常に成熟しているかどうかは分かりません。
ただ、私が言えるのは、ローコードはあるということです。例えば、RAG をやりたい場合には、いくつか選択肢があります。ドキュメントを見ることができます。これを、そうですね、2行か3行でやりたいなら、これを使えます。率直に言って、Lang Chain は抽象化されすぎているということでよく批判されたり指摘されたりしますが、それは完全に理解できますし、だからこそ私は提示しているのです。見てください、Lang Chain で物事を行う方法はたくさんありますし、率直に言って、できるだけ金属に近いところ、いわば低レベルに近いところでやりたいなら、非常に、非常に軽量な、例えば l l m chain だけを使って、あとはすべて自分でカスタマイズすることもできます。
Lang chain は生成のロギングや Lang か何かのためだけに使う、ということです。私は、ええと、率直に言って、その点は完全に理解しています。本番環境では、私はそのようなものを推奨するかもしれません。ただし、私たちには、RAG のような特定のことを2行か3行程度のコードでできるようにする抽象化もあります。ですからローコードであって、完全なノーコードではありませんが、ええと、そうですね、探してみるとよいと思います。私たち自身は何も提供していません。Lang Smith のものは、かなりローコード、スラッシュ、ノーコードです。
ええと、Lang Smith では、文字通り環境変数を設定するだけで、すべてがあなたの Lang Smith プロジェクトにログされ、閲覧したり、そして、そして、そして、つまり、すべて UI ベースです。なので Lang Smith は実際かなりローコードで、それは良いところです。トレースなどのこうしたものはすべて無料で手に入ります。プロジェクトで環境変数を設定するだけで、すべて Lang Smith にログされます。任意のトレースを開いて試すことができます。なので、それは、それは、それはかなり良いです。
わかりました。ええ。ええと、見たところ、ああ、ああ違う、それは、ええと、ええと、そうですね。ええと、たぶんもう1つ質問の時間があると思います。ええと、qa には質問がないようなので。
ああ、誰かが質問しています。ええと、誰かが、私は、わかりました。誰かが length flow または flow wise を使うことについてのあなたの考えを聞きたいようです。これらのツールを聞いたことがありますか？ええ、ええ、それらはロー寄りのノーコード選択肢のいくつかかもしれないと思います。あるいは、ええと、要するに、私はまったく触ったことがありません。ええ、たぶんそれらが何なのか教えてもらえれば、答えられます。私は、それらが何なのか分かりません。
私は一度も、一度も聞いたことがないので、だからこの質問は私には少し混乱します。ええと、名前は聞いたことがありますが、個人的には触ったことがありません。ええ、もし質問者がもう少し文脈を提供したいなら、私は、実際にコメントできてうれしいですが、触ったことはありません。私は、今すぐ調べてみます。Ang flow、私は、ええと、Chain。わかりました。
ええ。ええと、そうですね、実際かなり人気があるようです。Lang Chain 用の Lang Flow UI。ええ、彼が言っていたのはそれです。ちょっとクールに見えます。
Lang Chain パイプラインを実験したり、プロトタイプを作ったりするための手軽な方法で、ええと、ドラッグ＆ドロップ機能のようなものです。GitHub ではかなり採用されているように見えます。確かに興味深そうです。私は個人的にはまだ試していませんが、でも、ええと、コーディングへの適性やニーズなどによっては良い選択肢に思えます。ええ、でも実際かなりクールに見えます。
はい。ええと、では、これ以上の質問に答える時間はもうないかもしれません。ええと、Emily、引き継いで締めくくってもらえますか？もちろんです。ええと、本日のこのセッションに、ええと、お時間を割いてくださった皆さんに感謝したいと思います。そして、ええと、Link Chain チームの Lance には、ええと、非常に多くの素晴らしい情報を共有し、これらのさまざまな概念を一通り説明していただいたことに、特に感謝します。
ええと、Eugene、いつものように共同ホストを務めてくれて、ありがとうございます。ええと、そして今後の Sillas ウェビナーで皆さんにまたお会いできることを願っています。良い一日を。はい、ありがとうございます。では、さようなら。I.
Meet the Speaker
Join the session for live Q&A with the speaker
Lance Martin
Software / ML at LangChain
Lance is a software engineer at LangChain with a background in applied machine learning. Prior to LangChain, Lance spent 5+ years as a manager / perception lead on perception for self-driving cars (UberATG), trucks (UberATG, IKE), and delivery bots (Nuro, following Ike's acquisition in 2021). Prior to working on self-driving, he received a PhD from Stanford.