文章很長，且持續更新，建議收藏起來，慢慢讀！瘋狂創客圈總目錄博客園版 爲您奉上珍貴的學習資源：

免費贈送 :《尼恩Java面試寶典》 持續更新+ 史上最全 + 面試必備 2000頁+ 面試必備 + 大廠必備 +漲薪必備
免費贈送 :《尼恩技術聖經+高併發系列PDF》 ，幫你實現技術自由，完成職業升級，薪酬猛漲！加尼恩免費領
免費贈送經典圖書:《Java高併發核心編程（卷1）加強版》 面試必備 + 大廠必備 +漲薪必備加尼恩免費領
免費贈送經典圖書:《Java高併發核心編程（卷2）加強版》 面試必備 + 大廠必備 +漲薪必備加尼恩免費領
免費贈送經典圖書:《Java高併發核心編程（卷3）加強版》 面試必備 + 大廠必備 +漲薪必備加尼恩免費領

免費贈送資源寶庫： Java 必備百度網盤資源大合集價值>10000元加尼恩領取

精通RAG架構：從0到1，基於LLM+RAG構建生產級企業知識庫

尼恩特別說明：尼恩的文章，都會在《技術自由圈》公號發佈，並且維護最新版本。如果發現圖片不可見，請去《技術自由圈》公號查找

尼恩：LLM大模型學習聖經PDF的起源

在40歲老架構師尼恩的讀者交流羣(50+)中，經常性的指導小夥伴們改造簡歷。

經過尼恩的改造之後，很多小夥伴拿到了一線互聯網企業如得物、阿里、滴滴、極兔、有贊、希音、百度、網易、美團的面試機會，拿到了大廠機會。

然而，其中一個成功案例，是一個9年經驗網易的小夥伴，當時拿到了一個年薪近80W的大模型架構offer，逆漲50%，那是在去年2023年的 5月。

驚天大逆襲：8年小夥20天時間提75W年薪offer，逆漲50%，祕訣在這

不到1年，小夥伴也在團隊站穩了腳跟，成爲了名副其實的大模型架構師。

目前，他管理了10人左右的團隊，包括一個2-3人的python算法小分隊，包括一個3-4人Java應用開發小分隊，包括一個2-3人實施運維小分隊。並且他們的產品也收到了豐厚的經濟回報，他們的AIGC大模型產品，好像已經實施了不下10家的大中型企業客戶。

當然，尼恩更關注的，主要還是他的個人的職業身價。小夥伴反饋，不到一年，他現在是人才市場的香饃饃。怎麼說呢？他現在職業機會不知道有多少, 讓現在一個機會沒有的小夥伴們羨慕不已。

只要他在BOSS上把簡歷一打開，就有大量的獵頭、甲方公司挖他，機會可以說是非常非常非常多，給他拋繡球的不知道有多少：

並且來找他的，很多都是按照P8標準，年薪200W來的。

相當於他不到1年時間，職業身價翻了1倍多，可以拿到年薪 200W的offer了。

回想一下，去年小夥伴來找尼恩的時候，可謂是令人唏噓。

當時，小夥伴被網易裁員，自己折騰 2個月，沒什麼好的offer，才找尼恩求助。

當時，小夥伴其實並沒有做過的大模型架構，僅僅具備一些通用架構（ JAVA 架構、K8S雲原生架構）能力，而且這些能力還沒有完全成型。特別說明，他當時沒有做過大模型的架構，對大模型架構是一片空白。

本來，尼恩是規劃指導小夥做通用架構師的（ JAVA 架構、K8S雲原生架構）,

毫無疑問，大模型架構師更有錢途，所以，當時候尼恩也是壯着膽子，死馬當作活馬指導他改造爲大模型架構師。

回憶起當時決策的出發點，主要有3個：

（1）架構思想和體系，本身和語言無關，和業務也關係不大，都是通的。

（2）小夥伴本身也熟悉一點點深度學習，懂python，懂點深度學習的框架，至少，demo能跑起來。

（3）大模型架構師稀缺，反正面試官也不是太懂大模型架構。

基於這個3個原因，尼恩大膽的決策，指導他往大模型架構走，先改造簡歷，然後去面試大模型的工程架構師，特別注意，這個小夥伴面的不是大模型算法架構師。

沒想到，由於尼恩的大膽指導，小夥伴成了。

沒想到，由於尼恩的大膽指導，小夥伴成了，而且是大成，實現了真正的逆天改命。

相當於他不到1年時間，職業身價翻了1倍多，可以拿到年薪 200W的offer了。

既然有一個這麼成功的案例，尼恩能想到的，就是希望能幫助更多的社羣小夥伴，成長爲大模型架構師，也去逆天改命。

於是，從2024年的4月份開始，尼恩開始寫《LLM大模型學習聖經》，幫助大家穿透大模型，走向大模型之路。

尼恩架構團隊的大模型《LLM大模型學習聖經》是一個系列，初步的規劃包括下面的內容：

《LLM大模型學習聖經：從0到1喫透Transformer技術底座》
《LLM大模型學習聖經：從0到1精通RAG架構，基於LLM+RAG構建生產級企業知識庫》
《LLM大模型學習聖經：從0到1喫透大模型的頂級架構》

本文是第2篇，這一篇的作者是robin。

尼恩架構團隊會持續迭代和更新，後面會有實戰篇，架構篇等等出來。並且錄製配套視頻。

在尼恩的架構師哲學中，開宗明義：架構和語言無關，架構的思想和模式，本就是想通的。

架構思想和體系，本身和語言無關，和業務也關係不大，都是通的。

所以，尼恩用自己的架構內功，以及20年時間積累的架構洪荒之力，通過《LLM大模型學習聖經》，給大家做一下系統化、體系化的LLM梳理，使得大家內力猛增，成爲大模型架構師，然後實現”offer直提”，逆天改命。

尼恩《LLM大模型學習聖經》PDF 系列文檔，會延續尼恩的一貫風格，會持續迭代，持續升級。

這個文檔將成爲大家學習大模型的殺手鐗，此文當最新PDF版本，可以來《技術自由圈》公號獲取。

1. 大語言模型簡介

1.1 大語言模型簡介：探索AI的新邊疆

在AI的浩瀚宇宙中，語言模型猶如一艘艘探索船，它們通過預測單詞序列的概率，解碼語言的奧祕。這些由人工神經網絡構成的模型，經過海量文本數據的洗禮，不僅理解語言的本質，更能預測序列中的下一個單詞。當我們將這些模型的參數規模擴大到一個全新的量級時，便誕生了所謂的大型語言模型（LLM），它們以其龐大的參數數量，學習語言中的複雜模式，爲世界帶來了革命性的影響。

預訓練語言模型（PLM）：NLP的瑞士軍刀

在NLP的征途上，預訓練語言模型（PLM）以其在處理各種任務時展現的卓越能力，成爲了研究者們的得力助手。隨着模型規模的擴展，研究人員發現，這不僅提升了模型的性能，更解鎖了小規模模型所不具備的特殊能力。這種現象，就像是在AI的進化樹上，找到了一個新的分支——大語言模型（LLM）。

大語言模型（LLM）：AI進化的里程碑

LLM的研究揭示了一個有趣的現象：當模型的規模達到一定程度時，它們開始展現出一些被稱爲“湧現能力”的特質。這些能力在小規模的PLM中是難以觀察到的。例如，GPT-3通過上下文學習（ICL）解決了小樣本任務，而GPT-2則在這方面表現平平。ChatGPT的出現，更是將LLM的應用推向了一個新的高度，它在對話領域的卓越表現，讓人們對通用人工智能（AGI）的實現充滿了期待。

LLM與PLM：大小之間的質變

LLM與PLM之間的主要區別在於它們是否具備湧現能力，以及它們的使用方式和開發過程。LLM的出現，預示着人工智能開發和使用方式的徹底變革。研究人員和工程師需要緊密合作，共同解決在大規模數據處理和分佈式並行訓練中遇到的複雜工程問題。

大語言模型的湧現能力：AI的新技能

LLM的湧現能力包括上下文學習、指令遵循和逐步推理。這些能力使得LLM在解決複雜任務時表現出色，尤其是當它們通過思維鏈（CoT）提示策略來解決涉及多個推理步驟的問題時。

大語言模型的關鍵技術：構建AI的基石

LLM的成功，離不開一系列關鍵技術的發展，包括擴展定律、大規模訓練、能力引導、對齊微調和工具操作。這些技術不僅提升了LLM的性能，更使得LLM能夠更好地與人類價值觀對齊，並利用外部工具擴展其能力。

在這篇文章中，我們不僅探討了LLM的基本概念和關鍵技術，更通過實際案例，展示了LLM如何在實際應用中展現出其獨特的價值。隨着技術的不斷進步，LLM有望在未來的AI領域中發揮更加重要的作用。

1.2 大語言模型特點

1. 具備湧現能力

LLM 的湧現能力被正式定義爲 “在小型模型中不存在但在大型模型中產生的能力”，模型具有從原始訓練數據中自動學習並發現新的、更高層次的特徵和模式的能力,這是區別 LLM 與先前 PLM 的最顯著特徵之一。

2. 訓練數據大且難度大：

基於海量數據(書籍、文章和對話)進行訓練（TB級，甚至PB級），接受大量未標記文本的訓練，可能達到數千億個單詞，GPT-3 使用 45 TB 的文本進行訓練，而 Codex 則使用 159 GB 的文本進行訓練。

GPT-3（175B）：
- 由OpenAI開發，是一個具有1750億參數的大型語言模型。
- 預訓練數據集包含3000億個token，來源包括CommonCrawl、WebText2、Books1、Books2和Wikipedia。
PaLM（540B）：
- 由Google Research提出，是一個具有5400億參數的多任務、多模態大型語言模型。
- 預訓練數據集包含7800億個token，來源包括社交媒體對話、過濾後的網頁、書籍、Github、多語言維基百科和新聞。
LLaMA：
- 是Meta AI提出的一種大型語言模型系列，具有不同的大小變體，從6億參數到65億參數不等。
- 訓練數據來源多樣，包括CommonCrawl、C4、Github、Wikipedia、書籍、ArXiv和StackExchange。
- LLaMA（6B）和LLaMA（13B）使用了1萬億個token進行訓練，而更大的模型版本LLaMA（32B）和LLaMA（65B）則使用了1.4萬億個token。

3. 模型參數量大

大型語言模型由可能具有數千億，數萬個參數的神經網絡組成，使它們能夠學習語言中的複雜模式，OpenAI 發佈了 GPT-3，這是一個擁有 1750 億個參數的模型。

4. 生成的模型大

一般來說，大型語言模型的大小爲數十 GB。

5. 訓練需要算力規模

訓練基礎模型需要上千塊，甚至上萬塊高性能GPU才能完成。

1.3 大型語言模型四要素

大模型三要素：算力、算法、數據、場景。大模型是"大數據 + 大算力 + 強算法"結合的產物，大模型要到具體場景應用才能發揮最大的價值。

1. 算力：AI的心臟

在AI的宏偉藍圖中，算力是那顆不斷跳動的心臟。它決定了數據處理的能力，就如同血液的流動速度。芯片，作爲算力的核心，其性能的優劣直接關係到大模型處理能力的速度。黃仁勳在2023年2月的財報會上提到，過去十年間，通過不斷的技術創新和合作，大語言模型的處理速度實現了質的飛躍，提高了驚人的100萬倍。

2. 算法：AI的大腦

算法，作爲AI的大腦，是解決問題的核心機制。不同的算法就像是通往解決方案的不同路徑，而它們的效率和效果可以通過空間和時間複雜度來衡量。GPT，這個在Transformer模型基礎上發展起來的明星，自2017年由Google提出以來，就在NLP領域掀起了一場革命。它摒棄了傳統的RNN和CNN，以更好的並行性和更短的訓練時間，在處理長文本時展現出了無與倫比的優勢。

3. 數據：AI的養料

數據，是算法訓練的養料。在模型的早期訓練階段，需要大量數據的餵養，以形成模型的理解能力。而在中後期，數據的質量則直接決定了模型的精度。在機器學習的過程中，使用標註好的數據進行訓練是至關重要的。數據標註是對原始數據進行加工處理，使其轉化爲機器可識別的信息。只有通過大量訓練，覆蓋儘可能多的場景，才能孕育出一個優秀的模型。目前，大模型的訓練數據集主要來源於公開數據，如維基百科、書籍、期刊、Reddit鏈接、Common Crawl等。而在中後期，高質量數據的引入將顯著提升模型的精度。例如，更加事實性的數據將提高模型的準確性，而更加通順的中文語言數據將增強模型對中文的理解能力。此外，高質量的反饋數據也能提升模型性能，如ChatGPT採用的人類強化學習RLHF技術，通過專業的問題、指令和人類反饋排序等方式，加強了模型對人類語言邏輯的理解。最終，通過更精準的垂直領域數據，可以構建出更細分領域的專業模型。

4. 場景：AI的舞臺

大預言模型的應用場景衆多，技術與場景的結合是誕生有價值應用的溫牀。從文本生成到語言理解，從機器翻譯到智能對話，LLM在各個領域都有着廣泛的應用。隨着技術的不斷進步和創新，LLM將在更多的場景中展現出其獨特的價值，爲人類社會的發展貢獻AI的力量。

1.4 大語言模型應用

在當前的人工智能領域，大型語言模型（Large Language Models，簡稱LLM）已成爲推動業務創新和操作效率的關鍵技術。通過在龐大的數據集上進行預訓練，這些模型不僅展現出卓越的通用性和泛化能力，還極大地降低了人工智能應用的技術門檻。用戶可以藉助零樣本或小樣本學習迅速實現先進的應用效果，而“預訓練+精調”的開發模式標準化了研發流程，顯著降低了技術難度，促進了AI技術在各行各業的廣泛應用。大型語言模型爲企業帶來的主要好處包括：

1. 業務流程自動化

大型語言模型能夠自動化處理多種業務流程，如客戶服務、文本生成、預測和分類任務等。這種自動化減少了人工操作的需求，降低了相關成本，使員工能夠將精力集中在更加核心和有價值的任務上。例如，在客戶支持領域，通過自動響應客戶的查詢，大大提高了處理效率和客戶滿意度。

2. 促進個性化交互

通過運用大型語言模型，聊天機器人和虛擬助理能夠實現全天候的客戶服務，這些系統能夠分析和處理大量數據，深入理解客戶的行爲和偏好，從而實現高度個性化的交互。不論是在電子商務推薦、個性化營銷還是內容創建中，這種個性化的能力都極大地提升了用戶體驗和客戶忠誠度。

3. 提升任務準確性

大型語言模型通過分析和處理大量的數據來提高任務執行的準確性，這在數據密集型的任務中尤爲重要。例如，通過分析數千條客戶反饋，模型能夠精確地識別和歸類客戶的情緒和意見，無論是在市場研究、公關監控還是社交媒體分析中，都能夠提供深入且準確的洞察。

2. 檢索增強生成（RAG）

2.2 RAG是什麼？

檢索增強生成（RAG）是指對大型語言模型輸出進行優化，使其能夠在生成響應之前引用訓練數據來源之外的權威知識庫。大型語言模型（LLM）用海量數據進行訓練，使用數十億個參數爲回答問題、翻譯語言和完成句子等任務生成原始輸出。在 LLM 本就強大的功能基礎上，RAG 將其擴展爲能訪問特定領域或組織的內部知識庫，所有這些都無需重新訓練模型。這是一種經濟高效地改進 LLM 輸出的方法，讓它在各種情境下都能保持相關性、準確性和實用性。

2.2.1 RAG的誕生背景

隨着對大型模型應用探索的深入，檢索增強生成技術（Retrieval-Augmented Generation）受到了廣泛關注，並被應用於各種場景，如知識庫問答、法律顧問、學習助手、網站機器人等。在大型語言模型（LLM）的探索旅程中，檢索增強生成（RAG）技術正逐漸顯露其鋒芒，爲LLM的未來發展注入了創新的動力。以下是對RAG技術及其在LLM中應用的深入探討。

2.2.1.1 LLM面臨的挑戰有哪些

儘管ChatGPT和Claude等LLM展現了令人印象深刻的能力，但它們也面臨着一些挑戰：

產生臆想的答案（幻覺）：在沒有確切答案的情況下，LLM可能會產生誤導性信息。
知識更新慢：當用戶需要基於最新情況的具體響應時，LLM可能提供過時或不具體的信息。
知識來源缺乏引用：LLM可能引用非權威來源的信息，影響回答的準確性。
術語混淆：不同訓練數據中相同的術語可能指向不同概念，導致LLM產生混淆。
領域專業知識不足： 儘管LLM擁有廣泛的知識基礎，但它們並不瞭解特定業務的細節，如公司的私有數據。

2.2.1.12 RAG技術的解決的問題

避免“幻覺”問題：RAG 通過檢索外部信息作爲輸入，獲取領域特定的知識，輔助大型模型回答問題，這種方法能顯著減少生成信息不準確的問題，。
信息的實時性：RAG 允許從外部數據源實時檢索信息，RAG允許LLM訪問最新的客戶記錄、產品規格和實時庫存信息，解決知識時效性問題。
解決黑匣子問題：RAG技術使GenAI應用程序能夠提供其使用的數據來源，增加透明度，類似於學術論文中的引用，增加回答的可追溯性。
數據隱私和安全：RAG 可以將知識庫作爲外部附件管理企業或機構的私有數據，避免數據在模型學習後以不可控的方式泄露。
降低應用成本：RAG提供了一種經濟高效的方法，使得組織能夠在不重新訓練模型的情況下，提升LLM的輸出質量。

2.2.1.3 長上下文處理能力會殺死RAG嗎？

長上下文處理能力的提升確實爲大型語言模型（LLMs）帶來了顯著的進步，尤其是在處理長篇文檔和複雜查詢方面。然而，儘管LLMs的上下文長度得到了擴展，RAG（Retrieval-Augmented Generation）依然保有其獨特的價值和應用場景，並不會完全被長上下文處理所替代。以下是RAG保持其重要性的幾個關鍵優勢：

白盒模型的透明度和可解釋性：RAG的工作流程相對透明，模塊之間的關係清晰，這爲模型的效果調優和可解釋性提供了優勢。在檢索召回的內容質量不高或置信度不足時，RAG系統有能力避免生成誤導性信息，選擇不生成回答而非提供錯誤的信息。
成本效益和響應速度：與微調模型相比，RAG的訓練週期更短，成本更低。與長文本處理相比，RAG能夠提供更快速的響應和更低的推理成本。在工業界和產業應用中，成本是一個至關重要的因素，而RAG在這一點上具有明顯的優勢。
私有數據管理與安全性：RAG通過將知識庫與大型模型分離，爲私有數據的管理提供了一個安全的實踐基礎。這種方法有助於企業更好地控制和管理其知識資產，同時解決了知識依賴問題。此外，RAG底座數據庫的訪問權限控制和數據管理相對容易實現，而這對於大模型來說則較爲困難。
靈活性和適應性：RAG能夠適應不同的數據源和檢索需求，爲特定領域或任務提供定製化的解決方案。這種靈活性使RAG在多種應用場景中都能找到其適用之處。
模塊化和可擴展性：RAG的模塊化設計允許它輕鬆集成新模塊或調整現有模塊之間的交互流程，以適應不斷變化的任務需求和數據環境。

因此，儘管長上下文處理爲LLMs帶來了新的機遇，RAG仍然在多個方面保持其獨特的價值和應用潛力。在未來，RAG可能會繼續與長上下文處理和其他先進技術相結合，共同推動自然語言處理技術的發展。

2.2.3 RAG具備性價比

如果沒有RAG那麼，我們處理之前提到問題還能通過以下方式進行處理

1. 預訓練：打造基石模型的挑戰

在AI的征途上，構建基礎模型的第一步便是資金的籌集。對於大多數企業而言，這是一個幾乎不可能完成的任務。OpenAI的Sam Altman曾估算，訓練ChatGPT背後的基石模型成本高達1億美元。除了原始的計算成本，人才的稀缺性同樣令人頭疼：你需要一支由機器學習博士、頂尖系統工程師和高技能操作人員組成的夢之隊，來攻克生成此類模型及其每個模型所面臨的衆多技術難題。全球的AI公司都在爭相搶奪這些稀有人才。

獲取、清洗和標記數據集以生成功能強大的基礎模型，是另一個挑戰。以法律發現公司爲例，如果你打算訓練模型以回答有關法律文件的問題，那麼還需要法律專家投入大量時間來標記訓練數據。

2. 微調：適配領域數據的策略

微調，即根據新數據對基礎模型進行再訓練，無疑是一種成本相對較低的方法。然而，它同樣面臨着與創建基礎模型相同的諸多挑戰：稀缺而深入的專業知識需求，充足的數據資源，以及在生產中部署模型的高昂成本和技術複雜性。

LLM與向量數據庫的結合，用於上下文檢索，使得微調成爲一種不太實用的手段。一些LLM提供商，如OpenAI，已不再支持對其最新一代模型進行微調。

微調，作爲提升LLM輸出質量的傳統方法，需要主題專家進行重複、昂貴且耗時的標記工作，並持續監控質量的漂移，以及由於缺乏定期更新或數據分佈變化導致的模型準確性的偏差。

隨着時間的推移，即使是經過微調的模型，其準確性也可能下降，這就需要更昂貴且更耗時的數據標記、持續的質量監控和重複的微調。

3. 提示工程：優化輸入的藝術

提示工程，即精心設計和調整輸入到模型中的指令（prompts），以引導模型執行特定的任務或操作，是提高通用人工智能（GenAI）應用程序準確性的一種成本較低的方法。

通過簡單地更改提示，可以快速迭代和更新模型的輸入，而無需重新訓練整個模型。通過快速工程，可以優化模型返回的響應，使其更加準確和相關。

儘管提示工程可以改善模型的響應，但它並不能爲模型提供新的或動態的上下文信息。

這意味着如果模型的輸入僅依賴於靜態的提示，它可能無法考慮到最新的信息或環境變化。由於缺乏最新上下文，模型可能產生與現實不符的輸出，這種情況被稱爲“幻覺”（hallucination）。

幻覺是大型語言模型在生成文本時可能遇到的問題之一，尤其是在需要最新信息的任務中。

RAG 優勢的一個示例 ChatGPT 可以解決超出訓練數據範圍無法回答的問題，並生成正確的結果。

該技術通過獲取外部數據來響應查詢來補充模型，從而確保更準確和最新的輸出。

我們也製作了0基礎入門的提示教程，幫助你掌握與大模型溝通的藝術，全都核心概念和實操相結合，也能從小白到專家華麗蛻變，實現大模型自由。

2.3 RAG技術概述與原理

幻覺現象在大型語言模型（LLM）中主要因其無法訪問最新信息而產生，這一問題根源於模型對其訓練數據集的嚴重依賴。爲了解決這一侷限，提出了一種名爲RAG（Retrieval-Augmented Generation）的方法，該方法允許LLM通過外部信息源動態地補充訓練數據，從而提高回答的準確性。

RAG通過結合傳統的檢索方法和預訓練的語言模型，實現了對LLM輸入信息的實時更新，避免了對模型進行昂貴且耗時的微調和再訓練。這種方法增強了模型的靈活性和擴展性，使其可以輕鬆地應用於不同的LLM，滿足多樣化的需求。

在實際應用中，RAG通過引入人類編寫的現實世界數據作爲信息源，不僅簡化了回答生成過程，還大幅提高了生成響應的可靠性。隨着技術的進步，RAG不斷髮展，已經能夠支持檢索與生成組件之間的多輪交互，通過多次迭代檢索提高信息準確性，同時逐步優化生成的輸出質量。

平臺如langchain和llamaindex已經對RAG方法進行了模塊化處理，這些平臺通過實現多輪搜索迭代到連續生成的不同策略，提高了方法的適應性，並擴展了其在實際應用中的範圍。這些創新表明，儘管各平臺對RAG的具體實施方法各不相同，但它們都遵循了基本的RAG工作流程，展示了這一技術在現代AI應用中的廣泛適用性和有效性。

RAG 概述

RAG 技術是一種用額外數據增強大型語言模型知識的方法。儘管 LLM 能夠對衆多主題進行推理，但其知識僅限於訓練時使用的特定時間點之前的公開數據。因此，爲了讓聊天機器人能夠對私有數據或截止日期後引入的數據進行推理，我們需要用特定的信息來增強模型的知識。這個過程就是檢索增強生成（RAG）。

一個典型的 RAG 應用主要包含兩個部分：

第一部分：索引
第二部分：檢索與生成

先看第一部分：

第一部分索引：

從源數據中加載數據並進行索引，通常離線進行，並且支持動態更新，分爲：

加載：根據不同的數據源選擇合適的加載器，加載數據得到文檔。
切分：使用文本切分器將文檔切分成更小的片段，使用小片段一方面可以更好地匹配用戶問題，同時也可以適應模型的有限上下文窗口。
存儲：存儲和索引切片，以便在檢索時能夠快速找到相關的數據，通常使用 Embeddings 模型和向量數據庫（VectorStore）來完成。

再看第一部分：

檢索與生成：實際的 RAG 鏈，接收用戶問題，從索引中檢索相關數據，基於問題和這些數據生成結果，分爲：

檢索：給定用戶輸入，使用檢索器從存儲中檢索相關的切片。
生成：使用包括問題和檢索到的數據的提示調用 LLM 來生成答案。

2.3 RAG系統的主要組件和工作流程

2.3.1 RAG系統的核心組件與工作流程

RAG（Retrieval-Augmented Generation，檢索增強生成）系統是一個將生成式AI的優勢與搜索引擎的功能相結合的複雜系統。要深入理解RAG，關鍵在於剖析其核心組件以及這些組件是如何協同工作的，以提供無縫的AI體驗。

檢索引擎：數據的精準定位

RAG過程的首步是檢索引擎的介入。這一環節涉及對龐大的信息庫進行搜索，以定位與輸入查詢相匹配的相關數據。檢索引擎運用精細的算法，確保所檢索到的信息不僅相關性強，而且保持最新，爲生成準確的響應打下堅實基礎。

增強引擎：上下文的深度融合

檢索得到的相關信息隨後被送入增強引擎。這一引擎的職責是將檢索到的數據與原始查詢緊密結合，從而擴充上下文的深度，爲生成過程奠定一個更加明智的基礎。增強引擎的介入，使得生成的響應更加精準和全面。

生成引擎：智能響應的構建

最終，經過增強的輸入信息被送入生成引擎。這裏，通常是利用複雜的語言模型，基於擴充後的上下文創建出既連貫又緊密相關的響應。這種響應的生成，不僅依託於模型內部的先驗知識，還通過檢索引擎提供的外部數據得到了顯著增強。

2.3.2 RAG工作流程的全景視圖

RAG的基本工作流程始於創建一個包含外部信息源的索引庫。這個索引庫是檢索器模型的基石，它根據特定查詢檢索出相關的信息。在這一過程的最後階段，生成器模型將檢索到的信息與原始查詢融合，形成最終的輸出結果。

RAG（Retrieval-Augmented Generation，檢索增強生成）應用程序的成功依賴於一系列精心設計的步驟，確保了輸出的準確性和相關性。以下是RAG系統關鍵步驟的深入分析。

第一步，數據索引：構建檢索的基石

在RAG系統中，數據索引是基礎。它涉及將文檔分割成塊，編碼爲向量，並存儲於向量數據庫中，爲檢索引擎提供參考點。文本規範化，包括標記化、詞幹提取和停用詞去除，是增強文本適用性的重要步驟。深度學習技術的應用，特別是預訓練的語言模型（LM），爲文本生成語義向量表示，極大地提升了索引的效率和檢索的精確度。

第二步，輸入查詢處理：理解並轉化用戶需求

用戶的輸入是RAG過程的起點。系統需要準確處理和理解這些輸入，以形成檢索引擎的搜索查詢。這一步驟是確保檢索結果與用戶需求高度相關的關鍵。

第三步，搜索和排名：找到最相關的信息

檢索引擎根據輸入查詢的相關性對索引數據進行搜索和排名。利用語義相似性，檢索與問題最相關的前k個塊，這一步驟是RAG系統的核心，它決定了後續生成響應的質量和相關性。

第四步提示增強：豐富輸入，提升輸出

將檢索到的最相關信息與原始查詢結合，形成增強的提示。這一步驟爲生成引擎提供了更豐富的信息源，有助於生成更準確和相關的響應。

第五步，響應生成：構建最終答案

生成引擎結合原始問題和檢索到的信息，輸入LLM生成最終答案。這一步驟需要在保持與檢索內容一致性和準確性的同時，引入創造性，以生成既準確又具有洞察力的文本。

第六步，評估：持續優化的關鍵

評估是確保RAG應用成功的最後一步。它提供了關於系統輸出準確性、忠實性和響應速度的客觀衡量，是持續優化RAG策略的關鍵環節。

我們仔細看看RAG內部從索引，檢索，增強到最後生成每一步都是怎麼運行的，以及使用RAG和不使用RAG對返回結果的效果影響如何。

2.3 RAG範式

RAG研究範式在不斷髮展，我們將其分爲三個階段：Naive RAG、Advanced RAG和Modular RAG。儘管 RAG 方法具有成本效益並且超越了LLM的性能，但它們也表現出一些侷限性。 Advanced RAG 和 Modular RAG 的發展正是針對 Naive RAG 的這些具體缺點的迴應。

2.3.1 第一階段，樸素RAG

Naive RAG 研究範式代表了最早的方法，在 ChatGPT 廣泛採用後不久就得到了重視。

Naive RAG 遵循傳統的過程，包括索引、檢索和生成，也被稱爲“檢索-生成”框架，前面講的RAG是樸素RAG，它是最基礎的，最核心的架構。

隨着大模型落地不斷深化，樸素RAG也有一些缺點：

檢索挑戰——檢索階段經常在【精確度】和【召回率】方面遇到困難，導致選擇錯位或不相關的塊，並丟失關鍵信息。

生成困難——在生成響應時，模型可能會面臨幻覺問題，即生成【檢索到的上下文不支持的內容】。此階段還可能會受到輸出的【不相關性、毒性或偏差】的影響，從而降低響應的質量和可靠性。

增強障礙——將檢索到的信息與不同的任務集成可能具有挑戰性，有時會導致【輸出脫節或不連貫】。當從多個來源檢索類似信息時，該過程還可能遇到【冗餘，從而導致重複響應】。確定各個段落的重要性和相關性並確保風格和語氣的一致性進一步增加了複雜性。面對複雜的問題，基於原始查詢的【單一檢索可能不足以獲取足夠的上下文信息】。

2.3.2 第二階段，高級RAG

Advanced RAG 引入了特定的改進來克服 Naive RAG 的侷限性。

它着眼於提高檢索質量，採用檢索前和檢索後策略。

爲了解決索引問題，Advanced RAG 通過使用【滑動窗口方法】、【細粒度分段】和【合併元數據】來改進其索引技術。此外，它還結合了多種優化方法來簡化檢索過程。

預檢索過程——這一階段的主要重點是【優化索引結構和原始查詢】。優化索引的目標是提高索引內容的質量。這涉及到策略：增強數據粒度、優化索引結構、添加元數據、對齊優化、混合檢索。而查詢優化的目標是讓用戶的原始問題更清晰、更適合檢索任務。常見的方法包括查詢重寫、查詢變換、查詢擴展等技術。

檢索後過程——一旦檢索到相關上下文，將其與查詢有效集成就至關重要。檢索後過程中的主要方法包括【重新排序塊和上下文壓縮】。重新排列檢索到的信息以將最相關的內容重新定位到提示的上下文中是一個關鍵策略。

2.3.3 第三階段，模塊化RAG

模塊化 RAG 架構超越了前兩種 RAG 範例，提供了增強的適應性和多功能性。

它採用了多種策略來改進其組件，例如添加用於相似性搜索的搜索模塊以及通過微調來改進檢索器。

重組 RAG 模塊等創新並重新排列 RAG 管道的引入是爲了應對特定的挑戰。

向模塊化 RAG 方法的轉變正在變得普遍，支持跨其組件的順序處理和集成的端到端訓練。

儘管具有獨特性，模塊化 RAG 仍建立在高級 RAG 和樸素 RAG 的基本原則之上，展示了 RAG 系列的進步和完善。

新模塊

模塊化 RAG 框架引入了額外的專用組件來增強檢索和處理能力。

搜索模塊適應特定場景，使用LLM生成的代碼和查詢語言，可以跨搜索引擎、數據庫和知識圖譜等各種數據源直接搜索。

RAG-Fusion 通過採用多查詢策略將用戶查詢擴展到不同的視角，利用並行向量搜索和智能重新排序來揭示顯式和變革性知識，從而解決了傳統搜索的侷限性。

內存模塊利用LLM的內存來指導檢索，創建一個無限的內存池，通過迭代的自我增強使文本與數據分佈更緊密地對齊。

RAG系統中的路由可導航不同的數據源，爲查詢選擇最佳路徑，無論是涉及彙總、特定數據庫搜索還是合併不同的信息流。

Predict模塊旨在通過LLM直接生成上下文來減少冗餘和噪音，確保相關性和準確性。

任務適配器模塊根據各種下游任務定製 RAG，自動提示檢索零樣本輸入，並通過少數樣本查詢生成創建特定於任務的檢索器。這種綜合方法不僅簡化了檢索過程，而且顯着提高了檢索信息的質量和相關性，以更高的精度和靈活性滿足了廣泛的任務和查詢。

模塊化 RAG 的優勢

模塊化 RAG 通過允許模塊替換或重新配置來解決特定挑戰，從而提供卓越的適應性。

這超越了 Naive 和 Advanced RAG 的固定結構，其特點是簡單的“檢索”和“讀取”機制。

此外，模塊化 RAG 通過集成新模塊或調整現有模塊之間的交互流程來擴展這種靈活性，從而增強其在不同任務中的適用性。

重寫-檢索-讀取等創新模型利用LLM的能力通過重寫模塊和LM反饋機制來細化檢索查詢來更新重寫模型，從而提高任務性能。

類似地，像Generate-Read 用LLM生成的內容取代傳統檢索，而背誦閱讀強調從模型權重中檢索，增強模型處理知識密集型任務的能力。混合檢索策略集成了關鍵字、語義和向量搜索來滿足不同的查詢。

此外，採用子查詢和假設文檔嵌入（HyDE）旨在通過關注生成的答案和真實文檔之間嵌入相似性來提高檢索相關性。

模塊佈局和交互的調整，例如演示-搜索-預測（DSP）框架和 ITER-RETGEN 的迭代檢索-讀取-檢索-讀取流程，展示了模塊輸出的動態使用來支持另一個模塊的功能，說明了對增強模塊協同作用的複雜理解。

Modular RAG Flow 的靈活編排展示了通過 FLARE 等技術進行自適應檢索的優勢和自我 RAG 。

該方法超越了固定的RAG檢索過程，根據不同場景評估檢索的必要性。

靈活架構的另一個好處是RAG系統可以更輕鬆地與其他技術（例如微調或強化學習）集成。

模塊化RAG的核心在於將各種功能解耦，將其作爲獨立的模塊進行處理。具體來說，模塊化RAG包括了「搜索」、「預測」、「記憶」、「評估」、「驗證」和「對齊」等外層模塊，以及內層的「檢索」、「重排序」、「重寫」和「閱讀」等RAG核心過程。

在處理信息和響應用戶查詢的過程中，模塊化RAG採用了多種信息處理流程。

例如，傳統的Navie RAG模式僅包括基本的「檢索」和「閱讀」步驟。

而在更復雜的Advanced RAG模式中，包括了「重寫」→「檢索」→「重排序」→「閱讀」的路徑，這在提高檢索和生成內容的質量方面尤爲有效。

DSP（Demonstrate-Search-Predict）模式則專注於驗證、搜索和預測階段，這些模塊和模式的組合賦予了模塊化RAG極大的靈活性和適應性，使其成爲一種強大且可擴展的工具，能夠有效地應對各種信息處理挑戰，並在多樣化的應用場景中提供高質量的回答。

2.3.1 預檢索

檢索增強生成的預檢索階段爲成功的數據和查詢準備奠定了基礎，確保高效的信息檢索。

此階段包括爲有效數據訪問做好準備的基本任務。

索引

該過程從索引開始，索引建立一個有組織的系統，以實現快速、準確的信息檢索。

索引的特殊性取決於任務和數據類型。

例如，句子級索引有利於問答系統精確定位答案，而文檔級索引更適合總結文檔以瞭解其主要概念和思想。

查詢操作

建立索引後，將執行查詢操作來調整用戶查詢，以便更好地匹配索引數據。

這涉及查詢重構，重寫查詢以更符合用戶的意圖；查詢擴展，它擴展了查詢以通過同義詞或相關術語捕獲更多相關結果；查詢規範化，解決拼寫或術語的差異，以實現一致的查詢匹配。

數據修改

數據修改對於提高檢索效率也至關重要。此步驟包括預處理技術，例如刪除不相關或冗餘信息以提高結果質量，並使用元數據等附加信息豐富數據以提高檢索內容的相關性和多樣性.

2.3.2 檢索

搜索與排名

檢索階段是搜索和排序的結合。

它專注於從數據集中選擇文檔並確定其優先級，以提高生成模型輸出的質量。此階段使用搜索算法來瀏覽索引數據，查找與用戶查詢匹配的文檔。

識別相關文檔後，對這些文檔進行初始排名的過程開始根據它們與查詢的相關性對它們進行排序。

2.3.3 檢索後

檢索後階段用於細化最初檢索的文檔，以提高文本生成的質量。

此階段包括重新排序和過濾，每個階段都旨在優化最終生成任務的文檔選擇。

重排序

在重新排序步驟中，先前檢索到的文檔將被重新評估、評分和重新組織。目的是更準確地突出顯示與查詢最相關的文檔，並降低不太相關的文檔的重要性。此步驟涉及合併額外的指標和外部知識源以提高精度。在這種情況下，由於可用的候選文檔集有限，可以有效地使用精度較高但效率較低的預訓練模型

過濾

過濾的目的是刪除不符合指定質量或相關性標準的文檔。這可以通過多種方法來完成，例如建立最小相關性分數閾值以排除低於特定相關性級別的文檔。此外，使用用戶反饋或先前的相關性評估有助於調整過濾過程，保證只保留最相關的文檔用於文本生成。

2.3.4 生成

生成階段是 RAG 流程的重要組成部分，負責利用檢索到的信息來提高生成響應的質量。

此階段包含幾個子步驟，旨在生成可讀、引人入勝且信息豐富的內容。

增強

生成階段的核心是增強步驟，其目標是將檢索到的信息與用戶的查詢合併，以創建連貫且相關的響應。這包括闡述的過程，向檢索到的內容添加額外的細節以豐富它。

努力的重點是通過改寫和重組等方法提高清晰度、連貫性和風格吸引力，從而提高產出的質量。

綜合各種來源的信息以提供全面的視角，並進行驗證以確保內容的準確性和相關性。

定製化

定製是一個可選步驟，涉及調整內容以符合用戶的特定偏好或請求的上下文。

這種定製包括調整內容以滿足目標受衆的需求或呈現內容的格式，並壓縮信息以簡潔地傳達內容的本質。

該過程還需要創建強調要點或論點的摘要或摘要，確保輸出內容豐富且簡潔。

熟悉推薦和廣告系統的人員對此應該不陌生，推薦系統和廣告系統只是缺少了生成過程，前面的索引，檢索，排序和重排序都是同樣的原理，主打一個精準。

3. 網絡爬蟲與數據採集

我們在使用一些大模型的時候，我們通常會放一個網址，讓大模型幫我們解讀，這裏面究竟是怎麼回事?

我們先來看一個簡單網頁爬取。

import re
from typing import List, Union
import requests
from bs4 import BeautifulSoup
def html_document_loader(url: Union[str, bytes]) -> str:
    """
    Loads the HTML content of a document from a given URL and return it's content.
    Args:
        url: The URL of the document.
    Returns:
        The content of the document.
    Raises:
        Exception: If there is an error while making the HTTP request.
    """
    try:
        response = requests.get(url)
        html_content = response.text
    except Exception as e:
        print(f"Failed to load {url} due to exception {e}")
        return ""
    try:
        # Create a Beautiful Soup object to parse html
        soup = BeautifulSoup(html_content, "html.parser")
        # Remove script and style tags
        for script in soup(["script", "style"]):
            script.extract()
        # Get the plain text from the HTML document
        text = soup.get_text()
        # Remove excess whitespace and newlines
        text = re.sub("\s+", " ", text).strip()
        return text
    except Exception as e:
        print(f"Exception {e} while loading document")
        return ""

用於解析HTML內容並提取純文本。

使用BeautifulSoup解析HTML

創建一個 BeautifulSoup 對象，用於解析HTML文檔。"html.parser" 是指定的解析器。

清理HTML

使用 soup(["script", "style"]) 找到所有的 <script> 和 <style> 標籤，並通過 script.extract() 移除它們，因爲這些標籤通常包含JavaScript代碼或CSS樣式，而不是文檔的文本內容。

提取文本

使用 soup.get_text() 獲取HTML文檔的純文本。

去除多餘的空白和換行

使用正則表達式 re.sub("\s+", " ", text).strip() 替換一個或多個空白字符（包括空格、製表符、換行符等）爲單個空格，並且移除字符串首尾的空白字符。

返回處理後的文本

最終，處理後的文本通過 return text 返回。

由於爬蟲不是本文的重點，大家可以看以下兩個網址，

https://python3webspider.cuiqingcai.com/8.2-ji-yan-hua-dong-yan-zheng-ma-shi-bie

https://rapidapi.com/trafapi/api/trafilatura

第一個是介紹如何使用python抓取網頁的教程，第二個是一個網頁爬取工具，通常用來採集語料庫，大語言模型數據採集。

4. 向量數據庫與Embedding模型

4.1 爲什麼現在每個人都在談論矢量數據庫？

RAG的核心之一就是向量數據庫，這種數據庫專門用於處理向量數據，爲機器學習和人工智能等領域提供了強大的支持。

隨着AI時代的到來，向量數據格式日益重要，在未來的數據基礎設施建設中，向量數據庫很可能會成爲一個關鍵組成部分。

向量數據庫作爲一種專爲存儲和檢索高維向量數據而優化的數據庫，在RAG框架中，其作用至關重要。

這種數據庫的主要優勢在於它能高效地處理和存儲大量的向量化數據，它們通常採用了特殊的數據結構和索引策略，來有效組織和檢索向量數據，這對於RAG系統的檢索組件來說是核心功能。

這些數據庫能夠處理高維度數據的同時，提供近似最近鄰（ANN）查詢，這種查詢可以快速找到與查詢向量相似的數據項。

使得RAG系統能夠快速從海量數據中檢索出與用戶查詢最相關的信息，顯著提高信息處理的速度。此外，向量數據庫在提高數據處理的精確度方面也發揮着關鍵作用。它能確保檢索結果的精確性和相關性，從而增強RAG系統生成模型的輸出質量。

4.2 RAG 場景對向量數據庫的需求

而檢索系統對向量數據庫的需求可以抽象描述爲：

高精度的召回：向量數據庫需要能夠準確召回與查詢語義最相關的文檔或信息片段。這要求數據庫能夠理解和處理高維向量空間中的複雜語義關係，確保召回內容與查詢的高度相關性。這裏的效果既包括向量檢索的數學召回精度也包括嵌入模型的語義精度。
快速響應：爲了不影響用戶體驗，召回操作需要在極短的時間內完成，通常是毫秒級別。這要求向量數據庫具備高效的查詢處理能力，以快速從大規模數據集中檢索和召回信息。此外，隨着數據量的增長和查詢需求的變化，向量數據庫需要能夠靈活擴展，以支持更多的數據和更復雜的查詢，同時保持召回效果的穩定性和可靠性。
處理多模態數據的能力：隨着應用場景的多樣化，向量數據庫可能需要處理不僅僅是文本，還有圖像、視頻等多模態數據。這要求數據庫能夠支持不同種類數據的嵌入，並能根據不同模態的數據查詢進行有效的召回。
可解釋性和可調試性：在召回效果不理想時，能夠提供足夠的信息幫助開發者診斷和優化是非常有價值的。因此，向量數據庫在設計時也應考慮到系統的可解釋性和可調試性。

4.3 如何選擇向量數據庫

混合搜索還是關鍵字搜索？

關鍵字+矢量搜索的混合會產生最佳結果，每個矢量數據庫供應商都意識到了這一點，提供了自己的定製混合搜索解決方案
本地部署還是雲原生？

許多供應商都在推銷“雲原生”，好像基礎設施是世界上最大的痛點，但從長遠來看，本地部署可以更加經濟，因此也更加有效
開源還是完全託管？

大多數供應商都建立在可用源代碼或開源代碼庫的基礎上，展示其底層方法，然後將管道的部署和基礎設施部分商業化化（通過完全託管的 SaaS）。仍然可以自行託管大量此類服務，但這需要額外的人力和內部技能要求。

4.4 向量數據庫對比

Pinecone

優點：非常容易啓動和運行（沒有託管負擔，它完全是雲原生的），用戶不需要了解有關矢量化或矢量索引的任何信息。文檔也寫得不錯。
缺點：完全專有，如果無法在 GitHub 上跟蹤他們的進展，就不可能知道幕後發生了什麼以及他們的路線圖上有什麼。此外，某些用戶的體驗凸顯了依賴完全外部的第三方託管服務的危險，以及從開發人員的角度來看完全缺乏對數據庫設置和運行方式的控制。考慮到現有開源、自託管替代方案的數量龐大，從長遠來看，依賴完全託管、閉源解決方案的成本影響可能會很大。
評價：在 2020-21 年，當矢量數據庫非常不受關注時，Pinecone 遠遠領先於潮流，並以其他供應商沒有的方式爲開發人員提供了便利的功能。快進到 2023 年，坦率地說，Pinecone 現在幾乎沒有其他供應商提供的功能，而且大多數其他供應商至少提供自託管、託管或嵌入式模式，更不用說他們的算法的源代碼了它們的底層技術對最終用戶是透明的。
官方頁面：pinecone.io

Weaviate

優點：優秀的文檔（最好的文檔之一，包括技術細節和正在進行的實驗）。 Weaviate 似乎確實專注於構建儘可能最佳的開發人員體驗，並且通過 Docker 啓動和運行非常容易。在查詢方面，它可以生成快速、亞毫秒級的搜索結果，同時提供關鍵字和矢量搜索功能。
缺點：因爲 Weaviate 是用 Golang 構建的，所以可擴展性是通過 Kubernetes 實現的，而且當數據變得非常大時，這種方法（與 Milvus 類似）需要相當數量的基礎設施資源。從長遠來看，Weaviate 的完全託管產品的成本影響尚不清楚，將其性能與其他基於 Rust 的替代方案（如 Qdrant 和 LanceDB）進行比較可能是有意義的（儘管時間會告訴我們哪種方法在最具成本效益的情況下可以更好地擴展）方式）。
評價：Weaviate 擁有龐大的用戶社區，並且開發團隊正在積極展示極端的可擴展性（數千億個向量），因此看起來他們的目標市場確實是擁有海量數據的大型企業。進行矢量搜索。提供關鍵詞搜索和矢量搜索，以及強大的混合搜索，使其能夠推廣到各種用例，直接與 Elasticsearch 等文檔數據庫競爭。 Weaviate 積極關注的另一個有趣領域涉及通過向量數據庫進行數據科學和機器學習，將其帶出傳統搜索和檢索應用程序的領域。
官方頁面：weaviate.io

Qdrant

優點：雖然比 Weaviate 新，但 Qdrant 也有很好的文檔，可以幫助開發人員輕鬆地通過 Docker 啓動和運行。它完全用 Rust 構建，提供開發人員可以通過 Rust、Python 和 Golang 客戶端使用的 API，這些是當今後端開發人員最流行的語言。由於 Rust 的潛在功能，它的資源利用率似乎低於 Golang 中構建的替代方案。目前可擴展性是通過分區和 Raft 共識協議來實現的，這是數據庫領域的標準實踐。
缺點：作爲一個比競爭對手相對較新的工具，Qdrant 在查詢用戶界面等領域一直在追趕 Weaviate 和 Milvus 等替代品，隨着每個新版本的發佈，這種差距正在迅速縮小。
評價：我認爲 Qdrant 有望成爲許多公司的首選矢量搜索後端，這些公司希望最大限度地降低基礎設施成本並利用現代編程語言 Rust 的強大功能。在撰寫本文時，混合搜索尚不可用，但根據他們的路線圖，它正在積極開發中。此外，Qdrant 不斷髮布有關如何優化內存中和磁盤上的 HNSW 實施的更新，這將極大地有助於其長期的搜索準確性和可擴展性目標。很明顯，根據 Qdrant的 GitHub 星級歷史記錄，Qdrant 的用戶社區正在快速增長（有趣的是，比 Weaviate 的速度更快）！。
官方頁面：qdrant.tech

Milvus/Zilliz

優點：非常成熟的數據庫，具有大量算法，因爲它在矢量數據庫生態系統中長期存在。提供了很多矢量索引選項，並在 Golang 中從頭開始構建，具有極高的可擴展性。截至 2023 年，它是唯一一家提供有效 DiskANN 實現的主要供應商，據說這是最有效的磁盤向量索引。
缺點：在我看來，Milvus 似乎是一個解決可擴展性問題的解決方案——它通過代理、負載均衡器、消息代理、Kafka 和 Kubernetes的組合實現了高度的可擴展性，這使得整個系統變得非常複雜並且資源密集。客戶端 API（例如 Python）也不像 Weaviate 和 Qdrant 等較新的數據庫那樣可讀或直觀，後者往往更注重開發人員體驗。
評價：Milvus 的構建理念是實現將數據流式傳輸到向量索引的大規模可擴展性，並且在許多情況下，當數據大小不太大時，Milvus 似乎有些過大了。對於更靜態和不頻繁的大規模情況，Qdrant 或 Weaviate 等替代方案可能更便宜，並且在生產中啓動和運行速度更快。
官方頁面：milvus.io和zilliz.com

Chroma

優點：爲開發人員提供方便的 Python/JavaScript 界面，以快速啓動和運行矢量存儲。它是市場上第一個默認提供嵌入式模式的矢量數據庫，其中數據庫和應用程序層緊密集成，允許開發人員快速構建、原型化並向世界展示他們的項目。
缺點：與其他專門構建的供應商不同，Chroma 主要是圍繞現有 OLAP 數據庫（Clickhouse）和現有開源矢量搜索實現（hnswlib）的 Python/TypeScript 包裝器。目前（截至 2023 年 6 月），它尚未實現自己的存儲層。
評價：矢量數據庫市場正在迅速發展，Chroma似乎傾向於採取“等待和觀望”的理念，並且是少數旨在提供多種託管選項的供應商之一：無服務器/嵌入式、自託管（客戶端-服務器）和雲原生分佈式 SaaS 解決方案，可能同時具有嵌入式和客戶端-服務器模式。根據路線圖，Chroma 的服務器實施正在進行中。 Chroma 引入的另一個有趣的創新領域是量化“查詢相關性”的方法，即返回的結果與輸入用戶查詢的接近程度。可視化嵌入空間（也在他們的路線圖中列出）是一個創新領域，可以讓數據庫用於除搜索之外的許多應用程序。然而，從長遠來看，我們從未見過嵌入式數據庫架構在矢量搜索領域成功商業化，因此它的演變（與 LanceDB 一起，如下所述）將會很有趣！
官方頁面：trychroma.com

LanceDB

優點：旨在對多模式數據（圖像、音頻、文本）執行分佈式索引和本地搜索，構建在Lance 數據格式之上，Lance 數據格式是一種用於 ML 的創新型柱狀數據格式。就像 Chroma 一樣，LanceDB 使用嵌入式、無服務器架構，並且是用 Rust 從頭開始構建的，因此與 Qdrant 一起，這是唯一一家利用速度、內存安全性和相對較低的資源利用率的其他主要矢量數據庫供應商。
缺點：在 2023 年，LanceDB 是一個非常年輕的數據庫，因此許多功能正在積極開發中，並且由於工程團隊不斷壯大，直到 2024 年功能的優先級將成爲一個挑戰。
評價：我認爲在所有矢量數據庫中，LanceDB與其他數據庫的區別最大。這主要是因爲它在存儲層本身（使用 Lance，一種比 parquet 更快的新列格式，專爲非常高效的掃描而設計）和基礎設施層上進行了創新 - 通過在其雲版本中使用無服務器架構。結果，大量基礎設施的複雜性降低，大大增加了開發人員構建以分佈式方式直接連接到數據湖的語義搜索應用程序的自由度和能力。
官方頁面：lancedb.com

Vespa

優點：提供最“企業就緒”的混合搜索功能，結合了久經考驗的關鍵字搜索功能和 HNSW 之上的自定義矢量搜索。儘管 Weaviate 等其他供應商也提供關鍵字和矢量搜索，但 Vespa 是最早推出此產品的供應商之一，這讓他們有充足的時間來優化其產品，使其變得快速、準確和可擴展。
缺點：由於應用程序層是用 Java 編寫的，因此開發人員的體驗不如使用 Go 或 Rust 等面向性能的語言編寫的更現代的替代方案那麼順暢。此外，直到最近，它還沒有使設置和拆除開發實例變得非常簡單，例如通過 Docker 和 Kubernetes。
評價：Vespa 確實提供了非常好的產品，但它的應用程序主要是用 Java 構建的，而後端和索引層是用 C++ 構建的。隨着時間的推移，這使得維護變得更加困難，因此，與其他替代方案相比，它往往會給開發人員帶來不太友好的感覺。如今，大多數新數據庫完全是用一種語言編寫的，通常是 Golang 或 Rust，而且 Weaviate、Qdrant 和 LanceDB 等數據庫的算法和架構創新速度似乎要快得多。
官方頁面：vespa.ai

Vald

優點：旨在通過高度分佈式架構處理多模式數據存儲，以及索引備份等有用功能。使用非常快的 ANN 搜索算法 NGT（鄰域圖和樹），當與高度分佈的向量索引結合使用時，該算法是最快的 ANN 算法之一。
缺點：似乎比其他供應商的整體吸引力和使用量要少得多，並且文檔沒有清楚地描述使用什麼矢量索引（“分佈式索引”相當模糊）。它似乎也完全由一個實體——雅虎！日本，關於其他主要用戶的信息很少。
評價：我認爲 Vald 是一個比其他供應商更小衆的供應商，主要迎合 Yahoo!日本的搜索要求較高，並且總體上用戶社區要小得多，至少從 GitHub 上的星數來看是這樣。部分原因可能是它的總部位於日本，營銷力度不如歐盟和灣區其他地位較高的供應商。
官方頁面：vald.vdaas.org

Elasticsearch、Redis 和 pgvector

優點：如果您已經在使用 Elasticsearch、Redis 或 PostgreSQL 等現有數據存儲，那麼利用它們的矢量索引和搜索產品非常簡單，而無需求助於新技術。
缺點：現有數據庫不一定以最佳方式存儲或索引數據，因爲它們被設計爲通用目的，因此，對於涉及百萬級矢量搜索及以上的數據，性能會受到影響。 Redis VSS（矢量搜索存儲）之所以快，主要是因爲它純粹在內存中，但當數據變得大於內存時，就有必要考慮替代解決方案。
評價：我認爲專用矢量數據庫將在需要語義搜索的領域慢慢超越現有數據庫，這主要是因爲它們在矢量搜索方面最關鍵的組件（存儲層）上進行創新。像 HNSW 和 ANN 算法這樣的索引方法在文獻中有詳細記錄，大多數數據庫供應商都可以推出自己的實現，但是專門構建的向量數據庫具有針對手頭任務進行優化的優點（更不用說它們是使用 Go 和 Rust 等現代編程語言編寫），並且出於可擴展性和性能的原因，從長遠來看，它很可能會在這個領域勝出。

4.5 什麼是Embedding？

矢量數據庫不僅存儲原始數據（可以是圖像、音頻或文本），還存儲其編碼形式：Embedding。

這些Embedding本質上是存儲數據上下文表示的數字（即vector）列表。

直觀上，當我們提到Embedding時，我們談論的是實際存在於更高維度的數據（圖像、文本、音頻）的壓縮、低維表示。

Embedding基於一個技巧：獲取一段內容（文字，圖片，視頻.....）並將該內容轉換爲浮點數數組。

{
  "word": "Valentine's Day",
  "vector": [0.12, 0.75, -0.33, 0.85, 0.21, ...etc...]
}

Embedding的重要性何在呢？

它建立了一座橋樑，連接了人類語言的豐富多彩與算法的冷冰冰的計算效率。

算法擅長數字遊戲，卻不通人情，而通過文本向量化，它們彷彿獲得瞭解讀和處理語言的新技能。

其應用範圍廣泛，從推薦觸動人心的內容，到讓聊天機器人更具人情味，再到在浩瀚的文本海洋中尋找微妙的規律，文本向量化無處不在。

文本向量化讓機器能夠進行情感分析、語言轉換等看似高深的任務，以一種越來越接近人類的方式來理解和處理語言。

這個圖的左邊，我們看的每一列（維)的數字代表一種特徵，比如有代表是否是人類，年齡，性別等。在二維平面裏用圖形化表示，我們可以理解Embeddings就是在x和y上的座標，相同的類會聚集在一起，但是爲什麼又叫做向量或者矢量，矢量是代表有方向的。

我們看的男人和女，與國王和女王線是平行的。說明沿着這條線的方向就代表性別的強度。越往右上角越代表越女性化。當維度越多，表徵就更多，代表的語義就更加豐富。

演示網址：https://projector.tensorflow.org/?ref=mlq.ai。

4.6 向量之間的距離

向量可能非常長且複雜。

例如，OpenAI 的向量大小通常爲 1536，這意味着每個Embeddings都是 1536 個浮點數的數組。

就其本身而言，這些數據並沒有多大意義：它只是爲了找到其他接近的Embeddings。

當我們將圖像或文本片段表示爲向量嵌入時，它們的語義相似性由它們的向量在向量空間中的接近程度來表示。

因此，我們想要查看的是對象向量之間的距離。

這些向量表示（嵌入）通常是根據輸入數據和任務通過訓練模型創建的。

Word2Vec、GLoVE、USE 等是從文本數據生成嵌入的流行模型，而像 VGG 這樣的 CNN 模型通常用於創建圖像嵌入。

我們之前提到，我們通過計算對象向量之間的距離來發現對象之間的相似性。

我們可以根據最適合我們問題的距離度量來計算向量空間中這些向量之間的距離。

機器學習中常用的一些距離度量包括：

歐幾里德距離度量
曼哈頓距離度量
餘弦距離度量
切比雪夫距離度量。

下圖將幫助我們理解每種方法背後的原理。

下面是關於這四種常見的距離度量方法的介紹：

1. 歐幾里德距離度量（Euclidean Distance）

歐幾里德距離是最常見的距離度量方法之一，用於測量歐幾里德空間中兩個點之間的直線距離。對於二維空間中的兩個點 𝑃(𝑥1,𝑦1)P(x1,y1) 和 𝑄(𝑥2,𝑦2)Q(x2,y2)，歐幾里德距離可以表示爲：

對於多維空間中的點，歐幾里德距離的計算方式類似，即每個座標的差的平方和的平方根。

2. 曼哈頓距離度量（Manhattan Distance）

曼哈頓距離又稱爲城市街區距離，它是從一個點到另一個點沿着網格線的距離總和。在二維空間中，曼哈頓距離可以表示爲兩點座標差的絕對值之和：

在多維空間中，曼哈頓距離的計算方式類似，即每個座標的差的絕對值之和。

3. 餘弦距離度量（Cosine Distance）

餘弦距離是一種用於測量兩個向量方向的相似性的度量方法，而不考慮它們的大小。對於兩個向量 𝑢u 和 𝑣v，餘弦距離可以表示爲它們的夾角的餘弦值的補數：

4. 切比雪夫距離度量（Chebyshev Distance）

切比雪夫距離是在數學中定義的一種度量方法，用於衡量兩個點之間的最大距離。在二維空間中，切比雪夫距離可以表示爲兩點座標差的最大絕對值：

在多維空間中，切比雪夫距離的計算方式類似，即每個座標的差的最大絕對值。

這些距離度量方法各自適用於不同的情況和任務，根據具體的需求選擇合適的度量方法非常重要。

4.7 如何選擇嵌入模型

常見的類Embbedding模型

檢索用Embbedding
重排序用Embbedding

Embbedding模型在RAG中的應用場景

知識庫存入向量數據庫之前，需要使用Embbedding模型
用戶提問時的問題，需要使用使用Embbedding模型
檢索完成之後重排序的時候，需要 Rank Embbedding模型

在哪裏找到合適Embbedding模型？

MTEB被公認爲是目前業界最全面、最權威的中文語義向量評測基準之一，涵蓋了分類、聚類、檢索、排序、文本相似度、STS等6個經典任務，共計35個數據集，爲深度測試中文語義向量的全面性和可靠性提供了可靠的實驗平臺。

通過這個網站可以看到所有開源的語義向量模型：

https://huggingface.co/spaces/mteb/leaderboard

Embbedding模型選型

說了那麼多的模型，怎麼選擇一個好的Embbedding模型，它是由很多個維度可以選擇的，首先要考慮幾個公共的維度，讓後還需要考慮場景，因爲不同的Embbedding模型訓練的語料不一樣，業務數據與Embbedding模型訓練的語料匹配度越高，效果越佳。

Retrieval Average： NDCG是衡量檢索系統性能的常用指標。 NDCG 較高表示模型能夠更好地在檢索結果列表中將相關項目排名靠前。
模型大小：模型的大小（以 GB 爲單位）。它給出了運行模型所需的計算資源的概念。雖然檢索性能隨模型大小而變化，但值得注意的是，模型大小也會對延遲產生直接影響。在生產設置中，延遲與性能的權衡變得尤爲重要。
最大令牌數：可以壓縮爲單個嵌入的令牌數。您通常不想放置超過一個文本段落（~100 個代幣) 到單個嵌入中。因此，即使模型的最大令牌數爲 512，也應該綽綽有餘。
Embbedding維度：嵌入向量的長度。較小的嵌入可提供更快的推理，並且存儲效率更高，而更多的維度可以捕獲數據中的細微細節和關係。最終，我們希望在捕獲數據的複雜性和運營效率之間取得良好的權衡。
支持的語言 (Languages): 中文 (zh)，英文 (en) 等

4.8 嵌入是如何生成的？

方式一：模型託管方式生成嵌入：比如一些MaaS(模型即服務)服務廠商會提供嵌入模型的API，比如OpenAI的text-embedding-3-large

方式一：自己部署模型生成嵌入：另外一種是使用開源的嵌入模型，然後通過使用GPU服務器運行起來，自己封裝接口。

自己部署的一種流行的方法是通過開源庫sentence-transformers，可通過Hugging Face 模型中心或直接從源代碼庫獲取

方式一：模型託管方式生成嵌入

百度大模型平臺提供的Embbedding就有（Embedding-V1，bge-large-zh，bge-large-en）重排序（bce-reranker-base），可以使用API訪問。

Embedding-V1是基於百度文心大模型技術的文本表示模型，將文本轉化爲用數值表示的向量形式，用於文本檢索、信息推薦、知識挖掘等場景。

bge-large-zh、bge-large-en是由智源研究院研發的中文和英文版文本表示模型，可將任意文本映射爲低維稠密向量，以用於檢索、分類、聚類或語義匹配等任務，並可支持爲大模型調用外部知識。

tao-8k是由Huggingface開發者amu研發並開源的長文本向量表示模型，支持8k上下文長度，模型效果在C-MTEB上居前列，是當前最優的中文長文本embeddings模型之一。

下面是通過api，訪問模型託管生成嵌入的一個例子

curl -X POST https://xxx -d '{ "input": ["推薦一些美食","給我講個故事"]}'
輸入文本以獲取embeddings說明：
（1）文本數量不超過16
（2）每個文本token數不超過512且長度不超過2000個字符
（3）輸入文本不能爲空，如果爲空會報錯

輸入是一個文本list,返回數據核心就是一個數組，每個數組裏是每個文本對應的embedding，是一個float類型的數組。

這裏需要注意的是，不同的模型它的輸入要求是不一樣的,在調用模型的時候需要根據模型api的要求處理輸入的參數。

[
    {
      "object": "embedding",
      "embedding": [
        0.018314670771360397,
        0.00942440889775753,
        ...（共384個float64）
        -0.36294862627983093
      ],
      "index": 0
    }
 ]

重排序模型bce-reranker-base_v1是由網易有道開發的跨語種語義表徵算法模型，擅長優化語義搜索結果和語義相關順序精排，支持中英日韓四門語言，覆蓋常見業務領域，支持長package rerank(512~32k)。bce-reranker-base_v1是模型的一個版本。

它的輸入是一個提問和一些文檔塊，這些塊（來源於從向量數據庫中檢索出來的塊），這些塊與query有一定的相關度。

curl -X POST http://xxxx -d '{"query": "上海天氣","documents":["上海氣候", "北京美食"]}

它的返回結果和前面說的檢索用的Embedding模型有些區別，它是是返回query和各個documents之間的一個相關度評分，分數越高，相關性越強，通常我們準備10個塊給模型，我們拿到10個塊的分數，然後按分數由高到底排序，最後找出Top N個相關度最高的塊給大模型。目的就是優中選優，跟搜索推薦原理一模一樣。

 [
    {
      "document": "上海氣候",
      "relevance_score": 0.7059729695320129,
      "index": 0
    },
    {
      "document": "北京美食",
      "relevance_score": 0.4241394102573395,
      "index": 1
    }
]

開源的嵌入模型

使用OpenAI的text-embedding-3-large創建向量

下面的代碼，定義了一個名爲 get_embeddings 的函數，它使用 OpenAI API 來生成文本的嵌入表示。

以下是對函數和其中註釋的中文翻譯：


def get_embeddings(docs: List[str], model: str="text-embedding-3-large") -> List[List[float]]:
    """
    使用 OpenAI API 生成嵌入。
    參數：
        docs (List[str]): 要生成嵌入的文本列表
        model (str, optional): 模型名稱。默認爲 "text-embedding-3-large"。
    返回：
        List[float]: 嵌入的數組
    """
    # 替換換行符，它們可能會對性能產生負面影響
    docs = [doc.replace("\n", " ") for doc in docs]
    # 調用 OpenAI API 來獲取嵌入
    response = openai_client.embeddings.create(input=docs, model=model)
    # 提取響應中的嵌入數據
    response = [r.embedding for r in response.data]
    # 返回嵌入數據
    return response
```

也可以使用 Hugging Face Model Hub 上的開源模型，HuggingFace上有很多開源的模型，可以供選擇。


from typing import List
from transformers import AutoModel, AutoTokenizer
import torch
# 用戶查詢中要追加的指令，以改善檢索結果
RETRIEVAL_INSTRUCT = "Represent this sentence for searching relevant passages:"
# 檢查 CUDA（GPU 支持）是否可用，並相應地設置設備
device = torch.device("cuda") if torch.cuda.is_available() else torch.device("cpu")
# 從 Hugging Face 加載 UAE-Large-V1 模型
model = AutoModel.from_pretrained('WhereIsAI/UAE-Large-V1').to(device)
# 加載與 UAE-Large-V1 模型關聯的分詞器
tokenizer = AutoTokenizer.from_pretrained('WhereIsAI/UAE-Large-V1')
# 裝飾器，用於禁用梯度計算
@torch.no_grad()
def get_embeddings(docs: List[str], input_type: str) -> List[List[float]]:
    """
    使用 UAE-Large-V1 模型獲取嵌入。
    參數：
        docs (List[str]): 要嵌入的文本列表
        input_type (str): 要嵌入的輸入類型。可以是 "document" 或 "query"。
    返回：
        List[List[float]]: 嵌入的數組
    """
    # 如果是查詢類型，則在查詢前追加檢索指令
    if input_type == "query":
        docs = ["{}{}".format(RETRIEVAL_INSTRUCT, q) for q in docs]
    # 對輸入文本進行分詞
    inputs = tokenizer(docs, padding=True, truncation=True, return_tensors='pt', max_length=512).to(device)
    # 將分詞後的輸入傳遞給模型，並獲取最後一個隱藏狀態
    last_hidden_state = model(**inputs, return_dict=True).last_hidden_state
    # 從最後一個隱藏狀態中提取嵌入
    embeddings = last_hidden_state[:, 0]
    # 返回嵌入，從 GPU 轉移到 CPU 並轉換爲 NumPy 數組
    return embeddings.cpu().numpy()
```

5. 實戰：基於 Langchain+私有模型，構建一個生成級RAG 聊天機器人

LangChain 是一個功能強大的框架，幫助開發者利用 LLM 快速構建出適應各種場景的智能應用。

它提供了多種組件，可以幫助我們構建問答應用，以及更一般的 RAG 應用。

爲了讓大家對RAG的基本架構有一個初步認識，咱們先給大家一個實戰代碼，讓大家能直觀的瞭解最最基礎的RAG架構，在咱們後續的教程和項目都是工業化的，包括更加複雜的分塊處理，生成級向量數據庫，以及多階段檢索，多模塊的RAG架構。

咱們現在開始通過RAG基於一個PDF中的內容去聊天。

這是一份AIGC的行業研究報告，有圖，有表，有文字，作爲我們的實驗對象，目標是通過RAG基於這個PDF中的內容去聊天。

5.1 設置環境和依賴

使用python pip 來安裝以下依賴，在這個教程裏咱們爲了展示最基本的能力，所有內容都是採用本地化模型或者嵌入式的向量數據，方便大家快速上手。


use python 3.10
pip install  fastembed==0.1.3 chromadb==0.4.22 langchain==0.1.8  wikipedia==1.4.0 ollama

5.2 初始化LLM

我們將首先初始化本地大型語言模型，我們使用Ollama在本地運行該模型。

我們將使用流行的LangChain庫將所有內容連接在一起。

from langchain_community.llms import Ollama
from langchain.callbacks.manager import CallbackManager
from langchain.callbacks.streaming_stdout import StreamingStdOutCallbackHandler

llm = Ollama(
    model="llama3",
    callback_manager=CallbackManager([StreamingStdOutCallbackHandler()]),
)

我們可以通過運行以下命令來檢查它們是否全部連接在一起：

llm.invoke("英偉達公佈2024二季度營收多少億美元?")

輸出

According to my knowledge, InVite (英偉達) is a Chinese company that specializes in electric vehicles. As of now, I couldn't find any reliable sources confirming their 2024 Q2 revenue.

However, if you're interested in knowing the previous quarterly or annual revenues for InVite, I can try searching for those. 📊

Please let me know what specific information you're looking for, and I'll do my best to help! 😊

LLM不知道答案，返回了幻覺答案，即它會想出一些看似合理但完全編造的東西。

在這種情況下，它不如直接告訴它不知道，實際上會更好。

5.3 增強生成

我們可以幫助 LLM 的一種方法是創建一個新的提示，在其中手動粘貼整個頁面的內容（我們稱之爲context），並要求 LLM 使用該上下文來回答問題。

這是可行的，但並不是那麼有效——儘管我們不存在必須關心token費用的問題，因爲我們使用的是本地模型，但 LLM 往往需要更長的時間才能回答更長的問題。因此，我們希望識別頁面中可能有問題答案的部分，然後僅將該部分粘貼到提示中。

讓我們看看如果我們手動增強提示（即增強生成），LLM將如何回答這個問題！

在LangChain中我們可以使用以下代碼構造一個提示,這裏我們使用了Langchain的提示詞模板：

from langchain.prompts import PromptTemplate

template = """你是一個機器人，使用提供的上下文來回答問題。如果你不知道答案，只需簡單地說明你不知道。.

{context}

Question: {input}"""

prompt = PromptTemplate(
    template=template, input_variables=["context", "input"]
)

然後我們可以像這樣填充提示：

prompt.format(
    context="英偉達公佈2024財年第二財季季報。二季度營收135.07億美元",
    input="英偉達公佈2024二季度營收多少億美元?"
)

輸出

'你是一個機器人，使用提供的上下文來回答問題。如果你不知道答案，只需簡單地說明你不知道。.\n\n英偉達公佈2024財年第二財季季報。二季度營收135.07億美元\n\nQuestion: 英偉達公佈2024二季度營收多少億美元?'

然後我們可以將該提示輸入 LLM，如下所示：

llm.invoke(
    prompt.format(
        context="英偉達公佈2024財年第二財季季報。二季度營收135.07億美元",
        input="英偉達公佈2024二季度營收多少億美元?"
    )
)

輸出

根據上下文，英偉達公佈的2024二季度營收是135.07億美元。

就這樣，現在我們有了正確的答案。

但到目前爲止，我們的解決方案要求我們找到適當的信息並將其LLM - 如果我們能夠自動化該過程的這一部分，那就更好了。

5.4 生成嵌入

所以，接下來，需要的文件切割成小段落，然後把他們嵌入，轉化爲數字含義，最後把他們加載進我們向量庫。

讓我們首先創建 PDF頁面的嵌入。

我們可以使用以下方法檢索頁面PyPDFLoader：

from langchain.text_splitter import RecursiveCharacterTextSplitter

from langchain_community.document_loaders import PyPDFLoader

loader = PyPDFLoader("AIGC行業深度報告(11).pdf")
docs = loader.load()
print(len(docs))
print(docs[1].page_content)

這給我們返回了一個Document包含整個頁面的 LangChain。正如我們上面所討論的，我們將把頁面分成塊。實現此目的的一種方法是使用RecursiveCharacterTextSplitter遍歷文本並提取一定長度的塊，每個塊之間可以選擇重疊：

text_splitter = RecursiveCharacterTextSplitter(
    chunk_size = 1000,
    chunk_overlap  = 200,
    length_function = len,
    is_separator_regex = False,
)

data = text_splitter.split_documents(docs)
data[:3]

輸出

[Document(page_content='華西計算機團隊\n2023年10月9日華爲算力分拆 : 全球AI算力的第二極\n請仔細閱讀在本報告尾部的重要法律聲明\n僅供機構投資者使用\n證券研究報告 |行業深度研究報告\n分析師：劉澤晶\nSAC NO：S1120520020002\n郵箱：[email protected] 行業深度報告 (11)', metadata={'source': 'AIGC行業深度報告(11).pdf', 'page': 0}),
 Document(page_content='核心邏輯 :\n\uf075全面對標英偉達，華爲開啓國產自主可控新徵程 。我們認爲英偉達作爲全球 AI算力芯片龍頭坐擁三大法寶，分別是高性能芯片、其中 IC設計\n是重點， CUDA 架構、助力 AI加速計算生態， Nvlink 、NVSwitch 助力芯片快速互聯互通與 InfiniBand 配合組網技術實現高效互聯互通；而華\n爲作爲國產計算之光全面對標英偉達，在算力方面， 昇騰910芯片單卡算力已經可以與英偉達 A100 相媲美；統一達芬奇架構助力 AI計算引擎；\nHCCS 互聯技術，實現卡間高速互聯 。\n\uf075華爲構築世界 AI算力第二選擇 : 全連接大會上，華爲發佈多款 AI產品，爲世界 AI算力第二選擇。 華爲Atlas 900 SuperCluster 、全新的華爲\n星河AI智算交換機亮相，打開國產算力集羣想象空間，同時 發佈“三力四總線”，打造智能世界數字基礎大設施，此外發布星河 AI網絡解決\n方案，以高運力釋放 AI時代的高算力；軟件方面，華爲攜手基礎軟硬件創新，開啓國產 AI生態；華爲鯤鵬、昇騰、 AI助力國產千行百業數字\n化升級，包括金融、智能製造、工業、教育、醫療等方面。\n\uf075爲領銜演繹國產 AI計算產業崛起 : 我們認爲華爲 AI計算產業的核心在於芯片的自主可控，其中以鯤鵬和昇騰爲主導的海思芯片尤爲重要，因此\n與之相關的國產集成電路產業突圍尤爲重要，其中重中之重是 EDA 、光刻、代工產業； AI與信創雙輪驅動，國產服務器需求火爆， AI 服務\n器中的主要元器件包括 CPU 、GPU 板組、內存、硬盤、網絡接口卡組成，配合電源、主板、機箱、散熱系統等基礎硬件以提供信息服務，\n計算服務器基礎硬件供應商和華爲生態夥伴也將迎來發展機遇；算力組網方面，華爲有望帶動相關產品快速放量，其中包括國產 AI服務器、\n交換機、光模塊等產品，此外，在算網的趨勢下，網絡可視化將迎來黃金髮展週期。\n\uf075投資建議: 受益標的： EDA：華大九天、概倫電子、廣立微 等；光刻： 福晶科技、奧普光電、蘇大維格、美埃科技、騰景科技 等；PCB：滬\n電股份、勝宏科技 等；內存接口： 瀾起科技、聚辰股份 等；連接器： 華豐科技、鼎通科技 等；BIOS ：卓易信息 等；電源： 傑華特、歐陸通、', metadata={'source': 'AIGC行業深度報告(11).pdf', 'page': 1}),
 Document(page_content='交換機、光模塊等產品，此外，在算網的趨勢下，網絡可視化將迎來黃金髮展週期。\n\uf075投資建議: 受益標的： EDA：華大九天、概倫電子、廣立微 等；光刻： 福晶科技、奧普光電、蘇大維格、美埃科技、騰景科技 等；PCB：滬\n電股份、勝宏科技 等；內存接口： 瀾起科技、聚辰股份 等；連接器： 華豐科技、鼎通科技 等；BIOS ：卓易信息 等；電源： 傑華特、歐陸通、\n中國長城 等；服務器： 拓維信息、神州數碼、天源迪科、四川長虹、高新發展 等；光模塊： 天孚通信，劍橋科技、太辰光、中際旭創 等；網\n絡可視化： 恆爲科技、浩瀚深度、中新賽克 等；操作系統： 潤和軟件、測繪股份、中國 軟件、麒麟信安、誠邁科技 等；技術開發： 軟通動力、\n常山北明 等；傳統應用： 海量數據、超圖軟件、賽意信息 等；AI應用： 潤達醫療、雲鼎科技、梅安森、萬達信息、龍軟科技、金山辦公、夢\n網科技 等。\n\uf075風險提示 : 核心技術水平升級不及預期的風險、 AI倫理風險、政策推進不及預期的風險、中美貿易摩擦升級的風險。2', metadata={'source': 'AIGC行業深度報告(11).pdf', 'page': 1})]

5.5 生成並存儲嵌入

接下來，我們將使用 FastEmbedEmbeddings爲每個文本塊生成嵌入，然後將嵌入和文本存儲在 ChromaDB 中。

from langchain.vectorstores import Chroma
#from langchain.embeddings import OpenAIEmbeddings
from langchain_community.embeddings.fastembed import FastEmbedEmbeddings

embeddings = FastEmbedEmbeddings(model_name="BAAI/bge-base-en-v1.5")

store = Chroma.from_documents(
    data, 
    embeddings, 
    ids = [f"{item.metadata['source']}-{index}" for index, item in enumerate(data)],
    collection_name="AIGC-report-Embeddings", 
persist_directory='db',
)
store.persist()

本地會生成一個db文件夾

5.6 查詢嵌入

RAG的第二大部分是檢索與生成，依據問題，找出相關度最高的內容，將其融入到提示信息中並生成回覆。

現在我們要查詢嵌入。由於某種我還沒有完全弄清楚的原因，相似性搜索不會返回正確的塊，除非我增加的值k。

我嘗試了一些不同的嵌入算法，但它似乎並沒有改變結果，所以我們現在將解決這個問題。

result = store.similarity_search(
    query="英偉達公佈2024二季度營收多少億美元?",
    k=10
)
[doc.page_content for doc in result]

輸出

['1.1 全球龍頭英偉達業績持續高度景氣，印證全球 AI產業趨勢\n\uf075英偉達二季度業績持續超預期 ，印證AI景氣度： 美東時間 8月23日，英偉達公佈 2024 財年第二財季季報 。二季度營收 135.07億美元 ，同\n比增長 101%,遠超市場預期的指引區間 107.8億到112.2億美元 ，相較於華爾街預期 水平 高22%-29%以上 。業績指引方面 ，英偉達預計 ，\n本季度 、即2024 財年第三財季營業收入爲 160億美元 ，正負浮動 2%，相當於指引範圍在 156.8億到163.2億美元之間 。以160億美元計\n算，英偉達預期三季度營收將同比增長 170%，連續兩個季度翻倍增長 ，高於市場預期 。\n\uf075AI芯片所在業務同環比均翻倍激增較市場預期高近 30%，遊戲業務同比重回增長 :AI對英偉達業績的貢獻突出 。包括AI顯卡在內的英偉\n達核心業務數據中心同樣收入翻倍激增 ，二季度數據中心營業收入爲 103.2億美元 ，同比增長 171%，環比增長 141%；二季度遊戲營收\n24.9億美元 ，同比增長 22%，環比增長 11%，英偉達稱 ，數據中心收入主要來自雲服務商和大型消費類互聯網公司 。基於Hopper 和A\nmpere 架構GPU 的英偉達 HGX 平臺之所以強勁需求 ，主要源於開發生成式 AI和大語言模型的推動 。\n5 資料來源：techpowerup ，Bloomberg ，英偉達官網 ，英偉達2023財年年報， 新浪，華西證券 研究所產品實現雲、邊、端全面佈局\n雲端\n•GPU 加速雲計算（ 在雲端完\n成計算 ）\n•Omniverse Cloud ：自部署雲\n容器 、託管服務終端\n•遊戲： 驅動器、 Reflex 、G-SYNC 顯示器\n•可視化： 虛擬工作站 、NVIDIA RTXDI 光\n線追蹤等\n•智能駕駛： 艙內智能服務軟件、地圖軟件、\n輔助駕駛平臺等邊緣計算\n•Jetson 嵌入式系統： Orin 系列 、\nXavier 系列 、TX2系列 、Nano （在\n數據源或數據源附近完成計算 ）',
 '目錄\n301 全面對標英偉達，開啓國產自主可控新徵程\n02 華爲領銜演繹國產 AI計算產業崛起\n03  投資建議 : 梳理AIGC 相關受益廠商\n04  風險提示',
.....................
']

數據太多省略部分，但是可以看到第一個塊已經包含正確的數據：英偉達公佈 2024 財年第二財季季報。

二季度營收 135.07億美元

5.7 檢索增強生成

我們現在已經準備好進行檢索增強生成的所有部件，因此最後一步是將它們全部連接在一起。

用LangChain的術語來說，我們需要創建一條將向量存儲與LLM相結合的鏈。

我們可以使用以下代碼來做到這一點：

from langchain.chains.combine_documents import create_stuff_documents_chain
from langchain.chains import create_retrieval_chain

retriever = store.as_retriever(search_kwargs={
      'k': 10
})
combine_docs_chain = create_stuff_documents_chain(llm, prompt)
chain = create_retrieval_chain(retriever, combine_docs_chain)

然後我們可以這樣調用：

result = chain.invoke({
  "input": "英偉達公佈2024二季度營收多少億美元?"
})

輸出

According to the text, NVIDIA announced its 2024 second quarter revenue as $135.07 billion, with a year-over-year growth of 101%.

好了，正確的結果已經出來，我們從0一步步搭建起來一個基礎的RAG系統，是不是很神奇，

但是筆者在開發過程中會遇到PDF中的圖片，圖表無法友好解析的問題，包括工程化問題，這些會在咱們高級課程中體現。

6. 實戰：基於 Langchain+公有模型，構建一個生成級RAG 聊天機器人

下面我們將展示如何使用 Langchain+公有模型（ OpenAI 的 GPT 系列模型），構建一個生產級的 RAG 聊天機器人。

6.1 準備工作

安裝 Python：建議使用 Python 3.8 或更高版本，這是當前許多現代 Python 庫和框架的通用要求。
安裝依賴：使用 pip 安裝 LangChain 及其相關依賴pip install --upgrade --quiet langchain langchain-community langchainhub langchain-openai
獲取 OpenAI 密鑰：這裏選擇使用 OpenAI 的 GPT 系列模型作爲我們的 LLM。所以需要註冊一個 OpenAI 賬號，然後創建一個 API 密鑰。
註冊 LangSmith (可選)：使用 LangSmith，可以對 LangChain 的調用進行跟蹤和分析，強烈建議使用。

6.2 加載配置

項目中需要用到的配置信息，推薦使用 .env 文件進行加載，同時記得在 .gitignore 中排除這個文件，避免將敏感信息泄霩。

# .env
OPENAI_API_KEY="sk-xxx"
# OPENAI_API_BASE="https://api.openai.com/v1"

# LANGCHAIN_TRACING_V2=true
# LANGCHAIN_API_KEY=xxx

接着在項目中加載配置信息：

from dotenv import load_dotenv
dotenv.load_dotenv()

6.3 索引：加載數據

接下來，需要的文件切割成小段落，然後把他們嵌入，轉化爲數字含義，最後把他們加載進我們向量庫。

LangChain 提供了多種加載器，可以幫助我們從不同的數據源中加載數據，包括常見的 CSV、HTML、JSON、Markdown、PDF等。

基本上你能想到的數據源（甚至語雀）都有相應的加載器，詳細的加載器列表可以參考官方文檔。

下面我們以加載一個簡單的 PDF 文件爲例：

pip install pypdf
from langchain_community.document_loaders import PyPDFLoader

loader = PyPDFLoader("https://arxiv.org/pdf/2402.16480.pdf")
docs = loader.load()
print(len(docs))
print(docs[0].page_content)

在上面的代碼中，我們使用了 PyPDFLoader 來加載一個 PDF 文件，然後打印出了文檔的長度和第一頁的內容。

PyPDFLoader 默認不處理圖片，如果需要提取圖片，可以藉助 rapidocr-onnxruntime 庫：

pip install rapidocr-onnxruntime
loader = PyPDFLoader("https://arxiv.org/pdf/2402.16480.pdf", extract_images=True)

除了適用於常見格式的 PyPDFLoader，LangChain 還提供了其他針對不同類型 PDF 文件的加載器，比如 MathpixPDFLoader、UnstructuredPDFLoader等具體實現，可以根據實際情況選擇，詳細介紹可以參考官方文檔。

6.4 索引：切分數據

切分器是將文檔切分成更小的片段，以便於更好地匹配用戶問題，同時也可以適應模型的有限上下文窗口。

LangChain 提供了多種切分器，包括基於段落、句子、詞等不同粒度的切分器，詳細的切分器列表可以參考官方文檔。

下面我們以切分器爲例，展示如何使用 RecursiveCharacterTextSplitter 切分文檔：

from langchain_text_splitters import RecursiveCharacterTextSplitter

text_splitter = RecursiveCharacterTextSplitter(
    chunk_size=1000, chunk_overlap=200, add_start_index=True
)
splits = text_splitter.split_documents(docs)
print(len(splits))
print(splits[0].page_content)
print(splits[0].metadata)

在上面的代碼中，我們使用了 RecursiveCharacterTextSplitter 來切分文檔，然後打印出了切分後的切片數量、第一個切片的內容和元數據。

在使用 RecursiveCharacterTextSplitter 時，我們可以使用 chunk_size 來控制切分的粒度，chunk_overlap 來控制切片的重疊，重疊的部分可以保證切片之間的上下文連貫性。

此外，我們還可以使用 add_start_index 來控制是否在切片的元數據中添加起始索引。

這裏推薦一個網站 https://chunkviz.up.railway.app/，可以幫助我們直觀地理解切分的效果。

如果要使用 RecursiveCharacterTextSplitter 來切分代碼，可以通過結合 Language 類來實現：

from langchain_text_splitters import (
    Language,
    RecursiveCharacterTextSplitter,
)

python_splitter = RecursiveCharacterTextSplitter.from_language(
    language=Language.PYTHON, chunk_size=50, chunk_overlap=0
)

除了適用於一般文本的 RecursiveCharacterTextSplitter，LangChain 還提供了其他針對不同類型文檔或者不同切分方式的切分器，比如：

MarkdownHeaderTextSplitter 用於通過指定標題切分 Markdown 文件
RecursiveJsonSplitter 用於切分 JSON 文件
CharacterTextSplitter 用於通過指定分隔符切分文本

關於文檔切分器的詳細介紹可以參考官方文檔。

6.5 索引：生成嵌入

嵌入器是將文檔切片轉換成向量（embeddings），以便存儲到向量數據庫（VectorStore）中。

Embeddings 的本質是將文本映射到一個高維空間中的向量，使得語義相似的文本在空間中的距離更近。

LangChain 提供了多種嵌入器，包括 OpenAI, Cohere, Hugging Face 等提供的多種模型，詳細的嵌入器列表可以參考官方文檔。

下面我們以嵌入器爲例，展示如何使用 OpenAIEmbeddings 嵌入文檔切片：

from langchain_openai import OpenAIEmbeddings

embedding = OpenAIEmbeddings()
embedded_query = embedding.embed_query("What was the name mentioned in the conversation?")
print(embedded_query[:5])
[0.005384807424727807, -0.0005522561790177147, 0.03896066510130955, -0.002939867294003909, -0.008987877434176603]

在上面的代碼中，我們使用了 OpenAIEmbeddings 來嵌入查詢，然後打印出了嵌入後的前 5 個元素。

LangChain 中的 Embeddings 接口提供了 embed_query 和 embed_documents 兩個方法，分別用於嵌入查詢和文檔切片。因爲不同的嵌入器可能會針對文檔和查詢提供不同的實現。

6.6 索引：存儲嵌入

存儲器是將嵌入後的 embeddings 存儲到向量數據庫（VectorStore）中，以便在檢索時能夠快速找到相關的數據。

使用 embeddings 和向量數據庫可以實現語義匹配，這也是 RAG 和傳統關鍵詞匹配的區別。最常見的相似度計算方法是使用餘弦相似度。

LangChain 提供了多種存儲器，常見開源可本地部署的有 Chroma、Faiss、Lance 等，詳細的存儲器列表可以參考官方文檔。

下面我們以存儲器爲例，展示如何使用 ChromaVectorStore 存儲嵌入後的 embeddings：

from langchainhub.vectorstores import ChromaVectorStore

vectorstore = Chroma.from_documents(documents=splits, embedding=embedding)
query = "如何在開源項目中使用 ChatGPT ?"
docs = vectorstore.similarity_search(query)
print(docs[0].page_content)

在上面的代碼中，我們使用了 Chroma 來存儲嵌入後的 embeddings，然後使用 similarity_search 方法通過查詢文本檢索數據。這裏需要留意的是，雖然原始的 PDF 文檔是英文，而代碼中的查詢是中文，但依然可以查詢到相關文檔，這就是語義搜索的魅力。除了 similarity_search，我們還可以使用 similarity_search_by_vector 直接通過向量檢索數據。

6.7 查詢檢索

RAG的第二大部分是檢索與生成，依據問題，找出相關度最高的內容，將其融入到提示信息中並生成回覆。

檢索器根據用戶輸入，輸出相關的文檔列表。

LangChain 內置了多種檢索器，最常見和簡單的是基於向量數據庫的檢索器，詳細的檢索器列表可以參考官方文檔。不同的檢索器適合不同的場景，可以參照官方提供的對比表格進行選擇：

名稱	索引類型	使用LLM	使用時機	描述
Vectorstore	向量存儲	否	如果你剛開始，正在尋找快速簡單的方法。	這是獲取開始的最簡單方法。它涉及爲每個文本創建嵌入。
ParentDocument	向量存儲 + 文檔存儲	否	如果你的頁面有很多更小的獨立信息塊，它們最好單獨索引，但最好一起檢索。	這涉及爲每個文檔索引多個塊。然後你在嵌入空間找到最相似的塊，但檢索整個父文檔並返回（而不是單個塊）。
Multi Vector	向量存儲 + 文檔存儲	有時在索引期間	如果你能夠從文檔中提取出你認爲比文本本身更有索引價值的信息。	這涉及爲每個文檔創建多個向量。每個向量的創建方式有很多種 - 例如包括文本的摘要和假設性問題。
Self Query	向量存儲	是	如果用戶提出的問題更適合根據元數據而不是與文本的相似性來檢索文檔。	這使用LLM將用戶輸入轉換爲兩件事：（1）用於語義查找的字符串，（2）與之相關的元數據過濾器。這很有用，因爲很多時候問題是關於文檔的元數據（而不是內容本身）。
Contextual Compression	任何	有時	如果你發現檢索到的文檔包含太多無關信息，分散了LLM的注意力。	這在另一個檢索器之上放置了一個後處理步驟，只提取檢索到的文檔中最相關的信息。這可以使用嵌入或LLM來完成。
Time-Weighted Vectorstore	向量存儲	否	如果你有關聯時間戳的文檔，並希望檢索最新的文檔。	這根據語義相似性（如正常向量檢索）和最近性（查看索引文檔的時間戳）來檢索文檔。
Multi-Query Retriever	任何	是	如果用戶提出的問題複雜，需要多個獨立的信息塊來回答。	這使用LLM從原始問題生成多個查詢。當原始問題需要關於多個主題的信息塊才能得到正確回答時，這很有用。通過生成多個查詢，我們可以爲每個查詢獲取文檔。
Ensemble	任何	否	如果你有多重檢索方法，並希望嘗試將它們結合。	這從多個檢索器獲取文檔，然後將它們組合。
Long-Context Reorder	任何	否	如果你使用長上下文模型，並發現它沒有關注檢索文檔中間的信息。	這從底層檢索器獲取文檔，然後重新排序，使最相似的文檔位於開始和結束處。這很有用，因爲已經顯示，對於更長的上下文模型，它們有時不會關注上下文窗口中間的信息。

除了內置檢索器，LangChain 還支持集成多種外部檢索器，詳細列表可以參考官方文檔。

此外，LangChain 還支持自定義檢索器，示例代碼可以參考官方文檔。

下面我們展示如何使用 VectorStoreRetriever 檢索數據：

retriever = vectorstore.as_retriever(search_type="similarity", search_kwargs={"k": 6})
query = "如何在開源項目中使用 ChatGPT ?"
docs = retriever.invoke(query)
print(len(docs))
print(docs[0].page_content)

在上面的代碼中，我們基於 vectorstore 創建了一個檢索器，並且指定 search_type="similarity" 表示使用相似度檢索，，search_kwargs={"k": 6} 表示最多返回 6 個結果，然後調用 invoke 方法檢索數據。

生成

生成就是基於用戶的問題和檢索到的數據，拼裝進提示，然後調用 LLM 生成答案。

下面我們展示如何使用 OpenAI 的 gpt-3.5-turbo 模型構造 chain 生成答案：

from langchain_openai import ChatOpenAI
from langchain import hub
from langchain_core.output_parsers import StrOutputParser
from langchain_core.runnables import RunnablePassthrough

# 從 Hub 中加載 RAG Prompt
prompt = hub.pull("rlm/rag-prompt")
# 使用 OpenAI 的 gpt-3.5-turbo 模型
llm = ChatOpenAI(model_name="gpt-3.5-turbo", temperature=0)

# 格式化文檔
def format_docs(docs):
    return "\n\n".join(doc.page_content for doc in docs)

# 構建 chain
rag_chain = (
    {"context": retriever | format_docs, "question": RunnablePassthrough()}
    | prompt
    | llm
    | StrOutputParser()
)

# 以流的方式生成答案
for chunk in rag_chain.stream("What is Task Decomposition?"):
    print(chunk, end="", flush=True)

在上面的代碼中，我們使用了 ChatOpenAI 來加載 OpenAI 的 gpt-3.5-turbo 模型，然後構建了一個 chain，其中包含了檢索、格式化、提示和生成等步驟。最後以流的方式生成答案。代碼中涉及到的關鍵概念有：

hub.pull：從 Hub 中加載 RAG Prompt，Hub 是 LangChain 提供的一箇中心化的模型倉庫，可以方便地獲取和分享模型。
|：管道操作符，用於連接多個 Runnable。基於 LangChain Expression Language (LCEL) 的語法，可以方便地構建複雜的 chain，類似於 Unix 管道。LCEL 提供了非常多的特性，包括異步、批量執行、併發執行、流式、重試和回退等，在我看來就是 LangChain 的精髓所在，詳細介紹可以參考官方文檔。
RunnablePassthrough：一個簡單的 Runnable，用於傳遞輸入
StrOutputParser：一個簡單的 OutputParser，用於將輸出轉換成字符串
stream：以流的方式生成答案

LangChain 針對 LLM 的調用提供了兩種不同的抽象：ChatModel 和 LLM。前者接收聊天消息列表返回單個聊天消息，比如我們上面代碼中使用的 ChatOpenAI；後者接收一個字符串返回一個字符串。這兩種抽象可以根據實際情況選擇，詳細對比和介紹可以參考官方文檔。

總結

好了，到這裏我們已經完成了一個簡單的 RAG 聊天機器人的構建，可以看出 LangChain 提供了非常多的組件和特性，從而幫助我們快速構建出適應各種場景的智能應用。

限於篇幅，這篇文章就先到這裏，在後續文章中我們將繼續深入探討搭建一個生產級 RAG 聊天機器人所需要的更多高級特性，比如多模型集成、多語言支持、多輪對話、實時更新等，敬請期待！

說在最後：有問題找老架構取經

毫無疑問，大模型架構師更有錢途，這個代表未來的架構。

前面講到，尼恩指導的那個一個成功案例，是一個9年經驗網易的小夥伴，拿到了一個年薪近80W的大模型架構offer，逆漲50%，那是在去年2023年的 5月。

驚天大逆襲：8年小夥20天時間提75W年薪offer，逆漲50%，祕訣在這

不到1年，小夥伴也在團隊站穩了腳跟，成爲了名副其實的大模型架構師。回想當時，尼恩本來是規劃指導小夥做通用架構師的（ JAVA 架構、K8S雲原生架構），當時候爲了他的錢途，尼恩也是壯着膽子，死馬當作活馬指導他改造爲大模型架構師。

沒想到，由於尼恩的大膽嘗試，小夥伴成了，相當於他不到1年時間，職業身價翻了1倍多，現在可以拿到年薪 200W的offer了。

應該來說，小夥伴大成，實現了真正的逆天改命。

既然有一個這麼成功的案例，尼恩能想到的，就是希望能幫助更多的社羣小夥伴，成長爲大模型架構師，也去逆天改命。

技術是相同的，架構也是。

這一次，尼恩團隊用積累了20年的深厚的架構功力，編寫一個《LLM大模型學習聖經》，幫助大家進行一次真正的AI架構穿透，幫助大家穿透AI架構。

尼恩架構團隊的大模型《LLM大模型學習聖經》是一個系列，初步的規劃包括下面的內容：

《LLM大模型學習聖經：從0到1喫透Transformer技術底座》
《LLM大模型學習聖經：從0到1精通RAG架構，基於LLM+RAG構建生產級企業知識庫》
《LLM大模型學習聖經：從0到1喫透大模型的頂級架構》

本文是第2篇，這一篇的作者是robin。後面的文章，尼恩團隊會持續迭代和更新。並且錄製配套視頻。

當然，除了大模型學習聖經，尼恩團隊，持續深耕技術，爲大家輸出更多，更深入的技術體系，思想體系。

多年來，用深厚的架構功力，把很多複雜的問題做清晰深入的穿透式、起底式的分析，寫了大量的技術聖經：

Netty 學習聖經：穿透Netty的內存池和對象池（那個超級難，很多人窮其一生都搞不懂），
DDD學習聖經：穿透 DDD的建模和落地，
Caffeine學習聖經：比如Caffeine的底層架構，
比如高性能葵花寶典
Thread Local 學習聖經
等等等等。

上面這些學習聖經，大家可以通過《技術自由圈》公衆號，找尼恩獲取。

大家深入閱讀和掌握上面這些學習聖經之後，一定內力猛漲。

所以，尼恩強烈建議大家去看看尼恩的這些核心內容。

另外，如果學好了之後，還是遇到職業難題，沒有面試機會，怎麼辦？

可以找尼恩來幫扶、領路。

尼恩已經指導了大量的就業困難的小夥伴上岸.

前段時間，幫助一個40歲+就業困難小夥伴拿到了一個年薪100W的offer，小夥伴實現了 逆天改命 。

技術自由的實現路徑：

實現你的架構自由：

《喫透8圖1模板，人人可以做架構》

《10Wqps評論中臺，如何架構？B站是這麼做的！！！》

《阿里二面：千萬級、億級數據，如何性能優化？教科書級答案來了》

《峯值21WQps、億級DAU，小遊戲《羊了個羊》是怎麼架構的？》

《100億級訂單怎麼調度，來一個大廠的極品方案》

《2個大廠 100億級超大流量紅包架構方案》

… 更多架構文章，正在添加中

精通RAG架構：從0到1，基於LLM+RAG構建生產級企業知識庫

精通RAG架構：從0到1，基於LLM+RAG構建生產級企業知識庫

尼恩：LLM大模型學習聖經PDF的起源

1. 大語言模型簡介

1.1 大語言模型簡介：探索AI的新邊疆

預訓練語言模型（PLM）：NLP的瑞士軍刀

大語言模型（LLM）：AI進化的里程碑

LLM與PLM：大小之間的質變

大語言模型的湧現能力：AI的新技能

大語言模型的關鍵技術：構建AI的基石

1.2 大語言模型特點

1. 具備湧現能力

2. 訓練數據大且難度大：

GPT-3（175B）：

PaLM（540B）：

LLaMA：

3. 模型參數量大

4. 生成的模型大

5. 訓練需要算力規模

1.3 大型語言模型四要素

1. 算力：AI的心臟

2. 算法：AI的大腦

3. 數據：AI的養料

4. 場景：AI的舞臺

1.4 大語言模型應用

1. 業務流程自動化

2. 促進個性化交互

3. 提升任務準確性

2. 檢索增強生成（RAG）

2.2 RAG是什麼？

2.2.1 RAG的誕生背景

2.2.1.1 LLM面臨的挑戰有哪些

2.2.1.12 RAG技術的解決的問題

2.2.1.3 長上下文處理能力會殺死RAG嗎？

2.2.3 RAG具備性價比

1. 預訓練：打造基石模型的挑戰

2. 微調：適配領域數據的策略

3. 提示工程：優化輸入的藝術

2.3 RAG技術概述與原理

RAG 概述

2.3 RAG系統的主要組件和工作流程

2.3.1 RAG系統的核心組件與工作流程

檢索引擎：數據的精準定位

增強引擎：上下文的深度融合

生成引擎：智能響應的構建

2.3.2 RAG工作流程的全景視圖

第一步，數據索引：構建檢索的基石

第二步，輸入查詢處理：理解並轉化用戶需求

第三步，搜索和排名：找到最相關的信息

第四步提示增強：豐富輸入，提升輸出

第五步，響應生成：構建最終答案

第六步，評估：持續優化的關鍵

2.3 RAG範式

2.3.1 第一階段，樸素RAG

2.3.2 第二階段，高級RAG

2.3.3 第三階段，模塊化RAG

新模塊

模塊化 RAG 的優勢

2.3.1 預檢索

索引

查詢操作

數據修改

2.3.2 檢索

搜索與排名

2.3.3 檢索後

重排序

過濾

2.3.4 生成

增強

定製化

3. 網絡爬蟲與數據採集

使用BeautifulSoup解析HTML

清理HTML

提取文本

去除多餘的空白和換行

返回處理後的文本

4. 向量數據庫與Embedding模型

4.1 爲什麼現在每個人都在談論矢量數據庫？

4.2 RAG 場景對向量數據庫的需求

4.3 如何選擇向量數據庫

方式一：模型託管方式生成嵌入

5. 實戰：基於 Langchain+私有模型，構建一個生成級RAG 聊天機器人

6. 實戰：基於 Langchain+公有模型，構建一個生成級RAG 聊天機器人

實現你的架構自由：

實現你的響應式自由：

實現你的網絡自由：

實現你的分佈式鎖自由：

實現你的王者組件自由：

實現你的面試題自由：