前の記事で述べたように、ファブリスAIの開発は予想以上に複雑で、さまざまなアプローチを模索せざるを得なかった。
最初のアプローチラマ・インデックス – ベクトル検索
Fabrice AIの検索能力を向上させるために私が最初に取り組んだのは、Llama Indexを使ったベクトル検索でした。
コンセプトは単純で、私のブログのコンテンツをLangchainドキュメントに変換し、それをLlamaドキュメントに変換する。
これらのラマ・ドキュメントはベクトル・インデックスに保存され、関連情報をこのインデックスに問い合わせることができる。
しかし、システムをテストし始めると、このアプローチでは期待した結果が得られないことが明らかになった。
具体的には、”マーケットプレイスの創業者が犯す最大のミスは何か？”のような文脈に重きを置いた質問をシステムに問い合わせたところ、AIは意味のある答えを返すことができなかった。
私がデータに埋め込まれていると知っていたニュアンス豊かな内容を取得する代わりに、無関係な、あるいは不完全な回答を返してきたのだ。
この最初の失敗が、私のアプローチを再考するきっかけとなった。
単にベクトル・インデックスにコンテンツを格納するだけでは不十分で、検索メカニズムが質問の文脈やニュアンスを理解する必要があることに気づいたのだ。
この気づきは、Fabrice AIの進化を形作ることになる多くの教訓の最初のものだった。
知識を保存するMongoDBドキュメントストレージと検索
Llama Indexアプローチの限界を念頭に置いて、私は次にLlamaドキュメントをMongoDBに保存することを検討した。
MongoDBの柔軟なスキーマとドキュメント指向の構造は、私が長年にわたって蓄積してきた多様なタイプのコンテンツを管理するための有望なソリューションに思えた。
計画では、よりダイナミックでレスポンシブな検索体験を実現することだった。
しかし、このアプローチはすぐに問題にぶつかった。
より堅牢になると予想していた検索機能が、期待通りに機能しなかったのだ。
関連ドキュメントを返すはずのクエリが、結果を返さなかったり、無関係なコンテンツを返したりしたのだ。
この挫折は苛立たしいものだったが、同時に重要な教訓を浮き彫りにした。それは、検索戦略と同様に、ストレージ方法も重要だということだ。
例えば、MongoDBアトラスをベクトル検索に利用することで、必要な精度とスケーラビリティを実現できる可能性がある。
しかし、この選択肢にコミットする前に、もっと効果的なソリューションがないか、他のアプローチも試してみたかった。
メタデータレトリバーとベクターストア：特異性を求めて
私が探求した次の手段のひとつは、メタデータ・リトリーバーとベクトル・ストアを組み合わせることだった。
このアプローチの背後にあるアイデアは、Fabrice AI内の膨大な情報を分類し、その分類に基づいて答えを取り出すことだった。
メタデータでデータを構造化することで、具体的で的を絞った回答を提供するAIの能力を向上させることを期待した。
しかし、この方法にも限界があった。
表面的には有望に見えたが、AIはあらゆる種類のクエリに対して正確な回答を出すのに苦労した。
例えば、”著者は楽観的ですか？”と質問したとき。
システムは、関連するコンテンツの文脈で質問を解釈することができなかった。
メタデータに基づいた洞察に満ちた分析を提供する代わりに、曖昧な答えを返すか、何も返さないかのどちらかだった。
このアプローチは、AIにおけるコンテキストの重要性について、私に貴重な教訓を与えてくれた。
単に情報を分類するだけでは不十分で、AIはこれらのカテゴリーがどのように相互作用し、重なり合ってコンテンツのまとまった理解を形成しているのかも理解しなければならない。
この理解の深さがなければ、どんなに洗練された検索手法であっても不十分なものになりかねない。
知識の構造化SummaryTreeIndex
Fabrice AIを改良し続ける中で、私はSummaryTreeIndexを作成する実験を行った。
このアプローチは、すべての文書をツリー形式に要約し、AIがこれらの要約をナビゲートし、コンテンツの構造に基づいて関連情報を取得できるようにすることを目的としている。
文書を要約することで、AIは重要なポイントを素早く特定し、簡潔で正確な情報で問い合わせに対応できるというものだった。
しかし、この方法にも大きな課題があった。
AIは、”人生において重要な決断を下すには？”といった複雑なクエリに対して意味のある回答を提供するのに苦労した。
要約の中に保存されている豊かでニュアンスのあるコンテンツを引き出す代わりに、AIの回答は浅かったり不完全だったりすることが多かった。
この経験は、AIにおける広さと深さのバランスの難しさを浮き彫りにした。
要約はハイレベルな概要を提供することができるが、より複雑な質問に答えるために必要な詳細な文脈を欠いていることが多い。
私は、効果的なソリューションには、詳細なコンテンツとハイレベルな要約の両方を統合し、AIが必要に応じてその両方を利用できるようにする必要があると考えました。
そのため、現在稼働しているファブリーズAIのバージョンでは、より詳細に入る前に、まずAIに答えの要約を言わせるようにしている。
視野を広げるナレッジグラフ・インデックス
これまでの手法の限界を認識した私は、より洗練されたアプローチであるナレッジグラフ・インデックスに目を向けた。
このアプローチでは、構造化されていないテキストからナレッジグラフを構築し、AIがエンティティベースのクエリーを行えるようにする。
その目的は、コンテンツのよりダイナミックで相互接続された理解を生み出し、Fabrice AIが複雑で文脈の重い質問に、より効果的に答えられるようにすることだった。
ナレッジグラフ・インデックスは、その将来性にもかかわらず、大きなハードルにも直面していた。
AIは、特に文脈を深く理解する必要があるクエリに対して、正確な結果を出すのに苦労した。
例えば、”Seed & Series Aの公正な評価額は？”という質問に対して、AIはまたしても適切な回答を提供できず、非構造化テキストを首尾一貫したナレッジグラフに統合することの難しさを浮き彫りにした。
このアプローチは最終的には失敗に終わったが、AIで知識グラフを使用する際の課題について重要な洞察を与えてくれた。
データの複雑さと正確なコンテキストの必要性から、うまく構築されたナレッジグラフであっても、望ましい結果を出すのに苦労する可能性があった。
ナレッジグラフ・インデックスのもう一つの欠点は、そのスピードの遅さだった。
ベクトルストア・インデックスに比べて、関連文書を取得するためのレスポンス・タイムが非常に長かった。
データの再評価ジェミニ
何度か挫折を味わった後、グーグルのAI、ジェミニを活用して別のアプローチを取ることにした。
それは、JSON-CSVファイルからデータセットを作成し、このデータを使ってカスタムモデルのLLMを訓練するというものだった。
構造化されたデータとロバストなトレーニングモデルを使うことで、以前の試みを悩ませていた課題を克服できると期待した。
しかし、このアプローチにも困難があった。
データのフォーマットが正しくなかったため、モデルを効果的に学習させることができず、学習プロセスが中断してしまったのだ。
この挫折は、AIのトレーニングにおけるデータの完全性の重要性を浮き彫りにした。
適切にフォーマットされ、構造化されたデータがなければ、最も高度なモデルでさえ期待通りの性能を発揮できない可能性がある。
この経験から、私はJSONデータの保存にBigQueryを使用する可能性を考えるようになり、Fabrice AIを効果的に訓練するために必要な大規模データセットを管理するための、よりスケーラブルで信頼性の高いプラットフォームを提供できるようになりました。
強みを組み合わせる：松ぼっくりでラングチェーン文書
これまでに直面した困難にもかかわらず、私はFabrice AIが知識を効果的に保存し、検索できるソリューションを見つけようと決意した。
この決意が、LangchainドキュメントとPineconeの実験につながった。
このアプローチでは、LangchainドキュメントとOpenAIエンベッディングを使ってPineconeベクトルストアを作成し、クエリに基づいて上位の類似ドキュメントを検索しました。
この方法は、特にクエリに文書のタイトルが含まれている場合に有望であった。
例えば、”幸せの鍵は何か？”という質問に対して、AIは関連する内容を正確に検索し、要約することができた。
しかし、特にクエリに特定のキーワードやタイトルがない場合には、まだ限界があった。
このアプローチは、AIのパフォーマンスを向上させるために異なるテクノロジーを組み合わせることの可能性を示した。
LangchainドキュメントとPineconeのベクトルストアを統合することで、いくつかの制限はあるものの、AIの回答の関連性と精度を向上させることができた。
一貫性を実現する：GPTビルダー OpenAI
様々な手法や技術を検討した結果、私はFabrice AIに保存されている知識を統合し、改良するためにOpen AIのGPT Builderを利用しました。
すべてのコンテンツをGPTナレッジベースにアップロードすることで、ナレッジを検索し対話するための、より一貫性のある信頼性の高いプラットフォームを作ることを目指した。
このアプローチは、AIが様々なクエリに対してより良い結果を提供することができ、最も成功したアプローチの1つであることが証明された。
この成功の鍵は、すべての知識を1つのまとまったシステムに統合したことで、AIが質問に答える際に幅広いコンテンツを活用できるようになった。
前の投稿で述べたように、私のウェブサイト上で動作させることができず、Chat GPTの有料購読者のみが利用可能でした。
また、改善されたとはいえ、私はまだ回答の質を気に入っておらず、一般に公開することに抵抗がありました。
最終リファインメントモデル4oを使ったGPTアシスタント
ファブリーズAIの開発におけるパズルの最後のピースは、モデル4oを使ったGPTアシスタントの導入だった。
このアプローチは、プロジェクトを通して学んだことの集大成でした。
ベクター・データベースを活用し、プロンプトを洗練させることで、AIの応答において最高レベルの精度と文脈理解を達成することを目指した。
この方法では、私が蓄積してきた知識をすべてベクトル・データベースにアップロードし、それをAIのインタラクションの基盤として使用した。
ベクトル・データベースによって、AIはより高度な検索を行うことができるようになり、キーワードのマッチングだけに頼るのではなく、クエリの意味に基づいて情報を検索することができるようになった。
これにより、AIは複雑でニュアンスの異なる質問をよりよく理解し、対応できるようになった。
このアプローチの重要な革新のひとつは、プロンプトを注意深く改良することだった。
さまざまなプロンプトを入念に作成しテストすることで、AIをより正確で適切な回答を提供するように導くことができた。
これには、プロンプトの文言を微調整するだけでなく、可能な限り最良の回答を引き出すために、クエリを構造化するさまざまな方法を試すことも含まれる。
結果は素晴らしいものだった。
AIは、質問が自由形式であったり、文脈を深く理解する必要がある場合でも、幅広いクエリを高い精度で処理できるようになった。
例えば、”人生で最も重要な決断を下すには？”という質問に対して、AIは包括的で洞察に満ちた回答を提供した。
AIは包括的で洞察に満ちた回答を提供し、さまざまな情報源や視点を活用して総合的な回答を提供した。
この成功は、何百時間もの作業と数え切れないほどの実験の集大成だった。
テクノロジーと改良の適切な組み合わせによって、情報を効果的に保存・検索できるだけでなく、有意義な方法で情報を扱うことができるAIを作ることが可能であることを実証したのだ。
モデル4oを使用したGPTアシスタントの開発は、ファブリスAIが真に本領を発揮し、当初から思い描いていた洗練された精度のレベルを達成した時点となりました。
GPTアシスタントのAPIは私のブログに統合され、エンドユーザーがFabrice AIと対話できるようになりました。
旅を振り返る
ファブリスAIの開発プロセスは、AIを扱うことの複雑さ、特に情報を理解し文脈化することの難しさを浮き彫りにした。
AI開発には近道がないこと、すべてのステップ、すべての反復、すべての実験が、真に効果的なものを生み出すために必要な旅の一部であることを教えてくれました。
この先、ファブリーズAIの改良と拡張を続けていくことに興奮している。
前回の記事で述べたように、私は質問された内容を見直して、ギャップがある部分の知識ベースを完成させるつもりだ。
また、ゆくゆくは私のような見た目で会話もできるインタラクティブなバージョンをリリースしたいと思っています。
