正如我在 上一篇文章中提到的，開發 Fabrice AI 比預期的要複雜得多，這迫使我探索許多不同的方法。

最初的方法：Llama Index – 向量搜索

我第一次嘗試增強 Fabrice AI 的檢索能力涉及使用 Llama Index 進行向量搜索。 概念很簡單：從我的博客中獲取內容，將其轉換為 Langchain 文件，然後將這些文檔轉換為 Llama 文件。 然後，這些 Llama 文件將儲存在向量索引中，使我能夠查詢此索引以獲取相關信息。

然而，當我開始測試系統時，很明顯這種方法並沒有產生我所希望的結果。 具體來說，當我用「市場創始人犯的最大錯誤是什麼」等上下文密集型問題查詢系統時，AI 未能提供有意義的答案。 它沒有檢索我知道嵌入在數據中的細微內容，而是返回了不相關或不完整的回應。

最初的失敗使我重新考慮了我的方法。 我意識到，僅僅將內容存儲在向量索引中是不夠的;檢索機制需要理解所提問題的上下文和細微差別。 這一認識是塑造 Fabrice AI 發展的眾多經驗教訓中的第一個。

存儲知識：MongoDB 文件存儲和檢索

考慮到 Llama Index 方法的局限性，我接下來探索了在 MongoDB 中存儲 Llama 文件。 MongoDB 靈活的架構和面向文檔的結構似乎是一個很有前途的解決方案，可以管理我多年來積累的各種類型的內容。

該計劃旨在打造更具活力和回應速度的搜索體驗。 但是，這種方法很快就遇到了問題。 我曾預計搜索功能會更健壯，但未能按預期執行。 本應返回相關文件的查詢卻沒有結果或不相關內容。

這一挫折令人沮喪，但也凸顯了一個關鍵的教訓：存儲方法與檢索策略同樣重要。 我開始考慮其他選項，例如利用 MongoDB Atlas 進行向量搜索，這可能會提供我所需的精度和可擴充性。 但是，在決定採用這種替代方案之前，我想探索其他方法，以確定是否有更有效的解決方案。

元數據檢索器和向量存儲：尋求特異性

我探索的下一個途徑之一是將元數據檢索器與向量存儲結合使用。 這種方法背後的想法是對 Fabrice AI 中的大量資訊進行分類，然後根據這些類別檢索答案。 通過使用元數據構建數據，我希望提高 AI 提供具體、有針對性的答案的能力。

然而，這種方法也有其局限性。 雖然表面上看起來很有希望，但 AI 難以對所有類型的查詢提供準確的回應。 例如，當我問道：「作者樂觀嗎？ 系統未能在相關內容的上下文中解釋問題。 它沒有根據元數據提供有洞察力的分析，而是返回模糊的答案或沒有答案。

這種方法教會了我寶貴的一課，讓我明白了上下文在 AI 中的重要性。 簡單地對資訊進行分類是不夠的;AI 還必須瞭解這些類別如何相互作用和重疊，以形成對內容的連貫理解。 如果沒有這種深入的理解，即使是最複雜的檢索方法也可能達不到要求。

構建知識：SummaryTreeIndex

在我繼續優化 Fabrice AI 的過程中，我嘗試了創建 SummaryTreeIndex。 這種方法旨在將所有文檔匯總為樹格式，允許 AI 流覽這些摘要並根據內容的結構檢索相關信息。

這個想法是，通過總結文檔，AI 可以快速識別關鍵點，並使用簡潔、準確的信息回應查詢。 然而，這種方法也面臨著重大挑戰。 AI 努力為複雜的問題提供有意義的答案，例如「如何在生活中做出重要決定？ AI 的回答往往是膚淺或不完整的，而不是從摘要中存儲的豐富、細微的內容中提取。

這一經歷凸顯了在 AI 中平衡廣度和深度的難度。 雖然摘要可以提供高級概述，但它們通常缺乏回答更複雜問題所需的詳細上下文。 我意識到，任何有效的解決方案都需要集成詳細的內容和高級摘要，讓 AI 能夠根據需要利用兩者。

這就是為什麼在當前上線的 Fabrice AI 版本中，我讓 AI 先給出答案的摘要，然後再介紹更多細節。

擴展視野：知識圖譜索引

認識到以前方法的局限性后，我轉向了一種更複雜的方法：知識圖譜索引。 這種方法涉及從非結構化文本構建知識圖譜，使 AI 能夠進行基於實體的查詢。 目標是創建對內容的更動態和相互關聯的理解，使 Fabrice AI 能夠更有效地回答複雜、上下文繁重的問題。

儘管前景廣闊，但知識圖譜指數也面臨著重大障礙。 AI 難以產生準確的結果，尤其是對於需要深入瞭解上下文的查詢。 例如，當被問到「什麼是公平的種子和A輪估值？？時，AI再次未能提供相關的答案，突顯了將非結構化文本整合到連貫知識圖譜中的困難。

這種方法雖然最終沒有成功，但為在 AI 中使用知識圖譜的挑戰提供了重要的見解。 數據的複雜性和對精確上下文的需求意味著，即使是構建良好的知識圖譜也可能難以提供所需的結果。 知識圖譜索引的另一個缺點是速度慢。 相對於 vector store 索引，獲取相關文檔的回應時間非常長。

重新評估數據：雙子座

在經歷了幾次挫折之後，我決定採取不同的方法，利用Google的AI Gemini。 這個想法是從 JSON-CSV 檔案創建數據集，然後使用這些數據訓練自定義模型 LLM。 我希望通過使用結構化數據和強大的訓練模型，我能夠克服以前嘗試中困擾的一些挑戰。

然而，這種方法也遇到了困難。 由於數據格式不正確，訓練過程已停止，這導致模型無法得到有效訓練。 這一挫折凸顯了 AI 訓練中數據完整性的重要性。 如果沒有正確格式化和結構化的數據，即使是最先進的模型也可能無法按預期執行。

這段經歷讓我考慮了使用 BigQuery 存儲 JSON 數據的潛力，從而提供了一個更具可擴展性和可靠的平臺來管理有效訓練 Fabrice AI 所需的大型數據集。

結合優勢：Langchain 文件與 Pinecone

儘管到目前為止面臨挑戰，但我決心找到一種解決方案，讓 Fabrice AI 能夠有效地存儲和檢索知識。 這個決心促使我嘗試了 Langchain 文件和 Pinecone。 該方法涉及使用 Langchain 文件和 OpenAI 嵌入創建 Pinecone 向量存儲，然後根據查詢檢索排名靠前的相似文檔。

此方法顯示出希望，尤其是當查詢包含文檔的標題時。 例如，當被問到 「幸福的關鍵是什麼 」時，AI 能夠準確地檢索和總結相關內容。 但是，仍然存在限制，尤其是當查詢缺少特定的關鍵字或標題時。

這種方法展示了結合不同技術來提高 AI 性能的潛力。 通過將 Langchain 文件與 Pinecone 的向量存儲集成，我能夠提高 AI 回應的相關性和準確性，儘管存在一些限制。

實現一致性：GPT Builder OpenAI

在探索了各種方法和技術之後，我轉向 Open AI 的 GPT Builder 來整合和完善存儲在 Fabrice AI 中的知識。 通過將所有內容上傳到 GPT 知識庫中，我旨在創建一個更加一致和可靠的平臺來檢索我的知識並與之交互。

事實證明，這種方法是最成功的方法之一，AI 能夠在一系列查詢中提供更好的結果。 這一成功的關鍵是將所有知識集成到一個單一的、有凝聚力的系統中，使 AI 在回答問題時能夠利用全部內容。

正如我在上一篇文章中提到的，我無法讓它在我的網站上運行，而且它僅適用於Chat GPT的付費訂閱者，我覺得這太有限了。 此外，雖然它更好，但我仍然不喜歡答案的品質，也不願意將其發佈給公眾。

最終改進：使用 Model 4o 的 GPT 助手

開發 Fabrice AI 的最後一塊拼圖來自使用 Model 4o 的 GPT 助手 的引入。 這種方法代表了我在整個專案中學到的一切的巔峰之作。 通過利用向量資料庫並改進提示，我的目標是在 AI 的響應中實現盡可能高的準確性和上下文理解。

這種方法涉及將我積累的所有知識上傳到向量資料庫中，然後將其用作 AI 交互的基礎。 向量資料庫允許 AI 執行更複雜的搜索，根據查詢的語義含義檢索資訊，而不是僅僅依賴關鍵字匹配。 這標誌著與以前方法相比的重大進步，使 AI 能夠更好地理解和回答複雜、細微的問題。

這種方法的關鍵創新之一是對提示的仔細優化。 通過精心製作和測試不同的提示，我能夠指導 AI 提供更準確和相關的答案。 這不僅涉及調整提示的措辭，還涉及嘗試不同的查詢構建方式以獲得最佳回應。

結果令人印象深刻。 AI 現在能夠高精度地處理各種查詢，即使問題是開放式的或需要對上下文有深入的理解。 例如，當被問到「如何做出你生命中最重要的決定？ AI 提供了全面而有洞察力的答案，利用各種來源和觀點來提供全面的回應。

這一成功是數百小時工作和無數實驗的結晶。 它表明，通過將技術與改進正確結合，可以創建一個 AI，它不僅可以有效地存儲和檢索資訊，還可以以有意義的方式與信息互動。 使用 Model 4o 的 GPT 助手的開發標誌著 Fabrice AI 真正發揮作用，達到了我從一開始就設想的複雜程度和準確性。 然後，GPT Assistants API 被整合到我的博客中，以允許最終使用者以您現在在博客上看到的方式與 Fabrice AI 進行交互。

反思旅程

開發 Fabrice AI 的過程凸顯了使用 AI 的複雜性，尤其是在理解和情境化資訊方面。 它教會了我，AI 開發沒有捷徑可走——每一步、每一次反覆運算和每一次實驗都是創造真正有效的東西的必要部分。

展望未來，我很高興能繼續完善和擴展 Fabrice AI。 如上一篇文章所述，我將回顧在存在差距的情況下完成知識庫時提出的問題。 我還希望最終發佈一個互動版本，它的外觀和聲音都像我，你可以與之交談。