レイトチャンキングの紹介
- 香谷さん、こんばんは。 こんばんは。 お願いします。
- お願いします。今日は、最近おそらくホットなLate Chunkingという、ラグの新手法みたいなやつについて、背景情報とかを交えて語っていこうかなと思います。
Late Chunkingが何かっていうのを語る前に、ちょっとした背景情報としては、この手法を提唱したのが、Jina AIっていう、
多分、結構最近有名になってきた感を私は感じてるんですけど、
どういう会社なのか、私もあまり実は予測までつかめてないんですけど、
エンベディングモデルとか、リランカーとか、セマンティックチャンキングのAPIとかをですね、
これイングリッシュだけじゃなくて、マルチリンガルで、
だから日本語でも結構ちゃんと動くんですけど、っていうのをいろいろ出してて、
ラグ界隈では注目の企業みたいなイメージを勝手に持っているんですが、
香川さん、このJina AIって聞いたことはあります?
はいはいはい、めちゃくちゃちゃんとマッチしてるとかじゃないですか、それこそあれですよね、
リーダーAPIとか出してるとこですよね。
リーダーAPI、なんかあれですっけ、HTML。
YESYES、テキストというか文章とか、LM使ってパースしてくれる系のやつ。
リーダーAPIとかで最初知って、ちょっと前後関係覚えてないですが、
エンベディングモデルとかリランカーとか、その辺のやつとかいろいろ出してるなっていうのは認識してますが、
そんなちゃんとリーダーAPI以外は触ったことはないですね、正直。
私も本業でそんなにラグやってないんで、落とし身程度に触ってるぐらいなんですけど、
多分ラグやりやしたらちょっと触りたくなってくる感じなのかなっていう感じですね。
今回本題のレイトチャンキングなんですけど、そんなGINAっていう会社が、
ざっくり言うと何かっていうと、
ラグをするときに文脈を踏まえた上での精度も多分上がるし、
あとちょっとチャンキングする手間とかも減るおそらくみたいな感じの、
ちょっと逃げ切らない感じで説明してるんですが、そんな感じの地方ですね。
最初に概要だけざっくり言うと、
レイトチャンキングっていう名の通りなんですけど、
一般的なベクトル使ったリトリーバルっていうのって、
ドキュメントを事前に自然文としてチャンクにして、
それのエンベディングを作っておいて、
クエリもエンベディングにしたものとの類似度、
多分コサイン類似度とかがよく使われてると思うんですけど、
を比較して類似度とって引っ張ってくるって感じなんですけど、
レイトチャンキングはそのドキュメントの方のエンベディングが、
事前にドキュメントをチャンクにしていくっていうよりは、
まずドキュメント全体をエンベディングにします。
そのエンベディングをさらに細かいエンベディングに分けていく。
なのでチャンキングがエンベディングにしてからさらに行われる、
みたいなところがレイトチャンキングっていう名前の由来っていう感じですね。
これが最近いい感じなんじゃないかと話題という感じですね。
レイトチャンキングの利点
レイトチャンキングが何を解決しているかっていう話なんですけど、
そもそも今のラグの一般的なレイトチャンキングを提唱してたりする人たちは、
内部チャンキングって言うんだったりするんですけど、
課題感としては結構短いクエリと長いドキュメントのチャンクの類似度を
測るのが微妙だっていう話だったりとか、
それに対する回答としては一旦コサイド類似度で取ってきた、
バーっといっぱい取ってきたものをリランキングとかしてさらに絞るみたいな、
そういうやり方とかもあったりはするんですけど、
そもそもそういう類似度で引っ張ってくれるようないいチャンクを
元のテキストから作るのがちょっと難しいというかひどくさいと言いますか。
チャンクに単純に分解していってしまうと、
文脈の情報が失われてしまうっていうところがあって、
一例としては指示号みたいなもの、
〇〇は〇〇だったみたいな後に、
指示号はそれですね、それは〇〇だったみたいな、
こういう2つの文章があったときに、
後者だけ取ったときにそれが何を指すかみたいなものが入らなくなっちゃうと。
そういうのも含めた、
もしかしたらセマンティックチャンキングのやり方によっては
そういうのまで含めてできるかもしれないんですけど、
やっぱりチャンキングしていくときに注意が必要であったりとか、
かといってチャンキングをいろんな文脈情報も含めた上でまとめると
大きくなっていってどんどん、
それはそれでエンベディングにしたときの品質が微妙になってくるとか、
じゃあそういう文脈情報も踏まえた形で
リトリバルしてこれるようにようやくのレイヤーを一個挟むとか、
そんなチャンク作っていく上でいろんな工夫がなされてると思うんですけど、
ラグやっていく上でこのいいチャンクを作るっていうのが
結構めんどくさいポイントとしてあるのかなっていう感じですね。
私の理解ではレイトチャンキングのいいところって、
この文脈情報が取れるっていう点と、
あと裏側で何してるのかアルゴリズムを正直理解していないというか、
おそらく公開されてないんですけど、
そのエンベディングにした後に上手いことさらに分けたエンベディングにしてくれるっていう部分を
吉野にやってくれるっていうところで、
そのチャンキングの手間が減るっていうのが、
このレイトチャンキングのいいところなんじゃないかなっていうふうに思っていますが、
レイトチャンキングの性能評価
ここまで聞いて良さそうだなとか感想とかってありますか。
チャンキングはそうですね、
1年前とか思い出すと、
ラングチェーンでチャンク間で文字数とかオーバーラップさせてチャンクするみたいな、
微妙に便利なユーティル関数をありがたがって使ってるとか、
してたことを思い出しましたけど。
利用者視点で言うと、
レイトチャンキングってAPIがあるっていうよりかは、
エンベディングAPIがあって、
そこにレイトチャンキングモードのオンオフができるとか、
そんな感じのイメージなんですか。
現状このレイトチャンキング使う方法としては、
もしかしたら調べきれてないかもしれないんですけど、
GNANO AIのエンベディングモデルのAPIがあって、
そこでレイトチャンキングっていうのをトゥルーにすると、
それに即したエンベディングとして返ってくるみたいな、そんな感じでしたね。
だからそれこそエンベディングしたいドキュメント群とかを、
これ実際どうやって使うもんなんですかね。
例えばドキュメントとかいろんなドキュメントとかが、
数百個全部ぶん投げたりするわけじゃないじゃないですか、いきなりAPIとかで。
GNANOのほうとかにアップロードして勝手にお品にチャンキングされて、
エンベディングされてチャンキングされて、
そこのVisualsの結果とかだけ返ってくるみたいなインターフェースになるんですか、
このAPIしたいほうが。
巨大エンベディングのどれだけの巨大さというか、
リュードでぶん投げて吉野にやってくれるのか次第では、
結局何かのドキュメント単位とかページ単位とかでは、
こっち側とかで吉野にはやるんですよね、そこはさすがに。
そうですね、それで言うとそもそも現状、
エンベディングモデル自体のコンテキスト帳っていうのが制約があって、
多分今GNANOが出してるモデルが最大8192みたいな感じなので、
だから結局、それが自然文として我々がしなきゃいけない制約としては、
そこがどうしても入ってくるっていうのはあります。
8192トークンをWindowsコンテキストとして、
その範囲内をさまるドキュメント全体は、
良さげなエンベディングしてチャンキングしてみたいなのを、
勝手に裏側でやってくれますよみたいな感じ。
思っている。
多分APIのインターフェース的にはそんな感じですね。
何か分かんないですけど、話聞いてると、
自然言語のエンベディングする前とかに、いわゆるチャンキングすると、
多分よくあるのって、いろいろあるじゃないですか。
文字数とか小単位とか要約も入れてとか、
意味的なまとまりうまくやってとか、
チャンキングの仕方とかっていう。
その辺とか、どう頑張ってもぶった切りになってるとか難しかったりするので、
先にエンベディング全体で作っちゃってから、
チャンキングした方がその辺解消できますよみたいな話だったら、
エンベディング、レートチャンキングできる対象は、
大きければ大きいほど普通に嬉しいような気がするので。
嬉しいよね。
8192にもうちょい頑張ってくれると嬉しそうだなっていう、
雑な感想を受けました。
どうですよ。
APIが違うのかな。あってんのか。
でも多分そういう話な気はしますよね。
何かこのエンベディングモデルの、
多分そもそもこういうソリューションが出てきた背景としても、
8192トークンっていうのも割と今までのエンベディングモデルと比べるとだいぶ長い。
多分他のやつって512とか1024とか。
そんな感じのイメージですよね。
ちょっとそういうデカいのが出てきたから生まれたのかまではわからないですけど、
そういうのがあるからこそ使える手法みたいな。
逆に言うとちょっと選べるエンベディングモデルは限定されちゃうっていうのもありそう。
そうっすよね。
ちなみにこのレイドチャンキングってそれで精度というかベンチマークとか
いかしら性能向上みたいなのが上がりましたよっていうのが出てるんですか。
公式の記事だけしか読んでないんで、
ちょっと第三者的な視点もあるかもしれないんですけど、
一応ナイブな普通のチャンキングと比べるとNDCGっていう、
ラグの評価指標みたいなやつでエンベディングモデルか。
ラグなのか。
ちょっと浅い理解でしゃべってますが、
プレシジョンとかリコールだけじゃなくて取ってきたものの順番とか、
そういうものも含めて評価するみたいなやつ。
評価指標があるらしく。
それで比べるとナイブチャンキングが64.2%の正解です。
レイドチャンキングだと66.2%みたいな。
データセットによって数パー上がってるっていう感じなんで、
なんかちょっと上がってるみたいな感じですよね。
ちょっと上がってる。
これ実際見てるとノーチャンキングとネイティブチャンキングも、
0.3%ぐらいしか違わないんですね。
そうですよね。
だからめっちゃ精度上がるっていうよりは、
さっき言ったようなチャンキングよしないにやってくれるみたいな方が、
どっちかっていうと目的になるのかなっていう気はしないでもない。
性能向上よりも普通に効率化というか、
自分たちでやらなきゃいけないことが多少さばいて裏では勝手にやってくれますよ。
これあれですね。
レイトチャンキングの基本概念
ノーチャンキングとネイティブチャンキングの違いもなさすぎるから、
ちょっとその計り方をどう捉えればいいのか。
NDCGとかもこれですよね。
ノーマライズドドキュメンティットキュミレイティブゲイン。
ドキュメント検索タスクにおける消化指標の一つで、
ウェブ検索エンジンでの文章検索システム消化指標。
コメントエンジン欄研学習モデルの指標としても使う。
ノーチャンキングとネイティブチャンキングの0.3%しか違いないっていうのは、
どう捉えるかあんまりピンときてないんですけど、
性能は3%とか数%上がって、
これで我々の何かチャンキングとかをする作業が楽になるんだったら、
確かに選択としてあるっちゃあるかなと思いつつ、
おいくらなんでしたっけみたいな話とか、
ジナーAIのレイドチャンキングにベンダーロッキングみたいなことされるんだったらとか、
他のエンベディングAPIとかにまた切り替え直したいとか、
切り替えるときにちょっとどれだけ移行コストかかるんだっけとか次第とかでは、
移行コストはそんなかかんない気がしますけど、
結構その辺したいかなって気がしますね。
8192トークン使える時点で普通に嬉しいのか。
ほぼですね。
エンベディングどうなんだろうな、ロックイン。
エンベディングモデル乗り換えるときって基本大変になるというか、
基本エンベディング全部生成し直しみたいなそういうのが発生するから、
そういう意味ではどれ選んでもそこまで変わらないのかもしれないな。
確かにどれ選んでも大変だったらレイドチャンキングっていう使えるものに乗っかって、
賭けしてみたいみたいな、僕は既視的にはそっちの気持ちは多少はあるんで、
物によりますけど。
一回試してみるかってね。
これもう使えるんですよね、レイドチャンキングは。
そうですね、多分もう使えるし、
ちょっと正直まだ分かってないのが、
ベクター、記事の最近出したエンベディング、
エンベディングバージョン3っていうジーナが出してるモデルのリリース記事みたいなものの中に、
レイドチャンキング使えるようにしたよみたいなことが書いてあって、
ベクトルDBのベンダー、
ファインコーンとかキュートランドとかその辺の有名なやつとも協力して、
使えるようにしてるぜっていうのが書いてあるんですけど、
途中のエンベディングを作る過程がちょっと特殊なだけなら、
なんていうか、ベクトルDBにはそんな依存しない話なのかなとかちょっと思ってたんですけど、
この辺がちょっと、そこもロックインなら、
そこがロックインならちょっと結構問題になると思うんですけど、
エンベディングを作る過程がちょっと特殊なだけなら、
ちょっとそこもロックインなら、
そこがロックインならちょっと結構問題だなとか思ってたんですけど、
そこがまだあんまり分かってないです。
このGNUのAPIを叩けるようにしましたよぐらいの感じにも見えるので、
そういう話ではない?
なさそうな気もしてるんですけど。
そうですね。
レイドチャンキングのロジックとかは分からないんです。
分からないというか、
チューニングするとかって概念はないんですよね。
勝手にやってくれるっていう話ですよね。
多分そこはこっちで自分のユースケースに対して評価とかをして、
GNUを信じるみたいな、そんな感じなのかなっていう。
エンベリングしてからチャンキングしたら、
なんで良しになるのかちゃんとあんまり理解してない?
多分なんですけど、さっき言ったような、
指示語によって文脈が失われるみたいなものがなくなるみたいな、
なんていうんですかね。
もともと指していた語の意味を含んだ状態の
エンベリングになるみたいな、
そういうことなんじゃないかなっていうのは。
自然言語でその辺とかを踏まえてチャンキングするよりも、
一旦エンベリングフィクトルとかにして、
からの方がその辺、
良しなに判断してチャンキングするの楽だよねっていうのが成立してるはず。
確かにさっきリランク、リランカーの話とかも出ましたけど、
アルゴリズムの謎
リランカーも別にその、
チャンキング難いよね問題自体は別に解決してるわけではないとは、
という理解なので、
そこはそこで結局リランク的なものとか、
この後とかにやった方が精度上がるような気はしますが、
チャンキングはチャンキングで新しい手法が出てきてくれたっていう意味では、
確かにポジティブな事象なんだろうなとは思いますね。
正直なちょっとあんまり業務だと使いどころないな、
本業だと使いどころないな正直。
今はなかなか。
使い道ある今のとこあります本業とか。
本業がそうですね、
そもそも本業でラグが今そんな重要じゃないので、
そんな使わなそうではある。
あとちょっとぶっちゃけた話をすると、
どっちかっていうとクエリの方が、
クエリの方にちゃんと文脈情報を埋め込むみたいな方が、
大事だったりするんで、
そっちも解決しないとっていうのはあったり、
そっちの課題は別にビリングの方がどうなろうと解決しないから。
なるほど、クエリ最適化というかクエリ拡張とか、
そっちの話の方がホットなんですね。
確かにそれだと関係はなさそうだけど。
どうだろうな、どうだろうな。
これは本業ではないですけど、
結構法律とか医療みたいな、
専門用語多い系の領域で何かする、
ラグっぽいというかラグとか、
組み合わせていろいろ作るみたいなのをやりたいみたいな、
ユースケースは無きにしもあらずなので、
それと割とナイーブにラグやってると、
なかなか精度出ないなみたいなところとか、
いろいろとやろうとしてるところだったので、
その辺とかでレートシャンキングとかで何かが楽になるか、
何かちょっと性能上がるみたいなのがあるんだったら、
試してみたいなと思いました。
そうっすね。
私も本業ですぐ出番はなさそうだけど、
趣味で試してみたいですね。
こういうのとかをサッと触るだけだったら、
別に個人で勝手に触るよって話なんですけど、
東映それだとちょっと身になんないので、
本業なのか副業なのか個人開発なのか何でもいいけど、
こういうのを真面目に遊べるプレイグラウンドで
いっぱい持っていくってめっちゃ大事だなって思いました。
だから2人で個人開発でガッツリラグする何か作りましょうと。
大事。
ラグ作業までそんなに出番がないと変えない。
最近個人開発が熱が再燃しているのは結構それはありますね。
LMって言うとある程度アルファ版とかベータ版ぐらいだったらパッと作れる。
ソフトエンジニアで普通にフルスタックに言われたコードを書いてたから、
普通にLMも含めて全部パッと作れそうだなって思うけど、
そういうのとかパッと作ってアフブワとか作った方がこういうのとかも試せそうだから、
やっぱどっか機械見つけて真面目にラグ何かやるかっていう感想になりました最終的には。
ラグプロダクトいくというところで。
そうですね。
ちょっと分厚なまとめになったな。
今回レイトチャンキングっていうものに関して話してきたんですけれども、
レイトチャンキングは精度はちょっと上がるかもしれないみたいなところで、
ただどっちかっていうとチャンキングを上手いことやってくれそうみたいな、
そっちのテーマが減るみたいなところが結構美味しそうだなっていう感想でした。
ただエンベディングどうやってチャンクにしてるんだろうみたいなアルゴリズムはちょっと謎に包まれてるんで、
そこはちょっと信じて使うみたいな感じですね。
あとですね、このG9AI結構面白い感じの記事とかプロダクトを特にラグ周りでいろいろ出してるんで、
実用性と今後の展望
ぜひ最近の推し企業と言いますか、私の個人的推し企業なんでよかったらフォローしてみてくださいというところで、
じゃあ今回こんな感じですかね。
はい、ありがとうございます。
はい、じゃあ今回もありがとうございました。
はい、ありがとうございました。
