精打細算用好 LLMs ：LLM 落地應用成本及響應延遲優化 原創 精華
編者按： LLMs 被視為 AI 領域的一個里程碑式的突破，但要將其應用于實際生產環境，并且還能用對、用好并非易事。模型的使用成本和響應延遲是目前將大語言模型（LLMs）應用于生產環境中的核心難題之一。
在本期刊載的這篇文章中，作者從自身項目的實踐經驗出發，分享了一系列實用技巧，幫助優化 LLM Prompt ，能夠一定程度上降低大模型的使用成本和響應延遲。
文章首先解析了導致高成本和高延遲的根源在于輸入輸出 tokens 的數量，而非任務本身的復雜度。接下來，作者逐一闡述了包括提示詞拆分、模塊化設計、與傳統編程技術結合使用等多種優化策略。這些策略體現了作者對大模型應用本質的深刻理解，注重發揮 LLMs 在復雜推理方面的優勢，同時將數學計算、數據聚合等工作外包給 SQL/Python 等更高效的工具。
本文貫穿了一種務實的方法論 ------ 理性看待 LLMs 技術，揚長避短，與其他技術工具形成合力，而非將其視為解決一切問題的"靈丹妙藥"。這種觀點和方法論對于企業更好地將 LLMs 技術應用于生產實踐至關重要。
作者 ：Jan Majewski
編譯 ：岳揚
image generated by author with GPT-4o
高成本和延遲是將大語言模型應用于生產環境中的主要障礙之一，二者均與提示詞信息的體量（prompt size）緊密相連。
鑒于大語言模型（LLM）展現出極強的廣泛適用性，不少人視其為解決各類問題的靈丹妙藥。通過與諸如檢索增強生成技術（RAG\\）及 API 調用等在內的工具整合，并配以精細的指導性提示詞，LLM 時常能展現出逼近人類水平的工作能力。
然而，這種無所不包的應用策略，其潛在隱患在于可能會導致提示詞的信息量迅速膨脹，直接引發高昂的使用成本以及較大的響應延遲，令 LLMs 在生產環境的實際部署面臨重重困難。
針對高價值任務（如代碼優化任務）使用 LLMs 時，成本這方面的考量或許會退居其次 ------ 一段平常半小時才能編寫完成的代碼現在等待半分鐘即完成，花費一定的成本尚可接受。但轉至 To C 領域，面對成千上萬次的即時對話需求，成本控制與響應速度便成為決定項目成敗的關鍵。
本文將分享為 ??Resider.pl?? 構建由 LLM 支持的房地產搜索助手 "Mieszko" 這一過程的心得。本文的重點是：如何跨越從吸引眼球的概念驗證（impressive POC） 到在實操中有效運用 LLMs 的鴻溝。
01 Prompt is all you have
在構建 "Mieszko" 時，我非常倚重 LangChain 這一個出色的框架。該框架以一種有序且清晰的方式，將復雜的邏輯或組件抽象化，并配備了高效易用的提示詞模板，僅需寥寥數行代碼即可實現調用。
LangChain 的易用性或許會讓我們不經意間忘卻一個核心要點：不論我們的解決方案有多么繁瑣，實質上所有組件都會匯總成一條長長的文本信息------"指令性提示詞"------傳遞給LLM。接下來將要展示的內容是一個概括性的示例說明，用于展示 LLM Agent 在接收指令性提示詞或執行任務前，其輸入提示詞的基本結構和主要組成部分。
使用 LLM Agent 中的指令性提示詞模板時所采用的基本結構
02 是什么影響了使用成本和響應延遲？
LLMs（大語言模型）是有史以來構建的最復雜的人工智能模型之一，但其響應延遲和使用成本主要取決于輸入和輸出處理的 tokens 數量，而非任務本身的難度。
撰寫本文時，OpenAI 旗艦模型 GPT-4 Turbo 的定價公式大致如下：
響應延遲的相關計算方法則并不那么直接，但根據 "Mieszko" 的應用場景，可簡單歸結為以下這個公式：
從成本角度看，input tokens 通常是 LLMs 使用成本的"大頭"，其價格僅為 output tokens 的三分之一，但對于更復雜的任務，提示詞長度會遠超面向用戶的 output tokens 長度。
然而，延遲主要受 output tokens 影響，處理 output tokens 的時間大約是 input tokens 的 200 倍。
在使用 LLM Agents 時，約 80% 的 tokens 來自 input tokens ，主要是初始的提示詞和 Agents 推理過程中的消耗。這些 input tokens 是使用成本的關鍵組成部分，但對響應時間的影響有限。
03 監控和管理 tokens 的消耗
在構建任何 LLMs 應用程序時，除了初始提示詞模板之外，至少還需要以下組件：
- 記憶庫（每次與 LLMs 的交互（每次調用）中，都需要包含之前所有的對話消息或歷史上下文。）
- 工具箱（如供 LLMs 調用的API），及其詳細的指導性提示詞
- 檢索增強生成（RAG）系統及其產生的上下文
從技術上講，我們可以添加任意數量的工具，但如果依賴最簡單的 Agent\&Tools 架構，可能系統的擴展性就會很差。對于每一種可用的工具，都需要在每次調用 Agents 時發送諸如 API 文檔之類的詳細說明。
在準備新系統組件時，需要考慮每次調用增加多少個 tokens 是值得的。 如果使用的是 OpenAI 的模型，可以快速評估新工具或額外的指導性提示詞的"tokens 消耗"情況，方法如下：
- 直接訪問網站：??https://platform.openai.com/tokenizer??
- 如果你更喜歡使用 Python，可以使用 tiktoken 庫，通過以下簡單函數實現：
import tiktoken
def num_tokens_from_string(string: str, model_name: str) -> int:
try:
encoding = tiktoken.encoding_for_model(model_name)
except KeyError as e:
raise KeyError(f"Error: No encoding available for the model '{model_name}'. Please check the model name and try again.")
num_tokens = len(encoding.encode(string))
return num_tokens04 如何在保持提示詞精簡的同時不犧牲準確性
初次接觸時，大語言模型（LLMs）可能令人感到無所適從，但歸根結底，重要的是要記住我們打交道的仍是軟件。這意味著我們應當事先預料到會出現錯誤，管理和控制軟件系統設計中的抽象層次和模塊化程度，并尋找更高效的解決方案來處理子任務。
在開發 Mieszko 的過程中，我發現以下一些通用技巧特別有用。我將在未來幾周內撰寫后續文章講解其中的大多數通用技巧，因此，如果你想不錯過這些內容，歡迎您在此（??https://medium.com/@janekmajewski/subscribe）?? 訂閱我的個人主頁，以便在文章發布時接收到通知。
4.1 將大段提示詞拆分成多層然后再調用
軟件工程的關鍵原則之一是模塊化和抽象化。試圖用單個提示詞來處理更復雜的問題，就如同編寫難以維護的"意大利面條式"代碼（Spaghetti code）（譯者注：這個比喻來源于意大利面（spaghetti）纏繞不清、難分難解的形象。當一段代碼缺乏清晰的結構、正確的模塊劃分和合理的邏輯順序，而是充斥著大量的嵌套條件語句、無序的跳轉、重復的代碼塊時，就被視為"意大利面式代碼"。）一樣低效。
在構建 Mieszko 時，性能顯著提升的一個關鍵點是將提示詞拆分為兩個部分：
- 用于決策的 Agent （Decision Agent）：對下一步可以采取的措施以及如何處理提示詞輸出的一般指導原則。
- 用于執行任務的 Agent / 對話型 LLMs 系統：含有針對具體步驟（如房源搜索、數據比較或房地產知識查詢）的詳細指導性提示詞。
分層決策與執行架構圖
分層決策和執行調用架構圖，圖片由原文作者提供
這種架構使得我們能夠在每次調用時，首先選取需要使用的特定任務提示詞，而無需隨附沉重的、消耗大量 tokens 的執行指令（execution instructions），從而平均減少了超過 60% 的 tokens 使用量。
4.2 務必監控每次調用時的最終提示詞
LLM 接收到的最終提示詞（final prompt）可能與最初的提示詞模板相去甚遠。通過工具（tools）、記憶庫（memory）、上下文（context）及 Agent 的內部推理來豐富提示詞模板這一過程，可能會使提示詞的規模激增數千個 tokens 。
此外，LLMs 有時會展現出如洛奇·巴爾博亞（Rocky Balboa）（譯者注：洛奇·巴爾博亞（Rocky Balboa），美國電影《洛奇》系列的主角，業余拳擊手出身，憑借自身的努力，登上拳壇最高峰。）般的韌性，即使面對存在錯誤和矛盾的提示詞，也能"站起來"給出合理的答案。
通過仔細審查數十次 LLMs 的調用，并深入了解大語言模型（LLM）實際上接收到了什么信息，能為關鍵突破（key breakthroughs）和消除漏洞（bug elimination）提供寶貴洞見。我強烈推薦使用 LangSmith 來進行深入分析。
如果想要尋求最簡便的方案，也可以啟用 LangChain 中的調試功能，它將為我們提供每次調用時確切發送的提示詞，以及大量有用信息，幫助我們更好地監控和優化提示詞內容。
import langchain
langchain.debug=True4.3 如只需幾行代碼即可處理的事，向 LLMs 提交前請三思
在使用 LLMs 時，最大的誤區是忘記你仍然可以利用編程來解決問題。 以我為例，一些最大的性能提升，就是通過使用 Python 函數在 LLMs 調用的上下游處理一些極為簡單的任務。
在使用 LangChain 時，這一點尤為有效，我們可以輕松地將 LLMs 的調用與傳統的 Python 函數進行鏈式處理。下面是一個簡化的示例，我曾用它來解決一個難題：即便指示 LLMs 保持回答與用戶發送的消息相同的語言，LLMs 仍默認回復英文。
我們無需借助 LLMs 來檢測目前的對話使用的是什么語言，利用 Google Translate API 或甚至是一個簡單的 Python 庫（如 langdetect ），可以更快、更準確地完成這項任務。一旦我們確定了輸入語言，就可以明確地將其傳入指導性提示詞中，從而減少在 LLMs 的調用過程中需要處理的工作量。
from langdetect import detect
prompt = """
Summarize the following message in {language}:
Message: {input}
"""
prompt = ChatPromptTemplate.from_template(prompt)
def detect_language(input_message):
input_message["language"] = detect(input_message["input"])
return input_message
detect_language_step= RunnablePassthrough.assign(input_message=detect_language)
chain_summarize_in_message_language = (
detect_language_step
* RunnablePassthrough.assign(
language=lambda x: x["input_message"]["language"]
)
* prompt
* llm )4.4 在設計 Agent 的提示詞時要精打細算，因為它們通常至少會被調用兩次
集成了工具的 Agent 能夠將 LLMs 的能力提升到新的層次，但同時它們也非常消耗 tokens（計算資源）。 下面的圖表展示了 LLM Agent 針對 query 提供答案的一般邏輯流程。
AI Agent 兩次調用 LLM，圖片由原文作者提供
如上圖所示，Agent 通常至少需要調用 LLM 兩次：第一次是為了規劃如何使用工具，第二次則是解析這些工具的輸出以便給出最終答案。這一特點意味著，我們在設計提示詞時節省的每一個 token，實際上都會帶來雙倍的效益。
對于某些較為簡單的任務，采用 Agent 的方式可能是"用牛刀殺雞"，而直接使用帶有 Completion 的簡單指導性提示詞（譯者注：模型接收到 instruction prompt 后的內容生成過程。）可能就能夠達到相似的結果，且速度甚至還能快上一倍。以 Mieszko 項目為例，我們決定將大部分任務從 Multi-Agent 架構轉變為基于特定任務的 Agent+Completion 模式。
4.5 將大語言模型和傳統編程工具結合使用，發揮各自的優勢（Use LLMs for reasoning but calculate and aggregate with SQL or Python）
相較于早期的 GPT-3.5，最新頂尖大語言模型已經有了很大的進步，那時它們在處理基礎數學公式時都還會出錯。現在，在諸如計算 segment averages （譯者注：在一組數據中，將數據分成若干個段或區間，然后計算每個段內數據的平均值。）任務上，LLMs 已經能夠輕松處理數百個數字。
但它們更擅長編寫 Python 或 SQL，無需數以萬億計的模型參數，就能以 100% 的準確率執行復雜的數學運算。然而，向 LLMs 傳遞大量數字會消耗大量 tokens ，在最好的情況下，每 3 位數字都會轉換為一個 token ；若數值龐大，單個數字就可能占用多個 tokens 。
想要更低成本、更高效率地分析數學運算，獲得運算結果，竅門在于如何運用 LLMs 理解問題及手頭數據，繼而將之轉譯為 SQL 或 Python 這類更適合進行數學分析的編程語言。
實踐中，可將編寫的代碼嵌入一個函數內執行，此函數負責連接數據源并僅將最終分析結果呈現給 LLM，供其直接理解、分析。
05 Summary
希望本文介紹的這些通用技巧，能夠幫助各位讀者更好地了解 LLMs 應用中使用成本和響應延遲的主要影響因素，以及如何優化它們。我希望盡可能多地分享我在開發基于 LLM 的生產級應用中學到的關鍵經驗教訓。在本系列接下來的文章中，我將從更具體、實踐性更強的實踐案例著手：
- 使用 Python guardrails （譯者注：使用 Python 編寫基于規則的驗證函數。）提升 LLM 輸出內容的可靠性
- 通過模塊化和抽象化（Modularity and Abstraction）增強 LLM Agents
- 利用 LangSmith 了解、監控基于 LLMs 的應用（預計六月中旬發布）
最后，特別感謝 Filip Danieluk ，并向 Filip Danieluk 致以崇高的敬意，他是 Mieszko 引擎的 co-creator 。無數個晝夜的深入討論和結對編程（pair-programming）催生了本系列文中闡述的內容，這些見解既屬于我，也屬于 Filip 。
Thanks for reading!
Jan Majewski
??https://medium.com/@janekmajewski??
Leveraging LLMs to transform Real Estate search. Data Scientist passionate about NLP, geo-analytics and price-benchmarking
END
本文經原作者授權，由 Baihai IDP 編譯。如需轉載譯文，請聯系獲取授權。
原文鏈接：
