Join the Webinar
Loading...
セッションについて
Retrieval Augmented Generation（RAG）は、プロンプトにカスタムデータを組み込むことでチャットボットを強化します。大規模言語モデル（LLM）を審査役として使用することは、現代のRAGシステムで注目を集めています。この講演では、RAG評価のためのオープンソース自動化ツールであるRagasをデモします。Christyは、Milvusとcontext F1-scoreやanswer correctnessなどのRAGメトリクスを使用して、RAGパイプラインを評価する方法について説明し、デモを行います。
取り上げるトピック
- Foundation Model Evaluation vs RAG Evaluation
- 人間がラベル付けしたグラウンドトゥルースは必要ですか？
- 人間による評価 vs LLM-as-a-judge評価
- RAG全体の評価 vs RAGコンポーネント評価
- 評価を伴うさまざまなRetrieval方法の例
- 評価を伴うさまざまなGeneration方法の例
本日、今日のセッション「Ragusを使ったRAG評価」と、ゲストスピーカーのChristie Bergmanをご紹介できることを嬉しく思います。ChristieはZillowsの情熱的なデベロッパーアドボケイトです。以前は、あらゆる規模の分散コンピューティングに携わり、またAWSでAIおよびMLソリューションアーキテクトのスペシャリストとして働いていました。Christieは応用数学を学び、独学のコーダーであり、A CM racesとの共著を含む論文を発表しています。ハイキングとバードウォッチングを楽しんでいます。ようこそChristie。それでは本日のセッションを始めてください。
ありがとうございます、Saachi。ええと、皆さんおはようございます。私はKristi Bergmanです。Zillowsのデベロッパーアドボケイトで、今日のデモで使用するオープンソースのベクトルデータベースvisのメンテナーです。こちらが私のLinkedInです。
ぜひフォローするか、つながってください。では、ええと、私たちについて少しだけ、ええと、Zillowはオープンソースのベクトル、Daves Vissのメンテナーで、ベクトルデータベースはオープンソースまたはクローズドソースのいずれかとして考えることができます。ええと、ただ、ええ、私たちの会社はその両方に足を置いています。Linux Foundationに寄贈されたオープンソースのvissがあります。非常に寛大なApache Chewライセンスがあり、つまりオープンソースのvisの上に構築し、さらに製品に料金を請求することもできます。
ええと、ええ、つまりそれはLinux Foundationの、ええと、管理プロジェクトであり、つまり私たちが望んだとしてもそのライセンスを変更することはできません。そしてZIは、A-W-S-G-C-PまたはAzure上で動作するマネージドの、ええと、milsです。そしてZillowsには無料の、無料枠バージョンもあります。ですので、どちら側からでも無料で始めることができます。はい。
ええと、おそらく皆さんは生成AIのこれら3つの柱について聞いたことがあると思います。つまり計算、それはCPU、GPU、TPU、さらにはGR lpuです。そしてモデルは非常に重要です。私たちは、ええと、この小さなものをちょっとどかします。はい。
これを動かせません。ええと、ですので、ええと、モデルには、たとえば、open aiのGPT、ええと、meta LAMA threes、ええと、今日はそれをデモします。ええと、そして私たちは、ええと、最も重要なものは埋め込み、ええと、非構造化データだと考えています。すみません。はい。
ですので、非構造化データには多くの機会があると考えており、ええと、はい、今日はそこに踏み込んでいきます。また、今年のQ4に開催される非構造化データサミットにも注目していてください。では、今日の私のトピックですが、RAGの簡単な紹介をして、それからRAGに関するいくつかの課題について話し、その後RAG評価手法のデモをします。本当にこのものを動かせたらいいのに。F**k。
あ、動いた。やっとです。ええと、では。ええと、ほんの数週間前までは、Geminiにアクセスして、ええと、たとえばニューヨーク生まれの政治家を3人挙げて、と尋ねることができ、そのリストの1つにはHillary Clintonが含まれていました。しかしWikipediaを見ると、ええと、彼女はChicago生まれであることがわかります。
つまりこれはハルシネーションの例です。そして数週間前に、ええと、それが変わったことに気づき、今では選挙や政治家については何も得られなくなりました。では、なぜこれらのLLMはハルシネーションを起こすのでしょうか？ええと、それは、単語またはトークンのシーケンスで訓練され、ええと、次のトークンやマスクされたトークンを予測するようになっているからです。たとえば、the chicken walked acrossを予測するなら、おそらくthe roadでしょう。しかし、ええと、これらの大規模言語モデルは非常に多くのデータで訓練されており、ええと、たとえばおそらくRedditなども含まれていて、ええと、そこにはあらゆる種類の、ええと、普通ではないものが訓練データに挿入されていると想像できます。では、ベクトルはどこから来るのでしょうか？ベクトルは、これらのディープラーニングニューラルネットワークから来ます。ええと、通常は入力を数値にマッピングするための、ええと、たとえば9つ程度の異なるクラスのための、ええと、最終層ではありません。
ええと、ですが最後から2番目の層です。で、その理由は、ええと、研究者たちが、訓練済みの重みがすべてここに保存されていることを学んだからです。つまり、これを、このニューラルネットワーク全体を大きな関数、FFXのように考えることができます。そしてXはインストラクターデータの入力で、fはこれらすべての訓練済みの、ええと、重みを通した変換であり、最後の埋め込み層へとつながります。それが、ええと、FFX equals Yを表しています。Yはベクトルで、これらのYがこのモデルの知識を表しています。それらのベクトルを取り出して保存します。ええと、たとえばベクトルデータベースに保存して、それから、ええと、取得できます。うーん、そこは今は飛ばします。
つまり、それらをragに使えるということです。たとえば、ご存じのように、これがragパターンです。自分のデータを取り、ええと、埋め込みモデルを使って埋め込みます。ええと、それらをベクトルデータベースに保存します。そして通常、その部分はまずオフラインで行われます。その後、自分の、自分の、自分のチャットアプリをデプロイします。たとえば、ええと、ナレッジベースがすでに埋まった状態で。
そしてユーザーがリアルタイムでやって来て、何か質問をするかもしれません。その質問は、ええと、同じ埋め込みモデルを使ってエンコードされる必要があります。そしてベクトルは、ベクトル計算は非常に高速なので、近似最近傍をその場でリアルタイムに非常に高速に計算できます。ええと、ベクトルデータベースから取得されたものを、私たちはコンテキストと呼びます。それを質問と一緒にプロンプトに詰め込みます。
そしてこのプロンプトは別のモデル、生成モデルに送られます。そして私たちはそれらを単にLLMと呼びます。うーん、たとえばChatGPTのようなものです。そうすると、うまくいけば、より信頼性の高い回答が得られます。はい。では、bagに関するいくつかの課題について話しましょう。うーん、まず1つ目は埋め込みモデルの選択です。
そして始めるための一般的な場所は、このHugging Face M tabリーダーボードです。ええと、取得タスクで並べ替えて、うーん、上位ランクのモデルを見ることができます。うーん、そして、はい、1つ選びます。うーん、これについてはあまり話しすぎたくないと思います。うーん、その中の、うーん、ええと、ええと、驚くべき、驚くべき、うーん、今年の進展の1つは、人々は以前、埋め込みベクトルの長さが長いほど、より正確になると考えていたことです。ええと、しかし今年2月のOpenAIの発表で、彼らは、うーん、matrika embeddingsまたはMRL、ええと、matrika representation learningと呼ばれる手法を訓練時に使用することで、実際にはある埋め込みモデルを取り、5、12、または1536、ええと、次元のいずれかを使っても、実際にはより小さい、より低次元のベクトルからまったく同じ精度を得られることを示しました。
ええと、これは重要です。なぜなら、もし、ええと、ベクトルの長さが3分の1くらいで、うーん、それでも同じ精度が得られるなら、保存する必要があるデータ量に対して、メモリが小さく、ええと、データ量も少なくて済むということだからです。また、高速で、ええと、より低いレイテンシ、またはより速い応答時間も意味します。もう1つの課題は、ええと、インデックスの選択です。私たちのドキュメントに行けば、ユースケースに応じて選べる、たくさんの異なるインデックスがあるのがわかると思います。ええと、そうですね、flatというのは全探索を行うという意味です。
これは非常に小さいデータがある場合に適しています。うーん、これはブルートフォース検索です。ええと、a and n、近似最近傍の近似部分は、通常、非常に大きなデータでは検索が確率的だからです。うーん、つまり、インデックスのためにデータ構造を使うということです。ええと、このためのスライドがいくつかあったと思います。
たとえば、この IVF flat はデータ構造としてクラスタリングを使用しているので、ええと、そのうえで検索したいクラスタ数を指定します。ええと、HNSW インデックス型は、ええと、階層的なナビゲーション可能なスモールワールド、または上位に疎なグラフを持つより高次の階層グラフを使用します。つまり、たとえば最上位レイヤーに入ると、そこには検索すべきノードがそれほど多くないため、この最近傍探索は非常に高速で、その後、次のレイヤーに移動します。そこは少し、ええと、より密で、ええと、そしてこのように続けていきます。ですから、ええと、全体的な検索は、これは非常に効率的な検索アルゴリズムです。ええと、レイヤーからレイヤーへとジャンプしていくからです。ええと、実際にはビッグ O で log n です。したがって、大規模データに対して実際に最も効率的な検索アルゴリズムの 1 つですが、異なる、ええと、インデックス戦略を選ぶ理由はいろいろあります。そして最後に、ええと、今日のデモで掘り下げるのはチャンキングです。
そして、最近の RAG パイプラインにおけるチャンキングは、従来のデータサイエンスパイプラインの一部だったデータの特徴量化のようなものだと考えることができます。ええと、たとえば赤、緑、青のような特徴を 1、2、3 にマッピングする必要がある、というようなものです。そして、データを数値に変換するその特徴量化のやり方は、ええと、モデルの精度の結果に違いをもたらすことがあります。今日の RAG におけるパラダイムは、特にテキストデータに対して、このチャンキングのステップです。ですから、ええと、これはある意味、まだ少し職人的な部分があります。なので、これについてもう少し掘り下げます。
ええと、主な、最初の、最初の入り口は、自分がどんな種類のデータを持っているのかを考える必要があるということです。持っているデータの種類によって、会話チャットなのか、あるいはドキュメントなのか、ええと、今日はそれをデモしますが、あるいは Q&A ペアなのか、ええと、講義データなのかによって、ええと、その種類のデータを扱う最も効率的な方法となるさまざまなテクニックがあります。ええと、今日は 3 つのチャンキング方法について少し話します。ですので最初の、ええと、チャンキング方法は、たとえばデータの構造に依存します。たとえば、H TM L データがある場合、私も持っていますが、ええと、その H TML ページにはおそらくヘッダーが含まれていて、それが自然な構造につながります。ええと、そこにはちょっとした難しさがあります。というのも、多くのウェブページ、私たちの Melva docs も含めて、ええと、単純な H one H twos になっていないからです。ええと、それはデモでお見せします。私は自分のものを、ええと、そうではない形にしましたし、このテクニックが全員に機能するとは限らないかもしれませんが、ハイレベルでは、ウェブページというものにはおそらくタイトルがあり、おそらくヘッダーがあります。
そして各、各ヘッダーの中にはテキストがあります。そして単純にナイーブなテキストを取り出して、それだけを埋め込みチャンク化すると、ええと、いくらか、いくらかの、ええと、文脈を失ってしまいます。一方で、それらの、ええと、ヘッダーをテキストの中に入れるだけなら、通常それらは非常に小さいので、テキスト、つまりテキストチャンクサイズの面ではあまり失うものはありません。ええと、実際には、各チャンクにより多くの文脈を入れるための、ちょっとしたハック、近道のようなものです。別の、別のテクニックは、ええと、small to big と呼ばれるもので、小さなテキストチャンクを持ち、そしてそれらをたとえばそのチャンクの親ドキュメントにもマッピングします。たとえばチャンクとして 512 を持っていて、それを親ドキュメントにマッピングする、ええと、そうすることで、再、つまり考え方としては、小さいレベルでベクトル検索を行い、その後、大きいレベルでドキュメント検索を行い、この親ドキュメントを生成のために LLM に送る、ということです。
Okay、ここはたぶん、えっと、飛ばして、えっと、あー、Okay。ちょっと、これはまた別の、えー、RAGパイプラインを最適化しようとするときに考えるべき、えー、面白いスライドです。以前、私たちの非構造化データのイベントの1つで、Link chainから別の登壇者が来ました。そして彼は、干し草の山の中の針の実験について話しました。えー、それが示しているのは、特にこのアーカイブ記事からの研究では、LLMのコンテキストウィンドウにより多くのドキュメントを追加するだけでは、必ずしも良くなるわけではないということでした。ですので、この論文のこのチャートのy軸は精度で、x軸は追加するドキュメントの数、えー、それからそれらのドキュメントの位置です。そして一般的に、追加するドキュメントが増えるほど、精度を失うリスクがあります。
えー、でもここに興味深い曲線があり、それがきっかけで人々はさらに実験を行いました。それらはneedle and haystackと呼ばれていて、緑色の部分がすべて、最も正確な、えー、検索であることを示しました。つまり、最も正確な検索は最初と最後で得られるということです。そして、えー、サンフランシスコで私たちのところに来て話してくれたLance Martinは、実はそれにはもう少し細かな改善点があって、最も高い精度は実際には最後にあると言いました。そして最後に、RAGの、えー、パイプラインで考えるべきLAモデルそのものがあります。上の、えー、私はTwitterでこのMaxine Labonという人をフォローするのが本当に好きです。彼がやっているのは、えー、基盤モデル向けのLM CS leaderboardと呼ばれるものを取り上げて、緑がオープンソースモデル、赤がクローズドソースモデルである、見やすい可視化を作ることです。
そして人々はしばらくこれをかなり興奮して追跡していました。というのも、2つのモデルの精度の差が縮まっているように見えたからです。そして今年ついにそのギャップを超えました。えー、えー、Lama、えー、Lama threeで、実は、いえ、すみません、そのクロスオーバーはClawedでした。えー、そうですね。それから評価について少しだけ。つまり、エンコーダーモデルとデコードモデルがあり、これらは異なるタイプのモデルです。
えー、たとえば私は、えー、hooking faceのエンコーダーモデルを使っているかもしれませんし、open aiからこのGPT-4 ohを選んでいるかもしれません。えー、見てみましょう。ですので、覚えておくべきことは、よく、えー、ツイートされる、えー、リーダーボードのようなものに載っている特定の基盤モデルには、ある種の、つまり研究者によって綿密に追跡されている性能があります。えー、しかし、研究リーダーボードで上位に見えるモデル、つまり埋め込みモデルであれ生成モデルであれ、それがあなたの特定の、えー、システムで最も良い性能を発揮するモデルであるとは限りません。なぜなら、あなたの特定のデータは異なるからです。そして、えー、はるかに低い順位のモデルが、実際には上位のモデルと同じくらいうまく機能することもあり得ます。つまり、より小さな埋め込みや、えー、たとえばよりローカルなモデルで済ませることができ、システム内のコストや、えー、レイテンシを節約できるかもしれないということです。
ですので、えー、これが、自分自身のRAGシステム内で自分自身のデータに対して評価を行うことが本当に重要である理由です。そしてこれは難しいトピックです。えー、私が思うに、えー、念頭に置くべきことのいくつかは、これらのLLM評価、えー、モデルは2023年に出てきたこの概念に基づいているということです。LLM is a judge、えー、UC Berkeley SkylabのJan Stoicaによるものです。えー、これは本当に状況を変えました。というのも、この論文以前は、えー、評価は人間による、えー、アノテーションで行う必要があると考えられていたからです。
そしてこれは本当に高価でした。以前は、人々は、ああ、何千ものデータポイントが必要で、何千もの人間がラベル付けした、えー、そう、人間がラベル付けしたデータポイントが必要だと考えていました。しかしその論文では、実際にはGPT-4は人間と同じくらい優れていることが示されました。そして、これは人間の間でさえ確率性、確率性があり、すべての人間が、回答AとBのどちらがより良いかについて互いに同意するわけではないからです。そして、えー、実際には、人間は互いに約80%の割合で同意する傾向があります。
ええと、そして、これらの評価方法でLMを判定者として、ええと、あるいは批評者として適用すると、それらは互いに、ええと、そして人間とも80%の確率で一致します。つまり、そうですね、人間をLLMに置き換えられる、というのが、そのコンセプトです。そしてこれは評価を本当に変え、自動化された方法で評価を行うことを可能にしました。これからお見せします。ええと、そして、ええと、それからデータポイントについても。そんなに多くは必要なく、もう何千もの人間がラベル付けしたデータポイントは必要ありません。
これは、たとえば20個くらいの、ええと、人間がラベル付けしたデータポイントでなんとかできるということを意味し、評価をずっと取り組みやすくします。ですので、LMを判定者として使うことについては、いくつか注意点があります。私たちが知っているのは、異なる種類のものにスコアを付けるように依頼した場合、たとえば、答えは正しいか、それは、それは、ええと、スタイルは望むとおりか、あるいは完全か、包括的か？といったことです。ええと、LGP ええと、LMSは最初の2つのカテゴリでは非常に優れていますが、完全性タイプのスコアはあまり得意ではありません。ですので、LLMを判定者とする評価では、そのタイプの質問をするべきではありません。そして、olmsを判定者として使うことについて私たちが知っているもう一つのことは、たとえば、ええと、10、1から10のような、ええと、範囲の間でスコアを付けるように依頼したとします。ええと、実際には、ええと、レポートを書くほとんどの人は、それが実は良いスコアリングシステムではないことを知っていますが、仮にそれがスコアリングシステムだったとすると、ええと、人間は中間点の回答をしがちです。ええと、左側にチャートが見えますが、ええと、一方でuhisは極端な値で回答しがちです。
つまり、ゼロか、最高の最小値または最大スコアのどちらかです。なので、それもまた、ええと、私が使うvargasでは考慮されています。これはオープンソースのパッケージです。ええと、それらは、ええと、0から1の間をデジタルスケールでスコアリングします。ええ、これは私が使う予定のexploding gradients、GitHub、オープンソースのragusです。そして彼らが行ったことは、RAGをシステム全体として捉え、ええと、ragをシステム全体として評価するとともに、コンポーネント単位でも評価することです。
コンポーネント単位です。そのragの図は、おそらくコンポーネントの平行四辺形のようなものと考えることができます。そこには、ユーザーのクエリがあり、それから、その質問に答えるチャンクの最近傍探索から、何が取得されるかがあります。ええと、そして、それから、取得されたチャンクがその質問の主要なポイントをカバーしているかどうか、といったことを測定できます。それから、出力を生成するLLM生成モデルがあります。ええと、そして、たとえばそのLMがコンテキストに忠実だったかどうかを測定できます。
そして、ええと、正解の回答があります。ですので、これらすべてのデータポイント、ragのこれらのような、ええと、ええと、コンポーネントの間で、異なるメトリクスを取り出すことができますよね？私のデモです。では皆さん、たぶんこれを少し小さくしたほうがいいですね。Okay。いいですね。では、私はこのデモを、I'll、後でGitHubリンクを共有できます。
ええと、それは私たちの、もし、ええと、VIS bootcampを検索すれば、ええと、それらはGitHubにあります。ええ、これが私の正しい図です。ええと、データを取り込み、それをembeddingモデルに通し、ベクトルを保存し、やって来て、質問検索をします。ええと、あなたの質問をベクトルに埋め込んだものと、あなたのベクトルのナレッジベースとの間にはsabraがあり、ベクトルのナレッジベースから何が取得されるかです。それを質問と一緒にプロンプトに詰め込み、回答を生成します。
ええと、私が評価に使うデータは、ええと、私たち自身の、ええと、ドキュメント、ええと、viss. io docsになります。ええと、それらはドキュメントの公開ウェブページで、技術的な、技術ドキュメントです。そして私はそれらをロードして、ローカルにダウンロードします。ええと、毎回ダウンロードしなくてもよいようにするためです。そして、ええと、それらをクリーンアップし、合計22のドキュメントがあることがわかります。そして、ええと、そうですね、それぞれのウェブサイトを確認できます。デモについても多くの称賛を送りたいです。
これから、ええと、ほら、myzoomがちょっと邪魔なんだけど変えられるかな？Okay、ここで、ええと、おっと、違う、こっちだ。ええと、このリンクも共有します。ええと、これは私が書いたMediumの記事です。ええと、それからGreg Ounに感謝の意を伝えたいです。ええと、彼の元の記事はこちらで、ええと、Tech Splittingの5つのレベルで、chunkyでお見せする予定のもので、そのうち3つをお見せします。
ええと、なので、あります、あります、この、ドキュメントタイプによって、ええと、HTML、小さいものから大きいものへ、そしてsemantic chunkingが、今日デモでお見せするものです。Alright、ではここまでジャンプします。ええと、LLMをpipelines用に、ええと、line chainを使って初期化した方法、みたいなところは飛ばします。ここは全部飛ばします。いくつか事前に用意した質問があります。
Okay、では最初のchunkingメソッド、小さいものから大きいものへです。小さいものから大きいものへ、の考え方は、ええと、スライドでお見せしました。小さいch chunksがあって、それを、再帰的に分割していきます。再帰的な分割というのは、固定長があって、固定のオーバーラップがあって、すべてのテキストをある意味単純に進んでいって、10%のオーバーラップで5、12リンクに分割する、ということです。ええと、それから、それらの小さいチャンクはすべて親ドキュメントに属します。
なので、その親ドキュメントを追跡しておきます。ええと、そうです、これがそのやり方です。たとえばlink chainでは、この2つ、ええと、splitterとretrieverを定義するだけでよくて、ええと、そしてchild splitterを固定リンクに分割します。それから、ええと、見てわかるように、rは予想どおり、いくつかのばらつきはありますが、だいたい5 12あたりです。そして親ドキュメントがあり、私、それはもっと大きいものにするべきです。
なので親チャンクサイズとして1586を選びました。そして繰り返しますが、もし親チャンクサイズを見ると、かなり1586に近いです。ええと、それから必要なのは2つのvector、2つのstoreです。ええと、子チャンク用のvector storeとしてMelvaを使います。そして親チャンク用には、ええと、組み込みのlink chainのdocument storeを使います。
そしてやることは、childとparentを持つretrieverを定義して、それらのドキュメントを追加します。これはvis technical docsからの私のHTML、ええと、webpageでした。これで質問できるようになります。ええと、たとえば、私はそれに、ええ、ある質問をします、ええと、それをretrieverに渡して、ええと、結果出力を列挙します。そして、ええと、ここで質問は、ええと、distance metricは何か？でした。そして、尋ねられたその質問に関連するチャンクを取得できているのがわかります。ええと、親ドキュメントでも同じです。
非常に長い親ドキュメントを取得しているのがわかります。ええと、そしてやることは、それらを、ええと、LLMに送るcontextに詰め込むことです。ここではLance Martinの、ええと、知恵の言葉を活用していて、contextを逆順にして、最も、ええと、関連性の高いcontext、つまり、ええと、top Kの中のtop Kが最後に来るようにしています。そして答えが返ってきます。Okay、デモはあと15分残っているようです。なので、ええと、次のテクニックに移ります。それはsemantic chunkingです。
そしてこれは本当に、これは本当にユニークで、ええと、かなり面白いです。ええと、これを考案してくれたGregにすべて感謝します。つまり、基本的なコンセプトは、あなたの、ええと、私たちが持っている固定長チャンクを取り、隣接するチャンク間のcosign distanceを計算し、それからその距離をプロットする、というものです。隣接距離の外れ値を探します。そうすると、直感的にどこでチャンクの切れ目を作るべきかがわかります。ええと、なので、たとえば、彼はこうした素敵な、ええと、グラフを持っていて、そこで示しています、okay、より直感的な、ええと、外れ値距離に基づいて、これが私のチャンク、1、2、3、などになります、と。
つまり、これがやっていることです。なので再び、ええと、入っていきます、私は、これらをゼロから自分でコードするつもりはありません。実は、これらを全部ゼロからscratch codingしようとしたnotebookはあります。ええと、でも私は、ええ、今回このデモを使います。ええと、line chain sequential semantic、chunker、ええと、libraryを使います。
ええと、特定の埋め込みモデルで初期化するだけです。ええと、先ほどのコードではその部分を少し飛ばしていました。私は Hugging Face のオープンソース埋め込みモデルを使っています。そして、ええ、この時点では、ただ呼び出すだけです。というのも、これは統計を使ってチャンク分割をどこで行うべきかを計算しているだけだからです。そして、この場合、私の 22 個のドキュメントが 87 個のセマンティックドキュメントに分割されたことがわかります。
そして、チャンクリンクを見ると、何かがチャンク化できなかったことがわかります。おそらくコードだけのような Web ページか何かかもしれません。ええと、実はすでに見ていて、それはコードだけの Web ページでした。あまりうまく分割できなかったのです。ええ、でも他のほとんどの、ええと、他の Web ページのほとんどはかなり大きなチャンクに分割できました。ええ、パーセンタイルや、ええと、標準偏差をチャンクポイントとして試すことができます。
ええと、そしてまた、同じ手順に従います。VUS をベクターストアとして使うことができ、質問でテストできます。ええと、質問をして、自分の結果を取得し、取得されたものをループで処理します。ええと、ここではまた IBF flat について尋ねました。私は、ええと、それらを結合して、LLM に送れるコンテキストにしました。ええと、この HTML チャンク化を試しましたが、ここで言わなければならないのは、ええと、私たちの特定のドキュメントは非常に、H1 と H2 に関して非常に扱いにくい構造を持っているということです。見てわかるように、つまり、自分のドキュメントがどのようにコード化されているかを見る必要があります。
そして私のものは、ええ、私は、なんというか、結局これは取りやめました。なぜなら大量のカスタムコードを作ることになってしまったからです。きれいに整った H1、H2、H3 ではなく、ええと、奇妙な解析対象のようなものがあって、それを理解しようとしなければなりませんでした。ええ、でも私は、H T M L ドキュメントを解析するために、かなりスクラッチ的な作業をたくさんしました。ええと、22 個の初期ドキュメントを 63 個の H TML チャンクに分割できます。
ええと、そこから H1、H2、H3 のようなものが見えると思います。ええと、そして取得できた h TM L チャンクリンクを見ることができます。ええと、では、これが私が試した 3 つのチャンク化方法です。それでは戻ります。ええと、まだ 30 分しか経っていないので、このウェビナーはまだ 30 分残っています。はい。
では、ええと、全体として、私たちの rag パイプラインでやっていることは、チャンク化方法をいろいろ試しているということです。つまり、固定長チャンク化をやり、小から大への方法をやり、セマンティックチャンク化をやりました。ええと、最適化のために調整できる他のレバーとしては、チューニング戦略のほかに、埋め込みモデルを入れ替えることや、生成 AI モデルを入れ替えることができます。私のデモでは、実際に、ええと、これから、ええと、見やすいレビューのようなものはありますか？はい、私のデモでは、私は、2 つの異なる埋め込みモデル、Open AI モデルと Hugging Face モデルを入れ替えました。そこまでスクロールしました。
つまり、Hugging Face から、これを使っています。B-A-I-B-G-E large というものです。ええと、これも使えますし、ええと、それから、私が実験を行った方法は、このノートブックを 2 回実行しただけです。ええと、1 回は Hugging Face モデルで実行し、もう 1 回は、ええと、この特定の text embedding three small で実行しました。先ほど示した、より小さい次元の 512 です。1536 と同じ精度が得られるので。ええと、これらが埋め込みモデルの 2 つの反復です。
そして LLM についても反復しました。lms については、ええと、実際に 6 つの異なる、ええと、LLM を試しました。ええと、mixed drill を試し、Meta の LAMA three を試し、ええと、GPT-3 0. 5 を試しました。では、それらを試しているコードにジャンプします。そして、これを見やすくするために目次を追加します。
というのも、自分でもスクロールしようとしていると、少し大変だと気づいたからです。ええと、なので前に目次を追加して、もう一度チェックインします。はい、では、lms を使うときは、ええと、システムプロンプトを作成する必要があります。ええと、ここで私は LAMA three、ええと、alama で反復しました。
ですから、彼らのウェブサイトにある指示に従って、ダウンロードして、lama pip をダウンロードし、lama をインストールして、ええと、LAMA three モデルをプルするだけです。そして、ええと、もしこれをここで実行すると、ええと、あー、正確には long three latest が動いていること、ええと、それが GGUF、ええと、形式であることがわかります。つまり、それは、CPU 用にフォーマットされているということです。ええと、それに、量子化のレベルが最高であることもわかります。ええと、それを見るのはちょっと興味深いです。で、それは、それは理にかなっています。なぜなら私は貧乏人のラップトップを持っているからです。私は、ええと、M two、あー、つまり少し古い、ええと、古い Apple ラップトップを使っていて、メモリは 16 ギガバイトしかありません。
だから小さいものが必要でした。これを可能な限り小さくする必要がありました。ええと、なので、そうですね、LAMA three に送ることができて、ええと、答えを得られます。ええと、彼らが言ったのは vault index cosign です。ええと、より大きな llama に送ることもできます。なぜなら、私がローカルで llama を使って実行したその llama はかなり小さかったからです。なので、ええと、ええと、そうですね、送ることもできます。あー、ここでは 8 billion モデルを使っているので、今度はより大きいです。ええと、any scale を使っています。any scale endpoints が良いと聞いたからです。
なので試してみました。わかります、ああそう、これは指摘するためです。このレイテンシも見てください。私の lama は 3 秒かかりました。ええと、そして、エンドポイントを使うこともできます。それだと少し短くなります。だから多くの人がエンドポイントを使うのです。たとえオープンソースモデルをローカルで使う方が時には安くても、時にはレイテンシの懸念があるのです。
ですから、rag パイプラインには考えるべきこうしたさまざまなトレードオフがあります。Okta ai でも試してみました。ええと、ただ、それが、ええと、どのように、何が違うのかを見るためです。ええと、実際にはそこには明確な答えは見えません。ここでは l chew という明確な答えが見えます。ええと、gr も試してみて、これは素晴らしいです。
0 3 7 秒です。ものすごく速いです。ええと、そこには明確な答えが見えます。あー、clawed も試しています。ここではそれをデモしません。なぜなら、それは、試すには非常に高価だったからです。ええと、mixture を試すこともできます。
ええと、再び、mixed roll を試すために、ええと、any scale endpoints を使ったと思います。ええと、そして私が試した mixed roll は eight seven B instruct でした。そして答えが L two であることが見え、レイテンシもそれほど悪くありません。それから、もちろん open AI を試しましょう。そして GPT-3 0。
5 turbo を使っています。超高機能なモデルは必要ないからです。あー、単純な質問のためだけなので。そして、ええと、そうですね、答えが 2 つ見えます。L chew と ip です。さて、これで評価の準備ができました。
なので、私は、あー、論文、コード、docs、ええと、ブログへのリンクを用意しています。そして、必要なのは PIP install Vegas だけです。そして彼らは裏側で hugging face data sets を使っています。あー、そのうちの一つ、あー、人々は私に「難しい部分は何ですか？」と聞きます。あー、彼らが data sets を使っていることだけは覚えておいてください。なので、ええと、私はこれを作成しました。ええと、あー、そしてまた、それらの 4 つのコンポーネントも必要です。
なので、ここに 4 つの質問があります。各質問に対する ground truth answer があり、それから、これらの異なる chunking methods のそれぞれで取得された context があります。それから、ええと、別の、ええと、embedding model を使って取得した context があります。そして、6 つの異なるモデルに対する答えの 6 つの異なる列があるはずです。これは評価に必要な種類のものです。
そして本番環境では、およそ 20 個の質問を用意するべきです。私はただ、手早くするために、ここでは 4 つの質問しかありません。なので、それらを CSV に入れただけです。ええと、それから、あー、それらを hugging face dataset に変換する必要があります。そのためのコードをここに用意してあり、それらを組み立てます。ええと、ground truth が何か、何が、あなたの contacts だったのか、あー、あなたの answers は何か、という観点でです。それから、あー、何を評価しているのかを知る必要があります。なぜなら、あなたがこの高レベルのチャートから思い出すように、異なる metrics があるからです。LLM の context を評価している内容に応じて、あー、異なる、つまり、こうしたさまざまな metrics が可能です。
そこで、これらすべての指標をインポートし、それから、コンテキストを評価するのか、回答を評価するのかに応じて、どの指標を使うかを定義する必要があります。そして、ここでもう一つ少し厄介な点があると思います。まあ、一度知ってしまえば厄介ではないのですが、ええと、link chain でサポートされているものはすべて ragus でもサポートされているということです。それで、ええと、コストを節約するために、これは高額になり得るので、デフォルトの OpenAI モデルをローカルの alama モデルに置き換えました。そして埋め込みモデルとしてオープンソースの BA AI を使っています。したがって、モデルを変更できるようにするには、それらのラッパーを設定する必要があります。
それで私が見つけたのは、ざっと見た限り、つまり少なくとも私の regpipeline からの初期の目視確認では、LAMA three を使うことに非常に満足しているということです。ローカル llama number one 上の超量子化版でさえもです。なぜなら、その分のコストをすべて節約できるからです。質問ごとに計算する指標が 6 種類あります。そして、ご覧のとおり、LLM が 6 つ、埋め込みモデルが 2 つ、チャンキング方法が 3 つありました。つまり、6 足す 3 で 9、つまり、12 通りの異なる組み合わせがあり、それぞれに 6 種類の指標があるので、LLM 呼び出しが 72 回になり、これはあっという間に高額になります。しかも私は 4 つの質問しか使っていません。
ですから、もし 20 問すべてを使っている場合を想像してみてください。なので、私の場合、この評価から出てきた結果を目視で見て、非常に満足しており、lama を使い続けると思います。というのも、私の評価では、リアルタイム性能についてはあまり心配していないからです。はい、それで、ええと、これは私が実行しているもので、ええと、まあ、すべての異なるチャンキング方法について計算していると思います。たとえば、ええと、私は最終的な指標を出力しています。私が選んだのは、コンテキストを測定するために 3 つの異なる指標を出力するのではなく、ここでコード内でそれらをまとめることです。precision と recall があるので、それらを従来の F1 スコアにまとめています。
これが私の F1 計算で、ええと、最終スコアとして平均 retrieval F1 を返しています。これは、コンテキストのスコアリング方法として報告するものです。ここで、異なるチャンキング方法に対する出力を見ることができます。ええと、読みやすくするために、ここでは少し読みやすい形式で出力しています。その一方で、ragus は、質問ごとに、あなたが持っていた異なるコンテキストタイプごとに、このすべての出力を提供してくれます。これは私の recursive context です。
各質問について、precision と私の計算した F1 と呼ぶ異なるスコアが得られます。そして HTML、parent context、big to small、semantic context についても同様です。さらに、その semantic context が非常に大きかったので要約することも試しました。ええ、こうしたさまざまな組み合わせをすべて試しました。そして最終的にご覧のとおり、最も精度が高かったのは parent context、つまり raw parent context で、その次が非常に単純な recursive context でした。そして、チャンキング戦略、埋め込みモデル、LLM にわたってこれを行ったところ、ここでの結論は、私の場合、チャンキング戦略を変更することで最も費用対効果が高かったということです。84 で、これは本当に大きな差です。
埋め込みモデルを変更することで 20% の改善があり、L lm を変更することで 6% の改善がありました。はい、これが結論のようなもので、saachi、あなたに戻します。はい、デモを共有してくださって本当にありがとうございます。Christie。チャットと Q&A に、共有いただいた内容についてかなり多くの質問が来ています。はい。
まず、rag モデルにとって OPT、最適なチャンキングとは何ですか？そうですね、私たちが見たのは、チャンキングについて、単純明快な答えはないだろうということだと思います。第一に、あなたのデータの形に依存します。つまり、私が持っていたようなテキストデータなのか、それとも、会話データや講義データのような他の種類のデータなのか、ということです。ええと、それぞれ異なる戦略になるでしょう。もし会話であればメモリを追加すること、それが最大の費用対効果になります。
ええと、私の場合は、ええ、見てわかるように、それはこの、ええと、sim それはこの、ええと、小さいものから大きいものへのチャンキング、または親チャンキングが私には一番うまく機能しました。でも、それは本当にあなたのデータ次第だと思います。ええと、だからこそ、この評価という難しいタスクが本当に重要なんです。なぜなら、さまざまな縮小戦略を評価できなければ、それはわからないからです。はい。ありがとうございます。
それから、彼らのフォローアップ質問は、RAGにおけるコストはどうなのか、というものでした。どこが、最適な領域なのでしょうか？これについてはある程度答えていたと思いますが、何か付け加えることはありますか？はい、コストですね。ですから、考える必要があります、ええと、どのようなモデルか、ええと、つまり、オープンソースモデルですね。私は、ええ、自分自身の、ええと、見てきたものからして、今のオープンソースモデルには非常に強気です。私は、批評役としてのMELA threeがとても気に入っています。ええと、ただ、どのモデルがより良く評価しているかを見るために、批評役としてさまざまなモデルを試す必要があります。
そして、ええと、あの、たとえばローカルモデルを提供する場合との間にはトレードオフがあります。ローカルモデルは、少し悪く、少し遅い、ええと、パフォーマンスになりがちです。それに対して、商用エンドポイントでは、提供しているものの背後に巨大なクラスターがあるような場合があります。でも、そのクラスターに対して、APIコールを通じて料金を払うことになります。なので、はい、ええと、もしこれをやるなら、ええと、ぜひサブスクライブしておくといいと思います。ええと、個人でデモのためにやるなら、私はサブスクライブします。ええと、月20ドルはすぐに、ええ、元が取れるでしょう。ええと、大企業なら、もちろんその月20ドルでは、ええ、いくつか、いくつかの上限に当たることになるでしょう。でも、少なくとも個人にとっては価値があると思います。
ええ、その商用エンドポイントが必要なら月20ドル、あるいは小規模ビジネスなら月20ドルですね。わかりました。わかりました。ありがとうございます。ええと、それから、Q&Aツールで誰かが、LLMが高い回答と低い回答を好むスコア分布チャートについて質問していました。
これは、LLMを分類器として使うのは理想的ではないという意味でしょうか？そして、LLMを使って応答を一貫して分類するためには、どのような方法があるでしょうか？これは、これは既知のことで、そして、ええと、これは研究論文から出てきたことです。ええ、たとえば、ええと、ええと、この論文で、かなり広く受け入れられている手法です。今では、このLLMはjudgeです。つまり、ええと、望ましいのですが、でも、ポイントは、もしあなたが、つまり、LLMをjudgeとして使うという概念には、手作業でキュレーションした何千もの回答に戻ることと比べて、非常に多くの利点があるということです。ええと、なので、その利点は本当に大きいと思います。ただ、人間の批評者の代わりにLLMをjudgeとして使う、またはLLMをcriticとして使うことには、既知の注意点があるということを覚えておく必要があります。
ええ、AIは人間が好む中間点よりも極端なものを好む傾向がある、という事実、その事実を覚えておいてください。だからRagusはそれを行っていて、そうした既知の落とし穴を避けるメトリクスとスコアリングシステムを作っています。でも、私は、風呂水と一緒に赤ちゃんを捨てるようなことはしないで、と言いたいです。つまり、Hey、私は手法としてLLMをjudgeとして使うのはやめて、手でラベル付けされたデータポイントに戻る、とは単純に言わないでください。ええ。
わかりました。ありがとうございます。それから、ええ、誰かがRagusはVIS製品なのかと質問していますが、ええ、違います。でもChristie、ええと、たとえばRagusにどうアクセスできるかについて、少し話してもらえますか。でも、もちろんです。はい。
SoPI、私のノートブックにリンクがあると思います。おっと。では、これが、その、彼らの、ええ、技術ドキュメントです。ええ、なので、私はこれを、たとえばimportして、取り込んで、ええ、公開ウェブページなので、ええと、あなたがRAGの質問をできる小さなチャットボット、RAGチャットボットを作ることもできます。私がMillの質問でやったように。ですが、ええ、コードはこちらにあります。Exploding Gradientsと呼ばれています。
Ragusです。なので、いいえ、VISではありません。同じものではありません。わかりました、共有ありがとうございます。ええと、それからリンクも、ええと、メールの中に入れます。ええと、また、彼女が共有したコードは実際には私たちのVIS bootcampにあります。
ええと、そのリンクはすぐに提供します。ええと、次の質問をしている間に、つまり、ragus は Python デプロイメント専用なのか、ということです。ええと、見てみましょう。実はその答えについてはよく分かりません。ええと、word patients を見て、自分で確認する必要があります。はい。そう言って始めましょう。ええと、Python のように見えます。
はい、今のところそれが私の答えです。ええと、詳しく調べる必要がありますが、ざっと見たところでは Python のようです。はい、素晴らしいです。明確にしてくれてありがとうございます。ええと、それから次の質問ですが、すべてのチャンク化を行うよりも、すべてのデータにラベル付けして前処理し、事前に適切なチャンクに入れておき、代わりにパイプラインの他の部分に注力するほうが、おそらく ROI が高いのでしょうか？私の受け止めとしては、そしてこれは他の人たち、ええと、他のエンジニアからも聞いたことですが、さらに AI Alliance の AI 企業のコンソーシアムが公開したホワイトペーパーもあったと思いますが、費用対効果が最も大きいのは検索ステップから得られる、という点で合意がありました。
つまり、6 つの異なる LLM を入れ替えても、回答は実際にはそれほど変わりませんでした。ええと、しかし、チャンク化や埋め込みモデルを変えると、より大きな、ええと、より大きな改善がありました。ですので、実際には生成ステップよりも検索ステップに注力するほうが費用対効果が高いです。さて、検索ステップの中で、ええと、私の特定のケースでは、ここで最後まで行くと、ええと、私は、ええと、見ました。これは典型的な、ええと、何というか、その範囲外ですが、はい、彼らは大量のデータに対して非常に多くの実験を行い、通常、ホワイトペーパーで見られたのは、チャンク化によって約 30% の改善があり、LLM からは本当に小さな改善しか得られない、ということでした。私の場合は、チャンク化を変更することで大きな改善が見られました。ですので、はい、間違いなく、検索ステップを見る価値はあると思います。
ええと、そして、それは、見ていただいたように、LLM を変更するだけなら非常に簡単です。通常は 1 行、ええと、モデル名を変えるだけで、異なるモデルを使って別のエンドポイントを呼び出せますし、しかし検索やチャンク化を変更するには、より多くの作業が必要です。はい、ありがとうございます。それから、埋め込みモデルを入れ替えられるとおっしゃっていましたね。うんうん。ええと、確認ですが、1 つの Milvus コレクションにつき使用できる埋め込みモデルは 1 つだけです。
例えば、1 つのコレクション内で埋め込みモデルを混在させることはできない、ということですよね。その点の確認です。はい、はい、それは、ええと、私としては、それはペインポイントだと感じています。ええと、そしてそれはベクトル検索の理論そのものの一部でもあります。つまり、ナレッジベースを作成し、そこに後から入ってくる未知の質問に基づいて、ベクトル空間内で非常に高速な最近傍計算をしたい場合、ええと、その距離指標が意味を持つためには、それらはすべて同じベクトル空間内にある必要があります。つまり、基本的には、ベクトル間でコサイン距離指標、あるいは L2、あるいは内積、または何らかの距離指標を計算しているわけです。ですので、それらはすべて同じベクトル空間内にある必要があります。したがって、それらはすべて同じ埋め込みモデルで作成されている必要があります。
了解です。これはそれに少し関連しているのですが、どうやってサイズの異なる埋め込みモデルを混在させることができるのでしょうか？そしてこれは、内部のニューラルネットワークがすべて同じように構築されているという意味なのでしょうか？彼らが行ったのは、MRL matrika representationlearning で、これは埋め込みモデル自体の学習時に行われる必要があり、彼らが MRL embeddings と呼ぶものを可能にします。そしてその名前は、ロシアのマトリョーシカ人形、つまり人形の中に人形があり、その中にさらに人形がある、というものに由来しているのだと思います。つまり考え方としては、ベクトル自体が大きなベクトルの中にサブベクトルを持ち、さらにその中にサブベクトルを持っているということです。そして、このように、学習時にそれらのレイヤーを意識することで、埋め込みモデルが異なるサイズのベクトル出力を選べるようになります。この場合、この特定のケースでは、2024年2月の OpenAI の発表にあった私の埋め込みモデルの名前を忘れてしまいましたが、可能な2つの次元は 1536 または 512 で、同じ精度でした。
なので、それはあなた次第です。つまり、もし、私の場合なら、同じ精度が得られるなら、単に容量を節約したいです。それは、その、よくわかりません。質問に答えられているといいのですが。はい、フォローアップがあればコメントで教えてください。
ええと、誰かが疑問に思っています。あなたは ragus の共同創業者の何人かに会ったことがあるので知っているかもしれませんが、ragus の中の、rag の後の as は何なのでしょうか？いい質問です。全くわかりません。私は、私は、rag は知っていますが、なぜ Ragus と呼ぶのかはわかりません。たぶん rags のようなものかもしれません。たぶん rags は、たぶん彼らは、その会社名 rags を取ろうとした、あるいは、そう、rags という名前にしようとしたのですが、それがあまりに一般的すぎたのかもしれません。
だから彼らはそのまま、わかりません。ただの推測ですが、もしかすると。はい、私もそう思います。ええと、ここで最後の質問です。Ragus はこれらのスコアをどのように計算しているのですか？たとえばコンテキスト関連性について、LLM が評価しているのでしょうか、それともベクトル検索で使われるコサイン類似度のようなものなのでしょうか？はい、それが1つの質問です。
ええと、それに自由に答えてください。その後でフォローアップを聞きます。わかりました。はい、もちろんです。つまり、彼らは、ええと、埋め込みモデルを使っていて、距離を計算していて、そして LLM を審査員として使っています。したがって、Ragus を使うときの2つの主要なコンポーネントは、埋め込みモデルの選択と critic model です。
なので、それらを選ぶ必要があります。ええと、そして、彼らが何をしているかについては、参照するとよいのは、論文があります。ええと、実際に私は自分のブログでそれを説明しようとしました。ええと、あと、このブログのパート1があります。ええと、そこに、はい、実際、両方のブログをフォローアップとして示すと思います、saachi、たぶんこれらを送ることができます。ええ、私の最初のブログは Ragus がどのように機能するかについてで、そして、ええと、彼らの主な概念のようなものは、誰かが強調していたと思いますが、ええと、事実に基づく回答を統計的にサンプリングすると、それらは幻覚された回答よりも互いにより類似しているはずだ、というものです。そしてこれは、彼らが基にしている考え方のようなものです。
そして彼らは、ここに見えるこれらのさまざまなメトリクスをすべて計算するために、LM を審査員として使っています。なので、ええ、質問のセグメントを取り、質問から小さなファクトイドを取り出し、それらがたとえばコンテキストのファクトイドの中でカバーされているかを見る、ということです。ええと、それを precision と呼び、そして違いがあります。precision はより coverage のようなもので、recall は、出てきたポイントのうちどれだけが、ええと、同様に言及されていたか、というようなものです。ええと、だから通常、統計家は precision と recall から F1 score を計算するのです。ええ、そして recall には ground truth answer も必要です。ええと、precision と比べて、です。
すみません、たぶんかなり逆の言い方をしてしまいました。はい、まあ、彼らの次の質問は、ground truth が指定されていなくても、これらのスコアのいずれかを生成することは可能ですか、というものでした。なので、ええと、そうですね、つまり、そうです。はい。それは可能です。ground truth なしで ragus を使っている人を何人か見たことがあります。
ええと、それはつまり、例えば、これら3つの指標が欠けることになる、というだけです。リコールを取得することはできませんし、回答が正しかったかどうか、あるいはスタイルが似ているかどうかも取得できません。はい。はい。素晴らしいです。
では、残り1分なので、どなたか最後の質問があれば。ええと、ここに1つ見えていると思います。これは本番前評価ですか、それとも本番評価／モニタリングですか？はい、私なら、アプリをデプロイする前の開発サイクルの一部として、本番前にこれを行います。なぜなら、おそらく反復して、自社のデータに対して、何が、ええと、自社にとって最適なレバーなのか、どのレバーを使いたいのかを見極めたいはずだからです。そしてもう1つ、これらすべての上にさらに新しいレイヤー、もう1つのレイヤーがあります。それが、ええと、agentic rag で、LLM評価に加えて、今度は、例えば、agent rag がどのチャンキング戦略、どの埋め込みモデル、どのLLMを使うかを決定できるLLMを追加する、というものです。ですので、ええと、agent rag はまだ初期段階、まだ初期段階だと思いますが、そうですね、将来的にはLLMにさらに多くの意思決定をさせるということで、かなり話題になっています。
ええと、はい。わかりました。Christie、本当にありがとうございました。ええと、最後に、Ragus が何を意味するのかについていくつか推測が見えています。はい。
1つは assessment で、もう1つは、ええと、RAG、または Ragga は、あるいは Ragga はインドの音楽の旋律様式だと言っていました。なので、そこから、ええと、アイデアを得て、RAG がその一部だと見たのかもしれません。はい。ええと、名前の一部ということですね。ええと、でも、本当にありがとうございました。
ええと、ウェビナー終了後に、録画、スライド、そしてこのトピックについてさらに説明しているChristieのブログをいくつかお送りします。ええと、本日はご参加いただきありがとうございました。また次回お会いしましょう。それでは。ありがとうございました。さようなら。
さようなら。
Meet the Speaker
Join the session for live Q&A with the speaker
Christy Bergman
Developer Advocate
Christy Bergman is a passionate Developer Advocate at Zilliz. She previously worked in distributed computing at Anyscale and as a Specialist AI/ML Solutions Architect at AWS. Christy studied applied math, is a self-taught coder, and has published papers, including one with ACM Recsys. She enjoys hiking and bird watching.