用大型語言模型構(gòu)建讓我明白了一個明確的道理：最好的AI功能往往是隱形的。

當它成功時，用戶不會停下來想“那是人工智能”。他們只需點擊一個按鈕，快速得到回復，然后繼續(xù)他們的任務。

當它不奏效時，你會立刻注意到：轉(zhuǎn)盤花的時間太長，或者答案聽起來自信但其實不是真的。我多次遇到這兩堵墻。每次修復都不是關(guān)于“更智能的AI”，而是關(guān)于謹慎的工程選擇。只使用你需要的上下文。要求有結(jié)構(gòu)化的產(chǎn)出。當準確性重要時，保持低隨機性。讓系統(tǒng)說“我不知道”。

本指南不涉及大型研究理念。它講述的是任何工程師都可以遵循的實際步驟，將開源的大型語言模型引入真實產(chǎn)品。可以把它當作一本實地指南。可以把它看作是一個現(xiàn)場指南，擁有簡單的模式、可復制的代碼和習慣，讓AI功能感覺可靠、平靜且快速。

工作原理——四步循環(huán)

每一個可靠的AI功能都遵循同一個循環(huán)。保持一致。無聊是好事。

1）閱讀

只收集用戶輸入和你需要的最小應用上下文片段。更多的背景意味著成本更高，響應更慢，模型更容易偏離。

例子：

• 客服——“我的訂單在哪里？”→傳遞用戶ID和最后訂單摘要，而不是完整的訂單歷史。

• 提取——“從此郵件線程中提取姓名和日期”→僅傳遞線程文本，不傳遞無關(guān)附件。

• 搜索——“查找退款政策”→傳遞文件中的前三段內(nèi)容，而不是全部知識庫。

2）約束

設(shè)定規(guī)則，確保模型保持在你期望的約束范圍內(nèi)。

• 系統(tǒng)提示符作為合同

• 說明助理是什么，什么不是

• 要求有效的 JSON 與模式相匹配

• 如果缺少信息，請請求用戶簡短的后續(xù)詢問或回答“我不知道”。

• 保持隱私規(guī)則明確（不記錄敏感數(shù)據(jù)）

• 修改提示并進行測試

• 溫度與任務匹配（沒有一個設(shè)置適合所有任務）

• 低（≈0.0–0.2）：提取、分類、驗證、RAG回答并附引用、可靠的工具選擇

• 中等：模板草稿與輕音色變化

• 高：頭腦風暴和創(chuàng)意文案，多樣性很重要

無論如何都要保持上下文緊密。如果你的棧支持，測試中使用種子以提高重復性。

3）行為

目標是產(chǎn)出可以作為下一階段工作流程輸入的LLM輸出，無需進一步處理。

何時使用：

• 當下一步是程序化步驟時，結(jié)構(gòu)化輸出，例如用于更新界面、存儲字段和運行驗證。

• 為什么：這些輸出作為工作流程或應用下一步的輸入，無需進一步人工處理，是結(jié)構(gòu)化、可解析的數(shù)據(jù)。

• 例：從發(fā)票中提取{姓名、日期、金額}。

• 當模型需要實時數(shù)據(jù)或觸發(fā)代碼控制的動作（如搜索、取物、計算、通知或連接外部系統(tǒng)）時，函數(shù)調(diào)用（工具）。

• 為什么：工具讓模型能夠使用新鮮信息，而不僅僅是依賴訓練中學到的內(nèi)容。這意味著它可以查詢數(shù)據(jù)庫、調(diào)用API，或查找最新記錄而無需發(fā)明答案。模型提出動作，你的代碼決定是否運行，你保持清晰的審計軌跡。

• 例：模型調(diào)用 search_docs（） 來查找相關(guān)文本，然后調(diào)用 render_chart（） 來創(chuàng)建可視化，最后向用戶解釋結(jié)果。

• 當結(jié)果僅為敘述性時，如摘要或簡短回答，則使用純文本。

• 為什么：當沒有其他需要消耗輸出時，最簡單的路徑。

• 提取時，顯示匹配文本的簡短預覽。

• 在工具流中，顯示哪些工具運行了什么順序，然后把日志保留在服務器端。

4）解釋

向用戶展示步驟、工具和引用，讓他們對應用生成的AI輸出更有信心。

例子

• 附上簡短的“我用了什么”注釋，并注明來源標題或編號。以下復合模型展示了其答案，并附上了來源以保證清晰和信任。試試看這里。

• 提取時，顯示匹配文本的簡短預覽。

• 在工具流中，顯示哪些工具運行了什么順序，然后把日志保留在服務器端。

你會重復使用的核心模式

領(lǐng)域特定語言（DSL）：一種為特定領(lǐng)域設(shè)計的小型語言。在應用中，這通常意味著搜索篩選、沙盒SQL查詢、圖表規(guī)范或電子郵件模板。

安全運輸：測試、監(jiān)控與后備方案

發(fā)布前：

• 寫提示詞單元測試，檢查你預期的輸出格式。對于 JSON，斷言 required fields。對于純文本，請檢查關(guān)鍵詞、結(jié)構(gòu)、風格或拒絕短語。

• 從真實問題中建立一個小型評估集。包括預期結(jié)果和允許的拒絕情況。

• 在陰影模式或功能標志后運行，記錄所有內(nèi)容。

制作中需要跟蹤的事項：

• 延遲p50和p95

• 代幣的進出

• 模型和提示詞版本

• 工具調(diào)用的成功與失敗

• 無效的JSON速率

• 拒絕率

• 用戶編輯率（比較模型輸出與最終用戶文本）

• 引用正確性（核對引用來源）

你可以在 Groq 控制臺儀表盤中監(jiān)控這些信號，該儀表盤會提供日志、指標、使用情況和批處理分析，幫助你了解 AI 功能在真實工作負載中的表現(xiàn)。

有效的后備方案

• 如果任務無法回答，則用下一步回答“我不知道”。

• 如果結(jié)果看起來很長或很慢，就先流式播放部分結(jié)果，并保持界面響應式。

• 在關(guān)鍵時刻使用小模型再大模型路由，大多數(shù)請求從更小、更快、更便宜的模型開始。如果輸出不完整、不確定或被標記為過于復雜，則將同一請求升級到更大的模型。這樣可以節(jié)省日常任務的成本和延遲，同時仍能以更強大的性能處理復雜的邊緣情況。

常見陷阱與快速解決方法

• 太多上下文→只取你需要的東西然后重新排名。

• 讓模型直接接觸生產(chǎn)數(shù)據(jù)→始終使用工具和安全層。

• 所有事情都用聊天→很多工作更適合做簡單的提取器或路由器。

• 冗長的回答會降低成本→偏好簡潔的格式和結(jié)構(gòu)化字段。

• 沒有版本控制→每個日志行中都存儲提示ID和模型版本。

一份你今天就可以使用的簡短清單

• [ ] 寫一個清晰的系統(tǒng)提示和嚴格的JSON模式。

• [ ] 為任務選擇溫度，并保持上下文緊密。

• [ ] 在UI或數(shù)據(jù)庫更新前強制JSON驗證。

• [ ] 添加一個工具，記錄每次通話，并每周檢查失敗情況。

• [ ] 跟蹤延遲、令牌、提示符和模型版本、拒絕以及無效 JSON。

• [ ] 用功能旗幟和簡單的備選方案啟動。

別忘了

無聊的AI功能是可靠的AI功能，用戶感覺它們是隱形的——它們只是能正常工作。只讀你需要的內(nèi)容。用明確的規(guī)則來約束。用結(jié)構(gòu)化輸出和安全的工具行動。解釋一下發(fā)生了什么。從最小的實用功能開始。使用適合你使用場景的圖案。監(jiān)控一切。改進基于真實用戶行為，而非理論性能指標。目標不是打造令人印象深刻的AI演示。它是為了發(fā)布用戶每天都依賴的功能。