大模型上下文協議與Spring開發集成篇——mcp-spring-webmvc原理
“腦子”的問題目前已經有了成熟的解決方案來繞開 token 數量的限制。通常的方法借鑒了 Map Reduce 的思想，涉及到給文檔切片、使用 Embedding 引擎、向量數據庫和語義搜索（我們在 02 中詳細介紹了這個過程）。
關于“手臂”的探索也早就有很多，OpenAI 的 WebGPT 給模型注入了使用網頁信息的能力，Adept 訓練的 ACT-1 則能自己去網站和使用 Excel、Salesforce 等軟件，PaLM 的 SayCan 和 PaLM-E 嘗試讓 LLM 和機器人結合，Meta 的 Toolformer 探索讓 LLM 自行調用 API，普林斯頓的 Shunyu Yao 做出的 ReAct 工作通過結合思維鏈 prompting 和這種“手臂”的理念讓 LLM 能夠搜索和使用維基百科的信息……
有了這些工作，在開源模型或者 API 之上，開發者們終于可以做有相對復雜步驟和業務邏輯的 AI 應用。而 LangChain 是一個開源的 Python 庫（后續又推出了 Typescript 版本），封裝好了大量的相關邏輯和代碼實現，開發者們可以直接調用，大大加速了構建一個應用的速度。
如果沒有 LangChain，這些探索可能首先將被局限在 Adept、Cohere 等有充足產研資源的公司身上，或僅僅停留在論文層面。然后隨著時間推移，開發者需要悶頭碼個幾周來復現這些邏輯。但是有了 LangChain，做一個基于公司內部文檔的問答機器人通常只需要兩天，而直接 fork 別人基于 LangChain 的代碼構建個人的 Notion 問答機器人則只需要幾個小時。
我自己知道的第一個使用 Map Reduce 思想的應用是 Pete Hunt 的 summarize.tech，一個基于 GPT-3 的 YouTube 視頻總結器。Pete 在去年 9 月興沖沖地在 Twitter 上表示自己找到了讓 GPT-3 調用成本下降 80% 的方法 —— 不是一股腦將 YouTube 視頻的文稿做總結，而是先將它分成很多的文本塊（chunk），對每個塊分別總結，最后給用戶交付的是“摘要的摘要”，過程中消耗的 token 數能節省很多。
事實上，這不光能讓成本降低，還可以解決單個 Prompt 中 token 數量限制的問題。隨著 12 月 OpenAI 新的 Embedding 引擎推出和 ChatGPT 讓更多 AI 應用開發者入場，這種做法目前已經成為解決 Context 問題的絕對主流做法。
下面我們以一個 300 頁的書的問答機器人為例，給讀者展示下 LangChain 如何封裝這個過程（這個例子來自 YouTube 博主 Data Independent 的 LangChain 101 系列視頻，如果你想迅速上手 LangChain，強烈推薦觀看）：
1. 哪怕是 GPT 的 32k token 限制，300 頁的書也絕對超過了，因此我們需要引入上文這種 Map Reduce 的做法；
2. LangChain 提供了許多 PDF loader 來幫助上傳 PDF，然后也提供許多類型的 splitter 讓你可以將長文本切成數百個文本塊，并盡量避免這么切可能導致的語義缺失；
3. 有了文本塊之后，你可以調用 OpenAI 的 Embedding 引擎將它們分別變成 Embeddings，即一些大的向量；
4. 你可以在本地存儲這些向量或者使用 Pinecone 這樣的云向量數據庫存儲它們；
5. 調用 LangChain 的 QA Chain 就可以進行問答了，這背后發生的是 —— 輸入的問題也被 Embedding 引擎變成向量，然后使用 Pincone 的向量搜索引擎找到語義最接近的一些 Embedding，將它們再拼接在一起作為答案返回。
LangChain 在過程中提供了完整的集成，從 OpenAI 的 LLM 本身、Embedding 引擎到 Pinecone 數據庫，并且將整體的交互邏輯進行了封裝。如果你想用別人基于 LangChain 的代碼 fork 這個 PDF 問答機器人，基本只需要換一下 OpenAI API key、Pincone API key 和用的這份 PDF。
LangChain 身上有許多標簽：開源的 Python 和 Typescript 庫、第一個被廣泛采用的 LLM 開發框架、Model as a Service 設想的中間件、AI 應用層的基礎設施……?感興趣上手使用 LangChain 的讀者可以參考下圖觀遠數據的這個講解視頻，或是去 LangChain 的文檔中心和 Github 逛逛。
Source：《微軟 365 Copilot 是如何實現的？揭秘 LLM 如何生成指令》- Bilibili
我在這一部分將不再羅列 LangChain 本身的一系列功能，而是詳細講講我認為 LangChain 最重要的 3 個身份 —— 讓 LLM 擁有上下文和行動能力的第一選擇、所有 LLM Ops 工具的粘合劑/螺栓、一個快速崛起的開源社區。
目前基于 LangChain 開發的第一用例是建立使用私有數據的問答機器人，而大多數開發者想到要導入私有數據，第一選擇就是基于 LangChain 來做。可以說 LangChain 是目前將上下文信息注入 LLM 的重要基礎設施。Harrison 在去年 11 月為 LangChain 總結的 4 大價值主張支柱也都圍繞這一點，體現出了很優美的模塊化和可組合性特點：
LLM 和 Prompts
如果是一個簡單的應用，比如寫詩機器人，或者有 token 數量限制的總結器，開發者完全可以只依賴 Prompt。此外，這也是更復雜的 Chain 和 Agent 的基礎。LangChain 在這一層讓切換底層使用的 LLM、管理 Prompt、優化 Prompt 變得非常容易。
此處最基礎的能力是 Prompt Template。一個 Prompt 通常由 Instructions、Context、Input Data（比如輸入的問題）和 Output Indicator（通常是對輸出數據格式的約定）。使用 LangChain 的 Prompt Template 很好地定義各個部分，同時將 Input Data 留作動態輸入項。
圍繞 Prompt，LangChain 還有很多非常有意思的小功能，比如 0.0.9 版本上的兩個能力：Dyanamic Prompts 可以檢查 Prompt 的長度，然后調整 few-shots 給出的示例數量，另一個 Example Generation 可以檢查 Prompt 里 token 數量還有剩余的話就再多生成些示例。
Chain
當一個應用稍微復雜點，單純依賴 Prompting 已經不夠了，這時候需要將 LLM 與其他信息源或者 LLM 給連接起來，比如調用搜索 API 或者是外部的數據庫等。LangChain 在這一層提供了與大量常用工具的集成（比如上文的 Pincone）、常見的端到端的 Chain。
今天 LangChain 封裝的各種 Chain 已經非常強勁，一開始 300 頁 PDF 的案例中用到的是它的 QA Chain，我再舉一些足夠簡單、易于理解的 Chain 作為例子：
它的第一個 Chain 可以讓完全沒有技術背景的讀者也對 Chain 有個概念 —— 這個 Chain 叫做 Self Ask with Search，實現了 OpenAI API 和 SerpApi（Google 搜索 API）的聯動，讓 LLM 一步步問出了美國網球公開賽冠軍的故鄉。
還有一個很直觀的 Chain 是 API chain，可以讓 LLM 查詢 API 并以自然語言回答問題，比如下面這個示例中 LLM 使用了 Open-Mateo（一個開源的天氣查詢 API）來獲取舊金山當天的降雨量：
Agent
Agent 封裝的邏輯和賦予 LLM 的“使命”比 Chain 要更復雜。在 Chain 里，數據的來源和流動方式相對固定。而在Agent 里，LLM 可以自己決定采用什么樣的行動、使用哪些工具，這些工具可以是搜索引擎、各類數據庫、任意的輸入或輸出的字符串，甚至是另一個 LLM、Chain 和 Agent。
Harrison 將 Agent 的概念引入 LangChain 是受到前文提到的 ReAct 和 AI21 Labs 的 MRKL（Modular Resaoning, Knowledge, and Language 模塊化推理、知識和語言）系統的啟發。作為 Agent 的 LLM 深度體現了思維鏈的能力，充當了交通指揮員或者路由者的角色。
重新回歸 OpenAI 的 Anrej Karpathy 在 Twitter 上經常說 LLM 會成為編排資源的認知引擎，LangChain 的 Agent 走得其實就是這個方向。所以 Agent 究竟能干什么呢？下面是我最喜歡的一個例子。
眾所周知，ChatGPT 能聽懂你的幾乎所有問題，但是老胡編亂造。另外有一個叫 Wolfram Alpha 的科學搜索引擎，擁有天文地理的各類知識和事實，只要能聽懂你提問就絕不會出錯，可惜之前只能用官方給的語法搜索，非常難用。所以它的創始人 Wolfram 老師一直在鼓吹 ChatGPT 與 Wolfram Alpha 結合的威力。
23 年 1 月 11 日，LangChain 貢獻者 Nicolas 完成了 ChatGPT 和 Wolfram Alpha 的集成。Agent 可以像下圖一樣運行，自行決定是否需要工具和 Wolfram Alpha，在回答“從芝加哥到東京的距離”時選擇了調用它，在回答“Wolfram 是否比 GPT-3 好”時選擇不調用它，自行回答。
Memory
LangChain 在上述的 3 層都做得很好，但是在 Memory 上一直相對薄弱，Harrison 自己不懂，一直由非全職的貢獻者 Sam Whitmore 貢獻相關代碼，他也承認 LangChain 在這塊兒有些技術債。
對于不了解 Memory 是什么的讀者，你在 ChatGPT 每個聊天 session 都會出現在入口的左側，OpenAI 會貼心地為你生成小標題，在每個 session 的問答里 ChatGPT 都能記住這個對話的上文（不過也是因為每次請求都會把之前的問答 token 都傳給 OpenAI），但是新的對話 session 中的 ChatGPT 一定不記得之前 session 中的信息。LangChain 中的 Chain 在前幾個月一直也都是這種無狀態的，但是通常開發 App 時開發者希望 LLM 能記住之前的交互。
在前 ChatGPT 時代，LangChain 不久還是實現了 Memory 的概念，在不同的 Query 間傳遞上下文，實現的方法跟開始的總結 300 頁 PDF 類似：
? 總體而言的方法是記錄之前的對話內容，將其放到 Prompt 的 Context 里；
? 記錄有很多的 tricks，比如直接傳遞上下文，或者對之前的對話內容進行總結，然后將總結放 Prompt 里。
微博博主寶玉 xp 畫過一個系統交互圖，如果不使用被封裝好的庫，自己手寫的話實際上這套邏輯也很復雜。
在 Scale AI 今年的 Hackthon 決賽上，Sam 又為 LangChain 做了 Entity Memory 的能力，可以為 LLM 和用戶聊天時 Entity 提供長期記憶上下文的能力：
在 ChatGPT 發布后，LangChain 又優化了 Memory 模塊，允許返回 List[ChatMessage]，將邏輯單元拆分為了更小的組件，更符合模塊化的思想。
模塊化和可組合性是 LangChain 的關鍵理念，但它還有一個理念和我們介紹過的 Universal API 公司很像。
其實站在投資者的視角看，LangChain 的壁壘比較薄。有人問過 Harrison：為什么開發者要用 LangChain 而不是直接使用 OpenAI 或者 Hugging Face 上的模型？LangChain 作為一個開源庫仍然主要依賴于其他的開源庫，它的長期目標是什么？Harrison 的回答是：
Hugging Face、OpenAI、Cohere 可以提供底座模型和 API，但是在產品中集成和使用它們仍然需要大量的工作，長期目標是幫助人們更容易地構建 LLM 支持的應用。
從這個視角看，LangChain 更像“膠水”和“螺栓”。它的價值在于：
1. 全過程一站式的集成，從非結構化數據的預處理到不同模型結果的評估，開發者所需要的工具和庫 LangChain 基本都有現成的集成。
2. LangChain 作為 Universal Layer 在 LLM 身上包了一層，讓用戶可以更自由地在多個 LLM、Embedding 引擎等之間切換，以避免單點風險和降低成本。
這里的邏輯和 Universal API 很像 —— 每個 LLM 提供者的 API 數據結構不同，但是 LangChain 包了一層后做了遍 Data Normalization。從想象力的角度看，LangChain 有一定的編排價值，如果 Model as a Service 和多模型是未來，那么 LangChain 的價值會比想象中厚一些。
舉兩個例子：
去年 OpenAI 的 API 還很貴的時候，一些數據加載器將文本塊變成向量的方式是調用 OpenAI 的 Davinci Embedding，Harrison 覺得 LangChain 可以做到先用 Hugging Face 或者 Cohere 上便宜的模型做一道，然后再傳給 Davinci Embedding，這樣可以降低不少成本。
還有今年以來，ChatGPT 有時候會崩，這也引發了應用開發者們的擔憂。Will Brenton 覺得出于這種理由用 LangChain 就很值得，可以用幾行代碼實現在多個 LLM 之間切換的邏輯，一個 LLM 如果服務掛掉了就自動試下一個。
使用 LangChain 對比多個模型的輸出
LangChain 是目前 LLM 領域最熱門的開源項目之一，從下面可以看出今年以來的曲線和絕對 Star 數跟最熱門的開源模型 LLama 相比也不遑多讓，發布不到 5 個月已經擁有了超過 1 萬個 Github Star。
人多力量大，我們在上文介紹的集成大多數也都是社區貢獻的，目前 LangChain 的全職團隊只有 2-3 個人：
? 發起人是 Harrison Chase，他 17 年從哈佛大學畢業，分別在 Kensho（一家金融自動化公司，做金融分析決策與 NLP 的結合）和 Robust Intelligence（AI 模型部署的安全公司）做機器學習工程師，在 2022 年 9 月 的 Homebrew AI Club 聚會上聽到 Sam Whitmore 構建 AI 應用的過程和痛點后，他開始做 LangChain；
? 第一位全職加入 Harrison 的 LangChain 創業之旅的人似乎是 Ankush Gola，他從普林斯頓畢業后分別在 Facebook、Robust Intelligence 和 Unfold 做軟件開發，可以彌補 Harrison 在軟件工程方面經驗的缺失。Harrison 搞不定 LangChain 的異步支持問題，Ankush 加入后迅速彌補了這一點，讓 LangChain 能夠使用 asyncio 庫。
開源是擴大影響力和話語權的最好手段，LangChain 在 ChatGPT API 和 GPT-4 問世的當天都迅速發布了集成，基于 LangChain 構建的應用想轉用 GPT-4 只需要換下 API key 和模型名字就行了，顯然 LangChain 是 OpenAI 的重點合作對象之一。
除了 OpenAI 的這些更新，Zapier 推出的 Natural Language Actions API 也是跟 LangChain 進行了深度合作，Zapier NLA 對其 2 萬多個工具的操作實現了“自然語音 → API call → LLM-friendly 輸出”，也是基于 LangChain 做的。然后在推出當天，LangChain 也官宣了跟 Zapier NLA 的集成，用戶可以先在 Zapier 支持的 App 上設置好一個 NLA API endpoint，然后就可以在 LangChain 中調用和組合使用 Zapier。
從這兩個案例看，LangChain 是大模型能力“B2B2C”的一個重要中間站。
此外，除了給 LangChain 項目直接做貢獻，還有不少人已經在圍繞 LangChain 做生態項目，下面是我最喜歡的 2 個：
LangChain 本身是一個沒有 UI 的庫，但社區成員 Rodrigo Nader 為它構建了一個開源的 UI，叫做?LangFlow，讓用戶可以通過拖拽就能做出來應用原型。
大多數用戶會使用 Streamlit 或者 Replit 來部署它們的應用，但是已經有社區成員開始為 LangChain 應用打造更炫酷的部署方式，比如?Kookaburra，可以讓 LangChain 應用非常方便地被部署為短信機器人。
從投資者視角，我對 LangChain 的擔憂有兩點：
1. 它是一個很難被商業化的開源項目，因為它是一個“依賴其他開源庫的開源庫”，我所訪談的 LangChain 開發者也都認為自己不會為它付費，如果要構建一個基于 LLM 應用的公司，他們會選擇自己 fork LangChain 再寫一套框架，還能順手把成本和延時問題做更多優化；
2. 和第一點相輔相成的是，目前使用 LangChain 的主流人群是 Hacker 和獨立開發者們，而不是 B 輪以后的 Mid-Market 或者大型企業公司。當然，這是目前 AI 應用生態的現狀，獨立開發者在數量上占據主導。而且當前的 LangChain 實現一些復雜邏輯需要多個 Chain 的嵌套，并且多次 call LLM API，對于大規模調用的產品可能也確實成本不經濟也有不穩定的情況。但是正因為此，LangChain 更難進行商業化，特別是在從數據準備到模型部署的全環節已經非常卷的情況下。
從演進的視角看，我對于 LangChain 這個庫本身能不能具備服務中大型公司倒比較有信心 —— 兩個月前人們還不認為 LangChain 是一個在生產環境中可靠的東西，一個月前 LangChain 才剛剛支持自托管模型，讓企業 LLM 用戶可以在 LangChain 中調用共享遠程 API，但是它在客戶自己的云賬戶或者本地硬件中運行。給 LangChain 時間，貢獻者們會讓它高度可用。
市場上普遍對 LangChain 有擔心，但是我認為短期影響不大的兩點是：
1. LLM 本身的變化會讓 LangChain 庫中的許多部分過時。這一點我認為恰恰是開源項目的優勢，貢獻者可以迅速幫助它過渡到新版本；
比如 ChatGPT API 發布后，它有了新的交互，這也意味著需要新的抽象，原來的很多 Prompt 不管用了，適用于 GPT-3 的 Prompt Templates 在 ChatGPT 下效果不好，所以 LangChain 又新增了 PromptSelectors 功能。此外 ChatGPT 在遵循特定的輸出數據格式上表現得不好，有很多“無法解析 LLM 輸出”的報錯，LangChain 很快上了一個 chat-zero-shot-react-description Agent 來嚴格約束輸出的數據格式，還大受好評。使用 LangChain 可能幫助很多公司避免過多的 Prompt Engineering 開發資源浪費。
2. 隨著模型支持的 token 數量變多，LangChain 的核心用例 —— 用分塊、Embedding、語義搜索、再拼回來 —— 可能會直接消失。這在短期內不是個問題，因為哪怕 GPT-4 的 3.2 萬 token 也仍然不是很夠用。同時，這種 Map Reduce 的方式還能省錢。
在理性的質疑中，我比較認可的是 Notion AI 的 Linus 的觀點，他在 Twitter 上表示當前所有類似 LangChain 的 Prompt Ops 工具都是為 side-project 級別的用戶服務的，很難正經接受它們，主要有 3 點原因：
1. 這些工具都假設一個服務是對 LLM 的調用，然后在此之上把業務邏輯耦合進去。而不是反過來，在已有業務邏輯里插入對 LLM 的調用，這讓現有的 SaaS 等公司很難使用這些工具；
2. 對于模型的輸出大家目前都沒有可量化的方式來評估，Humanloop 已經有最好的模型評估 UI 了，但是也是為了人類反饋對齊而不是為了應用開發者的性能優化和迭代；
3. 這些工具都希望成為生產環境下工作負載的關鍵中間點，但是有延時和安全性上的很有問題，還不如給用戶交付模型配置和最終 prompt 然后讓用戶自己調用模型。
一些朋友在 Linus 的觀點下指出： LangChain 不是一個 Prompt Ops 工具，它是一個 LLM 增強工具，通過粘合一系列的模塊（這些模塊本身可能是 Prompt 增強工具）增加了 LLM 可以融入的業務邏輯復雜度。Linus 也認同這一點。總體而言，我認為這些批評為 LangChain 指明了方向，它也的確在 3 月擁有了更多和模型評估以及性能可觀測性相關的集成。
拋開直接面向消費者的應用不看，LangChain 的核心競爭對手是三類：
? GPT-Index 本身是基于 LangChain 構建的，它的用例更集中于 Memory 和將數據導入 LLM，用例非常明晰，而 LangChain 的功能更抽象和龐大，用戶需要在其中挑選符合自己用例的進行組合；
??Microsoft Semantic Kernel?的整體目標和 LangChain 非常接近，Planner 類似我們上文提到的 Agent，但是它針對的受眾不是獨立應用開發者，而是那些需要在兼顧原有開發工作的同時將 LLM 能力嵌入自家應用的工程師們，因此采用了一個輕量級 SDK 的形式交付，它是 LangChain非常強勁的潛在競爭對手，但是 Microsoft 和 OpenAI 的親密關系可能讓它在未來無法像 LangChain 一樣靈活支持各類 LLM；
? Dust 和 Scale AI Spellbook 代表著 LLM 應用開發的無代碼和低代碼思路，擁有非常好的 UI/UX，但是大多數開發者認為自己并不是需要低代碼的工具，而是需要更多的功能和可實驗性。
我們訪談的所有 LangChain 用戶都只使用 LangChain，對于 GPT-Index 和 Dust 只探索到去它們的 Github 和官網逛逛的程度。有 Twitter 博主專門橫向測評了這三個工具，結論是：
如果你想構建復雜邏輯并且自己托管后端的應用，那就使用 LangChain。Dust 和 Everyprompt 是通過 UI 來定義 Prompt 和創建 LLM 工作圖，LangChain 作為一個 Python 庫提供了更多的靈活性、可控度但更笨重。它的 game changer 是圍繞 Agent 的能力，一個可以跟外部工具（python interpreter、搜索引擎）交互從而回答問題的 LLM，這是其他工具所不具備的。
不看大廠的話，創業三杰 LangChain、GPT-Index、Dust 互相有很多羈絆，絕對不是火并競爭的關系：Dust 比 LangChain 出現得更早，由前 OpenAI 的Stanislas 創建，它的理念和對可組合性的重視對 Harrison 做 LangChain 有很大的啟發。而 GPT-Index 的創始人 Jerry Liu 是 Harrison 在 Robust Intelligence 時的同事，因此兩個人經常交流產品想法，GPT-Index 和 LangChain 互相有非常多的集成。
甚至 GPT-Index 本身也是基于 LangChain 構建的，能享受 LangChain 基建升級的許多好處。比如 LangChain 在 1 月底提供了 tracing 的能力，讓用戶能更好觀測和 debug 自己的 Chain 和 Agent，GPT-Index 作為基于 LangChain 的包也自動獲得了這個功能。下圖是一個 GPT-Index query 的 tracing 視圖：
LangChain 是一個開源項目，Harrison Chase 想構建的似乎不止于 LangChain。上個月，The Information 報道 Benchmark 以數千萬美元估值投資了 LangChain 數百萬美元。Harrison 有可能在繼續擴大 LangChain 影響力的同時做出更產品化的開發者工具。
從早期投資押注人的角度，Harrison 是一個很好的創業者和項目經理，盡管還沒有直接交流過，但我比較喜歡他的幾個特質：
在 22 年下半年，市場逐漸開始意識到 LLM 的下一步是“Action”，也就是在外部世界能夠采取行動。標志性的事件之一是 Cohere 在 9 月推出了基于 LLM 的 Discord 搜索機器人。
Harrison 這時候已經花了不少時間思考下一步所需要的工具，并且留意到了 Dust 的嘗試，隨后就開始構建 LangChain 這個 Python 包，并且在 10 月就立馬推出。在此期間，碰到有人做應用，Harrison 經常會問問對方“什么工具會幫你提效”、“還缺什么工具”。
回過頭看，LangChain 能繼續火下去的前提是，目前 AI 應用已經從模型技術能力的 pk 到了產品能力的 pk，Harrison 自己的總結是“能有好的產品創意的人 > 能創建更好模型的人”，而 LangChain 就希望解鎖這些人的創意和效率。
從后視鏡看，LangChain 的 Chain 和 Agent 邏輯似乎是個無腦的選擇。但是 Harrison 當時選擇構建這一點是基于對 Action 驅動和對 LLM 能力的判斷，受到了 ReAct 這篇論文不少影響。
他對于 token 數量限制的理解也很敏銳，將 Map Reduce 的實現提到了 LangChain 比較高的優先級，后面隨著 1 月份各種 AI Hackthon（Hugging Face、Scale AI 等）的舉辦，對快速使用這個邏輯的需求激增，并且相關參賽隊伍都會提到自己使用了 LangChain，讓 LangChain 迅速變成了 AI 應用開發者們的第一選擇。
LangChain 開發者舊金山 Meetup 的盛況
LangChain 上線各類新模型和新集成的速度非常快，Harrison 自己干活快，而且迅速讓 LangChain 的社區非常有凝聚力 ——?AI 和 LLM 本身是有趣且實用的，Harrison 推動做了 LangChain Hub，旨在為用戶提供一個易于分享和發現 Prompt Sequence、Chain 和 Agent，又加深了這一點。同時，Harrison 很善于跟社區成員交流獲得更多的反饋，在 LangChain Discord 社區頻繁互動，并且建立了一個專用的 Slack 頻道幫助大家將 LangChain 用于生產環境。
有一個小的細節是：在 1 月中旬，有用戶反饋 LangChain 的 verbose（根據內容來自的模型或組件來使用突出色號顯示）挺有用但可以更詳細，比如每個查詢到底用了多少 token，這樣在應用可能被大規模使用時可以更好地追蹤成本。這是個很細節的功能，但是 Harrison 表達了重視并且在一周之后添加了對 token 的計算和顯示，并且通過 GPT-Index 統計 token 的具體使用情況。類似的例子我還觀察到了不少，只要是 Harrison 答應用戶的需求，一定不久就會發布。
文章轉自微信公眾號@海外獨角獸
