請參閱基準
如何使用
- 確保安裝適當的軟件包。確保已安裝以下內容：ston_transformers tqdm pandas pypdf2 torch asyncio並發re qdrant_client pinecone pycone pymilvus dotenv
- 如果指定，將所有PDF的所有PDF上傳到 /數據 /或其他目錄。
- 如果您有一個元數據文件以獲取有關PDF文件的更多信息，請將其上傳到主目錄並將其命名為metadata.csv或更改名稱。可能需要在Macloader中的get_metadata（）中更改代碼，以適應您的特定元數據文件。
- .env中的輸入連接詳細信息。請參閱.env-示例您的.ENV外觀。
- 如果您只想將詳細信息作為代碼中的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已經準備好生產，並且應該使用抓地帶。在生產環境中，可以完全控制整個過程。
總的來說，我找不到很容易按照我想要的東西。這是我對我認為這個過程應該如何發展的理解：
在完成此程序時，我意識到這只是上述兩個工具的替代品。以上兩個工具旨在適用於所有用例，我只是對我的一個特定的編碼。
嵌入 /變壓器
挑選句子變形金剛並不難。
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容器中使用，則應重新考慮編織並進行公平射擊，但目前我尚未繼續對其進行評估。
目前正在調查
整個過程的考慮
- PDF的垃圾很大，大多數裝載機都會吃掉。對於從PDF的剝離文本，有很多垃圾，尤其是在使用Langchain或Llama_index的閱讀解決方案時。沒有控制該過程的控制，這比製作自定義Directory PDF加載程序要困難。
- 我認為幾乎任何其他格式都優於PDF，用於從大量數據中讀取。編碼，垃圾字符和不可讀的PDF的毀滅文本和堵塞管道的許多問題。
- 如果需要，可以將文本數據存儲在所有矢量數據庫中。這將大大簡化存儲過程。許多矢量數據庫都將以元數據的形式允許這一點，但不允許單獨存儲文本，這可能是一個問題。文本太大，內存密集型也無法存儲在內存中，並且可以將元數據存儲在磁盤上，但是元數據過濾無法使用。
- 如果矢量數據庫無法正確處理此信息，則僅通過上傳的向量和ID來簡化矢量上傳過程。執行語義搜索時，請從關聯的ID中搜索本地或NOSQL數據庫。
