鍵.png)
使用NestJS和Prisma構(gòu)建REST API：身份驗(yàn)證
本文討論的 RAG 流水線起始于一個(gè)文本文檔語料庫 。我們不涉及此前搜集文本資料的步驟，把它們交給那些強(qiáng)大的開源數(shù)據(jù)加載器，它們能連接到各種來源，從 Youtube 到 Notion 都不在話下。
簡(jiǎn)單地說，標(biāo)準(zhǔn)的 RAG 案例包括以下步驟：
提示工程是改進(jìn) RAG 流水線的一種非常經(jīng)濟(jì)實(shí)惠的方法。你應(yīng)該查看 OpenAI 非常全面的提示工程指南。
顯然，雖然 OpenAI 是大語言模型（大語言模型）供應(yīng)商的市場(chǎng)領(lǐng)頭羊，但也有很多其他選擇，比如 Anthropic 的 Claude，最近流行的小型但功能強(qiáng)大的模型如 Mistral 的 Mixtral、微軟的 Phi-2，還有諸如 Llama2、OpenLLaMA、Falcon 等多種開源選擇。因此，你可以為你的 RAG 流水線挑選最合適的“大腦”。
接下來，我們將深入探討高級(jí) RAG 技術(shù)的綜述。這里展示了一個(gè)方案，描述了核心步驟和涉及的算法。為了保持方案的清晰可讀，我們省略了一些邏輯循環(huán)和復(fù)雜的多步驟智能體行為。
方案中的綠色部分代表我們將重點(diǎn)討論的核心 RAG 技術(shù)，而藍(lán)色部分則是文本。并非所有高級(jí) RAG 的想法都能輕松地在一張圖表中展示出來，例如，一些擴(kuò)展上下文的方法就被省略了——我們會(huì)在后面詳細(xì)討論。
我們需要?jiǎng)?chuàng)建一個(gè)向量索引，這個(gè)索引代表了我們文檔的內(nèi)容。然后在運(yùn)行時(shí)，我們要在所有這些向量與查詢向量之間尋找最小的余弦距離，以找到最接近的語義含義。
Transformer 模型的輸入序列長度是固定的。即便輸入上下文窗口較大，單個(gè)句子或幾個(gè)句子的向量通常比覆蓋幾頁文本的平均向量更能準(zhǔn)確反映它們的語義意義（這也取決于具體模型，但總體而言是這樣）。因此，我們需要將數(shù)據(jù)進(jìn)行分塊處理——把原始文檔分割成一定大小的部分，同時(shí)保持其原有意義（如將文本分割成句子或段落，而不是將一個(gè)句子切成兩半）。市面上有各種能夠完成此任務(wù)的文本分割器。
塊的大小是一個(gè)需要考慮的因素——它取決于你所使用的嵌入模型以及其在 Token 上的容量。標(biāo)準(zhǔn)的 Transformer Encoder 模型（例如基于 BERT 的句子轉(zhuǎn)換器）最多處理 512 個(gè) Token，而像 OpenAI 的 ada-002 則能處理更長的序列，例如 8191 個(gè) Token。這里需要權(quán)衡的是，為大語言模型提供足夠的上下文以便于推理，與保持文本嵌入具體到足以高效執(zhí)行搜索之間的平衡。在 LlamaIndex 中，通過?NodeParser?類及其一些高級(jí)選項(xiàng)（例如定義你自己的文本分割器、元數(shù)據(jù)、節(jié)點(diǎn)/塊關(guān)系等）來解決這一問題。
下一步是選擇一個(gè)模型來對(duì)我們的塊進(jìn)行嵌入——有很多可選模型，我選擇了像 bge-large 或 E5 嵌入系列這樣優(yōu)化搜索的模型。你可以查看 MTEB 排行榜，了解最新的更新情況。
想要實(shí)現(xiàn)分塊和向量化步驟的端到端實(shí)現(xiàn)，可以參考 LlamaIndex 中完整數(shù)據(jù)攝取流程的一個(gè)示例。
RAG 流水線的核心部分是搜索索引，用于存儲(chǔ)我們?cè)谇耙徊襟E中得到的向量化內(nèi)容。最基本的實(shí)現(xiàn)方法是使用平面索引 —— 直接計(jì)算查詢向量與所有數(shù)據(jù)塊向量之間的距離。
更高效的搜索索引，專為處理超過 10000 個(gè)元素的大規(guī)模檢索而優(yōu)化，通常采用向量索引，如 faiss、nmslib 或 annoy，它們采用近似最近鄰算法，比如聚類、樹形結(jié)構(gòu)或 HNSW 算法。
還有一些托管解決方案，如 OpenSearch 或 ElasticSearch，以及像 Pinecone、Weaviate 或 Chroma 這樣的向量數(shù)據(jù)庫，它們?cè)诤笈_(tái)處理第 1 步中描述的數(shù)據(jù)攝取流程。
根據(jù)你選擇的索引類型、數(shù)據(jù)和搜索需求，你還可以存儲(chǔ)元數(shù)據(jù)，并利用元數(shù)據(jù)過濾功能來搜索特定日期或來源的信息。
LlamaIndex 支持多種向量存儲(chǔ)索引，但也支持其他更簡(jiǎn)單的索引實(shí)現(xiàn)，如列表索引、樹索引和關(guān)鍵詞表索引——我們將在融合檢索部分進(jìn)一步討論這些實(shí)現(xiàn)方式。
如果你需要從大量文檔中檢索信息，你需要能夠高效地搜索這些文檔，找到相關(guān)信息，并將其整合成一個(gè)包含參考來源的統(tǒng)一答案。對(duì)于大型數(shù)據(jù)庫，一個(gè)有效的方法是創(chuàng)建兩個(gè)索引：一個(gè)包含摘要，另一個(gè)包含所有的文檔塊，并通過兩步搜索，先利用摘要篩選相關(guān)文檔，再在這些相關(guān)文檔中進(jìn)行具體搜索。
另一個(gè)策略是讓大語言模型為每個(gè)數(shù)據(jù)塊生成一個(gè)問題，并將這些問題轉(zhuǎn)換為向量。在運(yùn)行時(shí)，對(duì)這些問題向量的索引進(jìn)行查詢搜索（將索引中的數(shù)據(jù)塊向量替換為問題向量），然后在檢索后將原始文本塊作為上下文發(fā)送給大語言模型，以獲取答案。這種方法由于查詢和假設(shè)性問題之間的語義相似性更高，相較于實(shí)際數(shù)據(jù)塊，可以提升搜索質(zhì)量。
還有一種反向邏輯的方法叫做 HyDE —— 讓大語言模型根據(jù)查詢生成一個(gè)假設(shè)性回應(yīng)，然后使用其向量與查詢向量共同提高搜索質(zhì)量。
這里的想法是通過檢索更小的數(shù)據(jù)塊來提高搜索質(zhì)量，同時(shí)添加額外上下文，以供大語言模型進(jìn)行推理。有兩種方法：一是在檢索到的小塊周圍擴(kuò)展上下文，二是將文檔遞歸分割為包含小塊的更大父塊。
一個(gè)相對(duì)較舊的想法，即你可以從兩個(gè)世界中汲取精華 —— 基于關(guān)鍵詞的老式搜索?——?稀疏檢索算法，如 tf-idf 或搜索行業(yè)標(biāo)準(zhǔn) BM25 —— 以及現(xiàn)代的語義或向量搜索，并將其結(jié)合在一個(gè)檢索結(jié)果中。這里唯一的技巧是如何恰當(dāng)?shù)亟Y(jié)合不同相似度評(píng)分的檢索結(jié)果 —— 這個(gè)問題通常通過使用互惠排名融合算法來解決，對(duì)檢索結(jié)果進(jìn)行重新排名以得出最終輸出。
在 LangChain 中，這一過程通過 Ensemble Retriever 類實(shí)現(xiàn)，它結(jié)合了你定義的多個(gè)檢索器，如基于 faiss 的向量索引和基于 BM25 的檢索器，并使用 RRF 算法進(jìn)行結(jié)果的重新排名。
LlamaIndex 中的實(shí)現(xiàn)方式與此相似。
混合或融合搜索一般能提供更優(yōu)的檢索結(jié)果，因?yàn)樗Y(jié)合了兩種互補(bǔ)的搜索算法，既考慮了查詢與存儲(chǔ)文檔之間的語義相似性，又考慮了關(guān)鍵詞匹配。
在使用上述任一算法獲取檢索結(jié)果后，現(xiàn)在是時(shí)候通過過濾、重新排名或一些轉(zhuǎn)換來優(yōu)化這些結(jié)果。LlamaIndex 提供了多種后處理器，可以基于相似度評(píng)分、關(guān)鍵詞、元數(shù)據(jù)進(jìn)行過濾，或使用大語言模型、句子轉(zhuǎn)換器跨編碼器、Cohere 重新排名端點(diǎn)等其他模型進(jìn)行重新排名，甚至可以基于日期新近性等元數(shù)據(jù)進(jìn)行排序——幾乎包括了所有你能想到的方法。
這是在將檢索到的上下文提供給大語言模型以獲取最終答案之前的最后一步。
現(xiàn)在，我們將探討更高級(jí)的 RAG 技術(shù)，如查詢轉(zhuǎn)換和路由，這兩種技術(shù)都涉及到大語言模型，從而展現(xiàn)了智能體行為——在我們的 RAG 流水線中，涉及到大語言模型的復(fù)雜邏輯推理。
在使用上述任一算法獲取檢索結(jié)果后，現(xiàn)在是時(shí)候通過過濾、重新排名或一些轉(zhuǎn)換來優(yōu)化這些結(jié)果。LlamaIndex 提供了多種后處理器，可以基于相似度評(píng)分、關(guān)鍵詞、元數(shù)據(jù)進(jìn)行過濾，或使用大語言模型、句子轉(zhuǎn)換器跨編碼器、Cohere 重新排名端點(diǎn)等其他模型進(jìn)行重新排名，甚至可以基于日期新近性等元數(shù)據(jù)進(jìn)行排序——幾乎包括了所有你能想到的方法。
這是在將檢索到的上下文提供給大語言模型以獲取最終答案之前的最后一步。
現(xiàn)在，我們將探討更高級(jí)的 RAG 技術(shù)，如查詢轉(zhuǎn)換和路由，這兩種技術(shù)都涉及到大語言模型，從而展現(xiàn)了智能體行為——在我們的 RAG 流水線中，涉及到大語言模型的復(fù)雜邏輯推理。
查詢轉(zhuǎn)換是利用大語言模型（大語言模型）作為推理引擎，對(duì)用戶輸入進(jìn)行調(diào)整，以提升檢索效果的技術(shù)。實(shí)現(xiàn)這一目標(biāo)有多種方法。
如果查詢內(nèi)容復(fù)雜，大語言模型可以將其分解為幾個(gè)子查詢。例如，當(dāng)你問：“在 Github 上，Langchain 和 LlamaIndex 哪個(gè)框架星星更多？” 我們不太可能在語料庫的某些文本中直接找到答案，因此把這個(gè)問題分解成兩個(gè)更具體、更簡(jiǎn)單的子查詢是合理的：
這些子查詢將并行執(zhí)行，然后將檢索到的上下文合并成一個(gè)整體，供大語言模型綜合出最初查詢的終極答案。Langchain 作為多查詢檢索器和 LlamaIndex 作為子問題查詢引擎都實(shí)現(xiàn)了這一功能。
這部分沒有編號(hào)，因?yàn)樗袷且环N輔助工具而非檢索改進(jìn)技術(shù)，但仍然非常重要。如果我們由于初始查詢的復(fù)雜性（需要執(zhí)行多個(gè)子查詢并將檢索到的上下文合并成一個(gè)答案），或因?yàn)樵诓煌臋n中找到了單個(gè)查詢的相關(guān)上下文而使用了多個(gè)來源來生成答案，就會(huì)出現(xiàn)如何準(zhǔn)確引用這些來源的問題。
有幾種方法可以做到這一點(diǎn)：
構(gòu)建高效的 RAG 系統(tǒng)的下一個(gè)關(guān)鍵是引入聊天邏輯，這與大語言模型（大語言模型）出現(xiàn)之前的傳統(tǒng)聊天機(jī)器人同樣重要，都需要考慮對(duì)話上下文。這對(duì)于處理后續(xù)問題、指代或與先前對(duì)話上下文相關(guān)的用戶命令至關(guān)重要。這一問題通過結(jié)合用戶查詢和聊天上下文的查詢壓縮技術(shù)得以解決。
常見的上下文壓縮方法有幾種，例如：
值得一提的是，LlamaIndex 還支持基于 OpenAI 智能體的聊天引擎，提供了更靈活的聊天模式，而 Langchain 也支持 OpenAI 的功能性 API。
還有像 ReAct 智能體 這樣的其他聊天引擎類型，但我們接下來將直接跳轉(zhuǎn)到第 7 節(jié)，討論智能體本身
查詢路由是大語言模型驅(qū)動(dòng)的決策步驟，用于在接收到用戶查詢后決定下一步的行動(dòng) —— 通常的選擇包括進(jìn)行摘要、對(duì)某些數(shù)據(jù)索引執(zhí)行搜索，或嘗試多種不同的路由后將其輸出綜合成單一答案。
查詢路由器還用于選擇發(fā)送用戶查詢的索引或數(shù)據(jù)存儲(chǔ)位置。這可能是因?yàn)橛卸鄠€(gè)數(shù)據(jù)來源，如經(jīng)典的向量存儲(chǔ)、圖數(shù)據(jù)庫或關(guān)系數(shù)據(jù)庫，或者是因?yàn)橛卸鄬铀饕Y(jié)構(gòu) —— 在多文檔存儲(chǔ)的常見情況下，會(huì)有一個(gè)摘要索引和另一個(gè)文檔塊向量索引。
定義查詢路由器包括設(shè)定其可能的選擇。路由選項(xiàng)的選擇通過大語言模型調(diào)用來執(zhí)行，返回的結(jié)果采用預(yù)定義格式，用于將查詢路由至指定索引。在涉及智能體行為時(shí)，可能還會(huì)將查詢路由至子鏈甚至其他智能體，如下面多文檔智能體方案所示。
LlamaIndex 和 LangChain 都提供了查詢路由器的支持。
智能體（由 Langchain 和 LlamaIndex 支持）自大語言模型 API 首次發(fā)布以來就已經(jīng)存在。其核心思想是為具備推理能力的大語言模型提供一套工具和待完成的任務(wù)。這些工具可能包括確定性函數(shù)（如代碼函數(shù)或外部 API）或其他智能體——正是這種大語言模型鏈接的理念促成了 LangChain 的命名。
智能體本身是一個(gè)龐大的領(lǐng)域，在 RAG 概覽中無法深入探討，所以我將直接介紹基于智能體的多文檔檢索案例，并簡(jiǎn)要介紹 OpenAI 助理，這是 OpenAI 開發(fā)者大會(huì)上作為 GPTs 提出的相對(duì)新穎的概念，在下面描述的 RAG 系統(tǒng)中發(fā)揮作用。
OpenAI 助理實(shí)現(xiàn)了許多圍繞大語言模型所需的工具，這些工具之前是開源的，包括聊天歷史、知識(shí)存儲(chǔ)、文檔上傳界面，以及可能最重要的，功能調(diào)用 API。這些 API 能將自然語言轉(zhuǎn)換為對(duì)外部工具或數(shù)據(jù)庫查詢的調(diào)用。
LlamaIndex 中有一個(gè) OpenAIAgent 類，將這些高級(jí)邏輯與 ChatEngine 和 QueryEngine 類結(jié)合，提供基于知識(shí)和上下文感知的聊天以及在一次對(duì)話輪次中調(diào)用多個(gè) OpenAI 功能的能力，這真正帶來了智能的代理行為。
讓我們來看看多文檔智能體方案——這是一個(gè)復(fù)雜的設(shè)置，涉及在每個(gè)文檔上初始化一個(gè)智能體（OpenAIAgent），負(fù)責(zé)文檔摘要和經(jīng)典問答機(jī)制，以及一個(gè)負(fù)責(zé)將查詢路由至文檔智能體并合成最終答案的頂級(jí)智能體。
每個(gè)文檔智能體擁有兩種工具——向量存儲(chǔ)索引和摘要索引，并根據(jù)路由的查詢決定使用哪一個(gè)。對(duì)于頂級(jí)智能體而言，所有文檔智能體都是其工具。
這個(gè)方案展示了一個(gè)高級(jí) RAG 架構(gòu)，涉及每個(gè)參與智能體做出的眾多路由決策。這種方法的優(yōu)勢(shì)在于能夠比較不同文檔及其摘要中描述的不同解決方案或?qū)嶓w，并結(jié)合經(jīng)典的單文檔摘要和問答機(jī)制——這基本涵蓋了與文檔集合互動(dòng)的最常見聊天用例。
這種復(fù)雜的方案可能存在的缺點(diǎn)是，由于需要與智能體內(nèi)的大語言模型（大語言模型）進(jìn)行多次迭代，其速度可能較慢。值得注意的是，大語言模型的調(diào)用通常是 RAG 流水線中最耗時(shí)的操作，而搜索設(shè)計(jì)上是優(yōu)化了速度的。因此，對(duì)于大型多文檔存儲(chǔ)，建議考慮對(duì)這個(gè)方案進(jìn)行簡(jiǎn)化，使其更具可擴(kuò)展性。
響應(yīng)合成器是任何 RAG 流水線的最后一步——基于我們仔細(xì)檢索到的所有上下文和初始用戶查詢生成答案。最簡(jiǎn)單的方法是將所有檢索到的上下文（超過一定相關(guān)性閾值）與查詢一起一次性輸入大語言模型。然而，還有其他更復(fù)雜的選項(xiàng)，涉及多次調(diào)用大語言模型來精煉檢索到的上下文并生成更優(yōu)答案。
響應(yīng)合成的主要方法包括：
這種方法涉及對(duì) RAG 流水線中的兩個(gè)深度學(xué)習(xí)模型之一進(jìn)行微調(diào)——要么是負(fù)責(zé)嵌入質(zhì)量和上下文檢索質(zhì)量的 Transformer 編碼器，要么是負(fù)責(zé)充分利用提供的上下文以回答用戶查詢的大語言模型（大語言模型）。幸運(yùn)的是，后者擅長少樣本（甚至是零樣本）學(xué)習(xí)。
現(xiàn)在的一個(gè)重要優(yōu)勢(shì)是，可以利用像 GPT-4 這樣的高端大語言模型生成高質(zhì)量的合成數(shù)據(jù)集。
但需要意識(shí)到的是，使用專業(yè)研究團(tuán)隊(duì)在精心收集、清洗和驗(yàn)證的大型數(shù)據(jù)集上訓(xùn)練的開源模型，并用小型合成數(shù)據(jù)集進(jìn)行快速調(diào)整，可能會(huì)在總體上限制模型的能力。
我曾對(duì)編碼器微調(diào)方法持有一定懷疑，因?yàn)樽钚碌臑樗阉鲀?yōu)化的 Transformer 編碼器已經(jīng)相當(dāng)高效。然而，在 LlamaIndex 的筆記本環(huán)境中，我測(cè)試了對(duì) bge-large-en-v1.5（寫作時(shí)位于 MTEB 排行榜前四）的微調(diào)效果，發(fā)現(xiàn)它帶來了 2% 的檢索質(zhì)量提升。盡管提升不是很顯著，但了解這個(gè)選項(xiàng)仍然有價(jià)值，特別是在你為特定領(lǐng)域數(shù)據(jù)集構(gòu)建 RAG 時(shí)。
另一個(gè)常見選擇是使用交叉編碼器重新排列檢索結(jié)果，特別是當(dāng)你對(duì)基礎(chǔ)編碼器的信任度不足時(shí)。這個(gè)過程包括將查詢和每個(gè)前 k 個(gè)檢索到的文本塊傳遞給交叉編碼器，并用 SEP 令牌分隔，然后微調(diào)它以對(duì)相關(guān)塊輸出 1，對(duì)不相關(guān)塊輸出 0?？梢栽谶@里找到一個(gè)很好的微調(diào)過程示例，結(jié)果顯示通過交叉編碼器微調(diào)，成對(duì)得分提高了 4%。
最近 OpenAI 開始提供大語言模型微調(diào) API，LlamaIndex 也有關(guān)于在 RAG 設(shè)置中微調(diào) GPT-3.5-turbo 的教程，旨在“提煉”GPT-4 的部分知識(shí)。這里的想法是獲取一個(gè)文檔，用 GPT-3.5-turbo 生成一些問題，然后使用 GPT-4 根據(jù)文檔內(nèi)容生成這些問題的答案（構(gòu)建一個(gè)由 GPT-4 驅(qū)動(dòng)的 RAG 流水線），接著在這個(gè)問題-答案對(duì)數(shù)據(jù)集上微調(diào) GPT-3.5-turbo。用于 RAG 流水線評(píng)估的 ragas 框架顯示了 5% 的忠實(shí)度指標(biāo)提升，意味著微調(diào)后的 GPT-3.5-turbo 模型比原始模型更好地利用提供的上下文生成答案。
一種更復(fù)雜的方法在最近的論文《RA-DIT: Retrieval Augmented Dual Instruction Tuning》中展示，提出了一種同時(shí)調(diào)整大語言模型和檢索器（原論文中的雙編碼器）的技術(shù)，基于查詢、上下文和答案的三元組。關(guān)于實(shí)現(xiàn)細(xì)節(jié)，請(qǐng)參考這個(gè)指南。這種技術(shù)用于通過微調(diào) API 微調(diào) OpenAI 大語言模型，也用于微調(diào)開源 Llama2 模型（在原論文中），在知識(shí)密集型任務(wù)指標(biāo)上提升了約 5%（與搭載 RAG 的 Llama2 65B 相比），在常識(shí)推理任務(wù)上也有幾個(gè)百分點(diǎn)的提升。
RAG 系統(tǒng)的性能評(píng)估通常涉及幾個(gè)框架，它們的共同理念是設(shè)定幾個(gè)獨(dú)立指標(biāo)，如整體答案相關(guān)性、答案基礎(chǔ)性、忠實(shí)度和檢索到的上下文相關(guān)性。
如前文所提到的 Ragas 使用真實(shí)性和答案相關(guān)性作為生成答案的質(zhì)量指標(biāo)，以及用于 RAG 方案檢索部分的傳統(tǒng)上下文精確度和召回率。
在 Andrew NG 最近發(fā)布的短課程《構(gòu)建和評(píng)估高級(jí) RAG》中，LlamaIndex 和評(píng)估框架 Truelens 提出了 RAG 三元組：
最關(guān)鍵且最可控的指標(biāo)是檢索到的上下文相關(guān)性——基本上上文所述的高級(jí) RAG 流水線的第 1-7 部分及編碼器和排名器微調(diào)部分都旨在提升這一指標(biāo)，而第 8 部分和大語言模型微調(diào)則專注于答案相關(guān)性和基礎(chǔ)性。
關(guān)于相對(duì)簡(jiǎn)單的檢索器評(píng)估流程的一個(gè)好例子可以在這里找到，它在編碼器微調(diào)部分中得到應(yīng)用。一種更高級(jí)的方法不僅考慮命中率，還考慮平均倒數(shù)排名（一種常見的搜索引擎指標(biāo)）以及生成答案的忠實(shí)度和相關(guān)性，這在 OpenAI 的烹飪書中得到展示。
LangChain 有一個(gè)較為高級(jí)的評(píng)估框架 LangSmith，可以實(shí)施自定義評(píng)估器，并監(jiān)控 RAG 流水線內(nèi)部的跟蹤，以增強(qiáng)系統(tǒng)的透明度。
如果你正在使用 LlamaIndex 構(gòu)建系統(tǒng)，可以使用 rag_evaluator llama pack 這個(gè)工具，它提供了一個(gè)快速評(píng)估你的流水線的方法，適用于公共數(shù)據(jù)集。
我嘗試勾勒出 RAG 的核心算法方法，并通過示例來闡述其中一些，希望這能激發(fā)你在 RAG 流水線中嘗試新的想法，或?yàn)榻衲臧l(fā)明的各種技術(shù)帶來一定的系統(tǒng)性。對(duì)我來說，2023 年是迄今為止最令人激動(dòng)的一年。
還有許多其他方面需要考慮，例如基于網(wǎng)絡(luò)搜索的 RAG（如 LlamaIndex、webLangChain 的 RAGs）、更深入地探索智能體架構(gòu)（包括 OpenAI 最近在這方面的投入）以及關(guān)于大語言模型長期記憶的一些想法。
RAG 系統(tǒng)面臨的主要生產(chǎn)挑戰(zhàn)之一，除了答案相關(guān)性和忠實(shí)度之外，還有速度問題，尤其是在采用更靈活的基于智能體的方案時(shí)。但這是另一篇文章的主題。ChatGPT 和大多數(shù)其他助手使用的流媒體功能并非無緣無故采用賽博朋克風(fēng)格，而是為了縮短感知的答案生成時(shí)間。這也是我認(rèn)為小型大語言模型，以及最近發(fā)布的 Mixtral 和 Phi-2 有著光明的未來，它們正在引領(lǐng)我們朝這個(gè)方向前進(jìn)。
文章轉(zhuǎn)自微信公眾號(hào)@Afunby的 AI Lab
對(duì)比大模型API的內(nèi)容創(chuàng)意新穎性、情感共鳴力、商業(yè)轉(zhuǎn)化潛力
一鍵對(duì)比試用API 限時(shí)免費(fèi)
