ベンチマークを参照してください
使い方
- 適切なパッケージがインストールされていることを確認してください。以下がインストールされていることを確認してください：dente_transformers tqdm pandas pypdf2 Torch asyncio concurrent re qdrant_client pinecone pymilvus dotenv
- すべてのPDFを /data /、または指定されている場合は他のディレクトリをアップロードします。
- PDFファイルに関する詳細については、メタデータファイルがある場合は、Home Directoryにアップロードして、メタデータを名前を付けるか、名前を変更します。特定のメタデータファイルに対応するために、MacLoaderのget_metadata（）でコードを変更する必要がある可能性があります。
- .ENVで接続の詳細を入力します。 .envがどのように見えるかについては.env-exampleを参照してください。
- 代わりに、コードのDB初期化の一部として詳細を入力するだけで、これは回避できます。
- インデックスPythonファイルを作成します。ここから適切なロギングを定義します。すべてのデータを使用すると、問題に注意することが重要です。すべてのロギングは、情報、警告、エラー、およびクリティカルを使用して適切に命名されています。
- delete.txtを作成し、何も入れないでください。
- プロジェクトから適切なファイルをインポートし、適切な詳細でそれらを初期化します。利用可能なすべてのパラメーションは十分に文書化されており、ホバリングまたはクリックを介してIDEによって表示される必要があります。
- 例：
from Loader import MacLoaderおよびfrom databases.PineconeDB import PineconeDB
- ファイルの実行を行った後、delete.txtをチェックして、PYPDF2リーダーに問題が発生しているファイルを確認してください。これらのファイルを削除する場合は、utility.delete_bad_pdfs（）を使用します
- お楽しみください、このプロセスを改善する方法を教えてください！
キーテイクアウト
前処理
llama_indexは素晴らしいですが、ノードの信頼性は本当に障害です。 TextNodesは非常に便利に思えますが、ストレージとパフォーマンスを取り上げるだけのベクトルでアップロードする不要なデータがたくさんあります。この理由だけで、llama_indexは、ベクトルアップロードプロセスを複雑にするために使用されるべきではありません。生産規模のデータセットにある場合、追加のデータは多すぎます。また、コードを時々書くのがどれほど迷惑であるかを嫌います。非常に多くの奇妙なルールと不必要な手順です。すべてが適切に管理されている場合、テキストノードは貴重な強力な資産になり、すべての追加データがローカルに保存され、検索速度やメモリを妨げないようにします。
Langchainは、より少ないルールでデータをインターフェースする簡単な方法を作成します（ただし、コンテキストに依存します）。私は間違いなく、Langchainが生産の準備ができているとは思いません。代わりにグリップテープを使用する必要があります。生産環境でも、プロセス全体を完全に制御することが好ましい場合があります。
全体として、私はそれが望むように簡単にフィットするものを見つけることができません。これが、このプロセスがどのように進むべきかについての私の理解です。
このプログラムを終了している間、私はそれが上記の2つのツールの単なる代替品であることに気付きました。上記の2つのツールは、すべてのユースケースに適用することを目的としています。私は私に固有の1つをコード化しました。
埋め込み /変圧器
文の変圧器を選ぶことはそれほど難しくありませんでした。
All-Minilm-V2は良好で高速でしたが、膨大な量のデータを使用したスケーラビリティが心配でした。最も正確ではありませんが、それでも良いことであり、生産のためではありません。
E5-Large-V2は、私のテストで小規模で基本的なデータ検索に失敗しました。このため、私はそれを大規模でも考慮しません。
インストラクターの埋め込みではすべてが時間がかかりますが、おそらくより良いデータ精度を提供するでしょう。私はこれらをまだ適切にテストしていません。
All-MPNET-V2は、スピードとパフォーマンスの点で最高のものであり、インストラクターの埋め込みほど正確ではないかもしれませんが、生産環境ではスピードとパフォーマンスが好まれる場合があります。
ADA（OpenAI）埋め込みは、典型的なローカル文の変圧器よりもはるかに高価になるでしょう。過去には、レートの制限やそのモデルによって課されたその他の制限により、大規模なデータセットの処理に問題がありました。チャンクでデータを送信すると、この問題が解決します。
- ADAが1536の寸法にも埋め込まれていることを考慮することが重要です。これにより、より多くの次元に必要な追加の数学が原因で、セマンティック検索時間が高くなります。繰り返しになりますが、これもより高い精度につながりますが、他のモデルは高価な外部APIを使用せずに高次元の埋め込みを行うこともできます。
- ローカル文の変圧器の使用が制限または不便である場合、これは大きな代替品です。
最終的な選択：未定。指示またはMPNETのいずれかを選択する前に、最初に前処理を終了する必要があります
ベクトルデータベース
拒否されたデータベース
- 彩度
- サーバーの展開オプションがありません。小規模なプロジェクトでは、これは常に最良の選択ですが、私は思いますが。
- pgvector
- 何らかの理由でベンチマークで非常に貧弱に機能します。しかし、現実世界のパフォーマンスを代表するものではないかもしれません。こちらをご覧ください
- PostresQLデータベースがすでに使用されていることを計画している場合、または特定のデータにとって実用的である場合、PGVectorが最良の選択肢になることは間違いありません。ただし、PGVectorライブラリを単独で使用するか、PostresQLに切り替えません。
- 弾性
- 織ります
- 私は以前にこれを評価することを計画していましたが、このプログラムでこれを実装しようとしている間、私は他のすべてに比べてはるかに困難でした。
- Pythonクライアントのドキュメントはまったく大きくありません。それは難しくありませんでしたが、ドキュメントの欠如は心配しています。
- 私のユースケースは、マネージドクラウドを使用することを計画しており、WCSは私を本当に心配させました。セキュリティはあまりないようです。2FAさえありません。私はWCSを個人的に信用しておらず、他のデータベースのいずれかと比較して最悪のUIがありました。
- Dockerコンテナで使用する予定がある場合、Weaviateは再考され、公正なショットを与えられる必要がありますが、今のところ私はそれを評価し続けていません。
現在調査中です
プロセス全体からの考慮事項
- PDFには非常に多くのジャンクがあり、ほとんどのローダーはそれを食べます。 PDFからテキストを剥奪するには、特にLangchainまたはLlama_indexの読み取りソリューションを使用する場合、多くのゴミがあります。そのプロセスを制御しないと、カスタムディレクトリPDFローダーを作成するよりも難しくなりました。
- 他のほとんどの形式は、大量のデータから読むためにPDFよりも優れていると思います。エンコード、ジャンクキャラクター、読みにくいPDFの台無しになったテキストとパイプラインのジャミングに関する非常に多くの問題。
- テキストデータは、必要に応じてすべてのベクトルデータベースに保存できます。これにより、ストレージプロセスが大幅に簡素化されます。多くのベクトルデータベースは、これをメタデータの形で許可しますが、問題になる可能性のあるテキストの個別の保存を許可しません。テキストは大きすぎてメモリが集中してメモリに保存され、メタデータはディスクに保存できますが、メタデータフィルタリングは使用できません。
- ベクトルデータベースがこれを適切に処理しない場合、ベクトルとIDをアップロードするだけでベクトルアップロードプロセスが簡素化される場合があります。セマンティック検索が実行されたら、関連するIDからローカルまたはNOSQLデータベースを検索します。
