1. 項(xiàng)目概述從零到一構(gòu)建LLM應(yīng)用的核心路徑最近和不少剛?cè)胄谢蛘呦朕D(zhuǎn)型做AI應(yīng)用的朋友聊天發(fā)現(xiàn)一個挺普遍的現(xiàn)象大家一提到LLM開發(fā)腦子里蹦出來的第一個詞往往是“調(diào)API”。這當(dāng)然沒錯調(diào)用大模型接口是開發(fā)的起點(diǎn)但如果你認(rèn)為LLM開發(fā)就等于寫個Prompt然后等結(jié)果那可能就錯過了這個領(lǐng)域最精彩、也最考驗(yàn)功力的部分。一個真正能落地、能產(chǎn)生價值的LLM應(yīng)用其開發(fā)流程遠(yuǎn)比想象中復(fù)雜它更像是在搭建一個精密的“智能體”系統(tǒng)需要將模型能力、業(yè)務(wù)邏輯、數(shù)據(jù)工程和用戶體驗(yàn)無縫地編織在一起。我把自己過去幾年從做簡單的聊天機(jī)器人到構(gòu)建復(fù)雜的企業(yè)級智能問答和流程自動化系統(tǒng)的經(jīng)驗(yàn)梳理了一下總結(jié)出了這個“LLM開發(fā)的整體流程”。這個流程不是某個框架的說明書而是一套通用的、可適配不同技術(shù)棧無論是用LangChain、LlamaIndex還是自己從零搭建的方法論。它涵蓋了從最初的靈光一現(xiàn)到最終產(chǎn)品上線的完整生命周期核心目標(biāo)是幫你建立起一個系統(tǒng)性的認(rèn)知框架知道在每一個階段應(yīng)該關(guān)注什么、解決什么問題、以及如何規(guī)避那些我踩過的坑。無論你是想用Dify這類低代碼平臺快速驗(yàn)證想法還是打算基于LangChain4j或原生SDK進(jìn)行深度開發(fā)這套流程的邏輯都是相通的。簡單來說這個流程解決的核心問題是如何將一個大模型的“潛力”穩(wěn)定、可靠、高效地轉(zhuǎn)化為解決特定實(shí)際問題的“能力”。它適合所有對LLM應(yīng)用開發(fā)感興趣的人無論是想了解全貌的產(chǎn)品經(jīng)理、尋求技術(shù)轉(zhuǎn)型的開發(fā)者還是正在規(guī)劃AI戰(zhàn)略的團(tuán)隊(duì)負(fù)責(zé)人。接下來我們就拋開那些浮于表面的概念直接進(jìn)入實(shí)戰(zhàn)環(huán)節(jié)一步步拆解這個過程中的關(guān)鍵步驟、技術(shù)選型背后的邏輯以及那些只有真正做過才知道的細(xì)節(jié)。2. 核心流程全景與階段定義如果把LLM應(yīng)用開發(fā)比作建造一座房子那么“整體流程”就是你的施工藍(lán)圖。它告訴你打地基、立結(jié)構(gòu)、裝修、通水電的先后順序和依賴關(guān)系。盲目開工很可能最后發(fā)現(xiàn)衛(wèi)生間沒留管道或者承重墻位置不對。LLM開發(fā)同樣如此缺乏流程指導(dǎo)很容易陷入“反復(fù)調(diào)Prompt不見效”或者“效果不錯但一上線就崩”的困境。我通常將LLM開發(fā)的全流程劃分為五個核心階段它們之間存在強(qiáng)烈的順序依賴和迭代關(guān)系問題定義與范圍框定明確你要用LLM解決什么具體問題以及它的邊界在哪里。方案設(shè)計(jì)與技術(shù)選型根據(jù)問題設(shè)計(jì)整體架構(gòu)并選擇合適的技術(shù)組件模型、框架、工具等。數(shù)據(jù)準(zhǔn)備與處理為你的應(yīng)用準(zhǔn)備“燃料”包括數(shù)據(jù)的收集、清洗、增強(qiáng)和向量化。開發(fā)、評估與迭代核心的構(gòu)建階段實(shí)現(xiàn)功能并通過系統(tǒng)的評估不斷優(yōu)化。部署、監(jiān)控與維護(hù)讓應(yīng)用跑起來并確保其長期穩(wěn)定、可靠地運(yùn)行。這五個階段并非嚴(yán)格的瀑布模型而是一個螺旋式上升的循環(huán)。特別是在“開發(fā)-評估”階段可能會根據(jù)結(jié)果回溯到“方案設(shè)計(jì)”甚至“問題定義”進(jìn)行調(diào)整。下面我們就深入每一個階段看看具體要做什么以及為什么這么做。2.1 階段一問題定義——從“能用AI”到“用AI解決問題”這是所有環(huán)節(jié)中最重要卻最容易被忽視的一步。很多團(tuán)隊(duì)一開始的命題就是“我們要做一個AI客服”這過于寬泛。正確的問題定義應(yīng)該像手術(shù)刀一樣精準(zhǔn)。首先必須將模糊的需求轉(zhuǎn)化為可衡量的任務(wù)。例如“AI客服”可以具體拆分為任務(wù)類型是問答回答產(chǎn)品規(guī)格、分類將用戶問題分給不同部門、總結(jié)生成聊天記錄摘要還是流程執(zhí)行根據(jù)用戶指令觸發(fā)退款輸入輸出輸入是純文本、帶結(jié)構(gòu)的工單、還是包含圖片的反饋輸出需要是結(jié)構(gòu)化數(shù)據(jù)JSON、自然語言還是需要調(diào)用某個API性能指標(biāo)如何定義“好”是回答的準(zhǔn)確率Accuracy、召回率Recall還是用戶滿意度CSAT對于總結(jié)任務(wù)可能需要用ROUGE分?jǐn)?shù)對于分類任務(wù)看F1-score。其次嚴(yán)格框定范圍Scoping。LLM不是萬能的明確什么不做和明確做什么同等重要。你需要定義拒答范圍當(dāng)問題超出知識庫、涉及敏感信息或用戶意圖模糊時系統(tǒng)應(yīng)該如何優(yōu)雅地處理是直接告知“我無法回答”還是引導(dǎo)用戶澄清問題這一步直接決定了后續(xù)開發(fā)中很多邊界邏輯的設(shè)計(jì)。實(shí)操心得在這個階段我強(qiáng)烈建議制作一個“問題-答案”對Q-A Pair的樣本集哪怕只有20-30對。這個樣本集應(yīng)包含你預(yù)期的典型問題、邊緣案例和必須拒答的問題。它將成為后續(xù)技術(shù)方案討論、Prompt編寫和效果評估的黃金標(biāo)準(zhǔn)。沒有這個錨點(diǎn)所有關(guān)于“效果好壞”的討論都會變成空中樓閣。2.2 階段二方案設(shè)計(jì)——在“快速驗(yàn)證”與“長期穩(wěn)健”間權(quán)衡有了清晰的問題定義接下來就要設(shè)計(jì)技術(shù)方案。這里的關(guān)鍵決策是如何讓LLM獲得完成特定任務(wù)所需的知識和能力目前主流有三種范式選擇哪一種取決于你的任務(wù)性質(zhì)和數(shù)據(jù)基礎(chǔ)。范式一提示工程Prompt Engineering這是最簡單直接的起點(diǎn)。通過精心設(shè)計(jì)提示詞Prompt引導(dǎo)基礎(chǔ)大模型如GPT-4、Claude-3完成特定任務(wù)。它適合邏輯推理、創(chuàng)意生成、文本轉(zhuǎn)換等通用能力較強(qiáng)的任務(wù)。優(yōu)點(diǎn)開發(fā)速度極快成本低能直接利用最先進(jìn)模型的能力。缺點(diǎn)嚴(yán)重依賴模型本身的“知識”無法注入私有、實(shí)時或領(lǐng)域特定數(shù)據(jù)存在“幻覺”編造信息風(fēng)險(xiǎn)提示詞可能不穩(wěn)定不同版本模型效果波動。技術(shù)選型參考直接調(diào)用OpenAI、Anthropic等廠商的API或部署開源模型如Llama 3、Qwen的API。范式二檢索增強(qiáng)生成RAG這是當(dāng)前企業(yè)級應(yīng)用最主流的架構(gòu)。核心思想是不讓LLM“憑空回憶”而是為它提供一個“外部知識庫”。當(dāng)用戶提問時先從知識庫中檢索相關(guān)文檔片段然后將“問題檢索到的上下文”一起交給LLM生成答案。優(yōu)點(diǎn)可以有效結(jié)合私有數(shù)據(jù)答案來源可追溯減少幻覺知識更新方便更新文檔庫即可。缺點(diǎn)架構(gòu)復(fù)雜度高涉及檢索系統(tǒng)向量數(shù)據(jù)庫、文本分塊、向量化等多個組件檢索質(zhì)量直接影響最終答案效果。技術(shù)選型參考框架LangChain/LangGraph功能全面生態(tài)好LlamaIndex專注于RAG優(yōu)化。向量數(shù)據(jù)庫Pinecone全托管簡單Weaviate開源功能強(qiáng)Milvus/Qdrant開源高性能。嵌入模型OpenAI的text-embedding-3系列開源的BGE-M3、Snowflake Arctic Embed。范式三微調(diào)Fine-Tuning當(dāng)你有大量高質(zhì)量的任務(wù)特定數(shù)據(jù)如成千上萬的客服對話記錄且希望模型徹底掌握某種風(fēng)格或復(fù)雜領(lǐng)域知識時可以考慮對基礎(chǔ)模型進(jìn)行微調(diào)。優(yōu)點(diǎn)能深度定制模型行為在特定任務(wù)上可能達(dá)到比Prompt或RAG更好的效果和更低延遲。缺點(diǎn)數(shù)據(jù)準(zhǔn)備成本極高訓(xùn)練有算力成本和門檻可能損失模型的部分通用能力迭代周期長。技術(shù)選型參考使用Hugging Face的TRL、PEFT庫進(jìn)行高效微調(diào)或使用云廠商的微調(diào)服務(wù)如Azure OpenAI Fine-tuning。如何選擇我的經(jīng)驗(yàn)法則是先嘗試Prompt Engineering。如果簡單Prompt就能達(dá)到80分效果就沒必要上更復(fù)雜的架構(gòu)。如果需要結(jié)合最新、私有文檔毫不猶豫選擇RAG。它是目前平衡效果、成本和復(fù)雜度的最佳實(shí)踐。只有當(dāng)你需要模型學(xué)習(xí)一種極其復(fù)雜的模式或風(fēng)格且有海量標(biāo)注數(shù)據(jù)時才考慮微調(diào)。對于大多數(shù)應(yīng)用RAG 少量Prompt優(yōu)化足以應(yīng)對。在這個階段你還需要設(shè)計(jì)應(yīng)用的整體架構(gòu)圖。例如一個典型的RAG應(yīng)用可能包含前端界面 - 后端API服務(wù) - Prompt編排/Agent邏輯 - 向量檢索服務(wù) - 知識庫文檔處理流水線。明確每個組件的職責(zé)和技術(shù)選型。3. 數(shù)據(jù)工程構(gòu)建智能的基石無論你選擇哪種范式數(shù)據(jù)都是LLM應(yīng)用的“燃料”。低質(zhì)量的數(shù)據(jù)輸入必然導(dǎo)致低質(zhì)量的輸出。這個階段的工作往往決定了項(xiàng)目上限。3.1 數(shù)據(jù)收集與清洗為知識庫“備料”對于RAG應(yīng)用你需要構(gòu)建知識庫。數(shù)據(jù)來源可能是內(nèi)部文檔Word、PDF、PPT、Confluence頁面、數(shù)據(jù)庫、甚至爬取的公開網(wǎng)頁。格式處理使用像Unstructured、PyPDF2、pdfplumber這樣的庫將各種格式文件轉(zhuǎn)換為純文本。注意處理頁眉頁腳、目錄、圖片中的文字OCR等。清洗去除無關(guān)字符亂碼、特殊符號、標(biāo)準(zhǔn)化格式日期、數(shù)字、處理換行和空格。一個干凈的文本是高質(zhì)量嵌入向量的前提。3.2 文本分塊Chunking藝術(shù)與科學(xué)的結(jié)合這是RAG中最關(guān)鍵也最微妙的一步。你不能把整本100頁的說明書扔給模型也不能把每一句話都單獨(dú)作為一塊。分塊的目標(biāo)是讓檢索回來的“上下文”既完整又聚焦。固定大小分塊最簡單的辦法比如每256或512個字符分一塊。缺點(diǎn)是可能割裂完整的語義比如一句話被切成兩半。按分隔符分塊按照段落\n\n、標(biāo)題、句號等自然邊界進(jìn)行分塊。更符合閱讀習(xí)慣。智能分塊使用語義分割模型或遞歸分塊算法試圖保持語義單元的完整性。這是目前的主流趨勢。重疊分塊在塊與塊之間設(shè)置一定的重疊字符如50個字符確保邊界信息不會丟失提高檢索召回率。注意事項(xiàng)分塊大小沒有黃金標(biāo)準(zhǔn)必須通過實(shí)驗(yàn)確定。我的經(jīng)驗(yàn)是對于事實(shí)性問答塊可以小一些200-500字符確保精準(zhǔn)對于需要理解上下文的分析性任務(wù)塊可以大一些500-1000字符。一定要在評估階段測試不同分塊策略對最終答案質(zhì)量的影響。3.3 向量化與索引讓機(jī)器“理解”文本分塊后的文本需要轉(zhuǎn)換成向量一組數(shù)字才能被向量數(shù)據(jù)庫快速檢索。這個過程由嵌入模型完成。嵌入模型選擇通用場景下OpenAI的text-embedding-3-small在效果和成本間取得了很好平衡。對中文或特定領(lǐng)域可以測試BGE-M3等開源模型。關(guān)鍵是要確保你的檢索模型和生成模型LLM在語義空間上對齊即它們對“相似”的理解一致。索引將文本塊和對應(yīng)的向量存入向量數(shù)據(jù)庫。數(shù)據(jù)庫會為這些向量創(chuàng)建索引如HNSW、IVF以實(shí)現(xiàn)快速近似最近鄰搜索。一個常見的數(shù)據(jù)處理流水線示例使用LangChainfrom langchain_community.document_loaders import DirectoryLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_openai import OpenAIEmbeddings from langchain_community.vectorstores import Chroma # 1. 加載文檔 loader DirectoryLoader(./docs/, glob**/*.pdf) documents loader.load() # 2. 分塊 text_splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap50, separators[\n\n, \n, 。, , , , , 、, , ] ) chunks text_splitter.split_documents(documents) # 3. 向量化并存儲 embeddings OpenAIEmbeddings(modeltext-embedding-3-small) vectorstore Chroma.from_documents( documentschunks, embeddingembeddings, persist_directory./chroma_db )4. 核心開發(fā)與迭代循環(huán)這是將設(shè)計(jì)落地的階段核心工作是實(shí)現(xiàn)智能體Agent邏輯和建立評估飛輪。4.1 智能體邏輯與工具調(diào)用現(xiàn)代LLM應(yīng)用很少是“一問一答”這么簡單。它需要具備規(guī)劃、記憶、工具使用的能力這就是智能體。規(guī)劃讓LLM將復(fù)雜問題拆解為步驟。例如用戶問“公司去年在華東區(qū)的銷售情況如何”智能體應(yīng)規(guī)劃為1. 理解“去年”和“華東區(qū)”的定義2. 調(diào)用銷售數(shù)據(jù)查詢工具3. 對查詢結(jié)果進(jìn)行分析總結(jié)。記憶保存對話歷史讓模型擁有上下文。分為短期記憶當(dāng)前會話和長期記憶可存入向量庫的過往重要信息。工具調(diào)用這是智能體能力的延伸。LLM可以生成JSON格式的請求調(diào)用外部工具如計(jì)算器、日歷數(shù)據(jù)庫查詢API內(nèi)部業(yè)務(wù)系統(tǒng)接口網(wǎng)絡(luò)搜索代碼執(zhí)行器LangChain工具調(diào)用 vs. LLM原生Function Calling 這是一個常見困惑點(diǎn)。兩者目標(biāo)一致但層級不同。LLM原生Function Calling是模型本身的能力如GPT-4 Turbo。你定義好函數(shù)的名稱、描述和參數(shù)格式模型會在生成文本時判斷是否需要調(diào)用函數(shù)并輸出符合格式的JSON。速度主要受模型本身推理速度和網(wǎng)絡(luò)延遲影響。LangChain工具調(diào)用是一個更高層次的框架。它封裝了與LLM的交互、工具的描述、輸出的解析以及工具的執(zhí)行流程。它可以使用LLM的原生Function Calling作為底層實(shí)現(xiàn)也可以使用其他方式如提示詞引導(dǎo)。速度受LLM調(diào)用延遲、工具本身執(zhí)行時間以及LangChain框架開銷的共同影響。開發(fā)建議初期可以直接利用LangChain/LangGraph快速搭建智能體原型它提供了豐富的內(nèi)置工具和編排模式。在對性能和可控性有極致要求時可以考慮基于LLM原生Function Calling自研更輕量的編排邏輯。4.2 評估體系告別“感覺不錯”擁抱“數(shù)據(jù)驅(qū)動”“我覺得答案挺好”是LLM開發(fā)的大忌。必須建立客觀、可量化的評估體系。評估什么檢索質(zhì)量檢索到的文檔塊是否與問題相關(guān)可以用命中率、平均相關(guān)分?jǐn)?shù)來衡量。生成質(zhì)量答案是否準(zhǔn)確、完整、無害這是最難的。如何評估生成質(zhì)量人工評估黃金標(biāo)準(zhǔn)但成本高、速度慢。適用于構(gòu)建核心測試集。基于LLM的自動評估用另一個LLM如GPT-4作為裁判根據(jù)標(biāo)準(zhǔn)對答案進(jìn)行打分?？焖?、可規(guī)?；嬖诓门心Ｐ捅旧淼钠??？梢栽O(shè)計(jì)詳細(xì)的評分規(guī)則Rubric例如事實(shí)準(zhǔn)確性0-5分、完整性0-3分、清晰度0-2分?；鶞?zhǔn)測試使用公開數(shù)據(jù)集如HotpotQA、TriviaQA來測試系統(tǒng)的通用能力。構(gòu)建評估流水線將你的樣本測試集、評估標(biāo)準(zhǔn)、評估方法人工或自動自動化。每次對系統(tǒng)做出更改調(diào)整Prompt、修改分塊大小、更換模型后都運(yùn)行一遍評估流水線用數(shù)據(jù)說話看指標(biāo)是上升還是下降。4.3 提示詞工程與迭代優(yōu)化在RAG架構(gòu)中Prompt通常由以下幾部分組成系統(tǒng)指令定義模型的角色、回答風(fēng)格和限制。上下文從向量庫檢索到的相關(guān)文檔塊。用戶問題原始問題?；卮鸶袷揭罄纭坝弥形幕卮稹薄ⅰ叭绻畔⒉蛔阏埫鞔_說明”。優(yōu)化是一個循環(huán)過程修改Prompt - 運(yùn)行評估 - 分析失敗案例 - 找到根因 - 再次修改。常見的優(yōu)化技巧包括指令細(xì)化不要說“請準(zhǔn)確回答”而要說“請嚴(yán)格依據(jù)提供的上下文信息回答如果上下文中沒有明確依據(jù)請說‘根據(jù)已知信息無法回答該問題’”。少樣本提示在Prompt中提供1-2個高質(zhì)量的輸入輸出示例引導(dǎo)模型模仿。思維鏈對于復(fù)雜問題要求模型“逐步思考”這能顯著提升推理任務(wù)的準(zhǔn)確性。輸出格式化要求模型以特定格式如JSON、Markdown列表輸出便于后端解析。5. 部署、監(jiān)控與持續(xù)改進(jìn)開發(fā)完成并通過評估后就進(jìn)入了生產(chǎn)化階段。這里的關(guān)鍵詞是“穩(wěn)定”和“可觀測”。5.1 部署模式與架構(gòu)考量后端服務(wù)化將你的LLM應(yīng)用封裝成RESTful API或gRPC服務(wù)。使用FastAPI、Flask等框架。注意處理異步請求因?yàn)長LM調(diào)用可能很慢。配置管理將模型API密鑰、Prompt模板、參數(shù)溫度、top_p等抽取為配置文件或環(huán)境變量便于不同環(huán)境開發(fā)、測試、生產(chǎn)切換。緩存策略對頻繁出現(xiàn)的相同或相似查詢結(jié)果進(jìn)行緩存能極大降低成本和延遲?？梢允褂肦edis等內(nèi)存數(shù)據(jù)庫。限流與降級對API接口實(shí)施限流防止濫用。當(dāng)主要模型服務(wù)如GPT-4不可用時應(yīng)有降級方案如切換到備用模型或返回簡化結(jié)果。5.2 可觀測性與監(jiān)控上線不是終點(diǎn)而是開始。你需要知道你的應(yīng)用在生產(chǎn)環(huán)境表現(xiàn)如何。日志記錄詳細(xì)記錄每一次請求的輸入用戶問題、檢索到的上下文、LLM的完整Prompt、輸出、耗時、Token使用量、消耗成本。這些日志是后續(xù)分析和優(yōu)化的寶貴數(shù)據(jù)。關(guān)鍵指標(biāo)監(jiān)控性能指標(biāo)請求延遲P50 P99、每秒查詢率QPS、錯誤率。質(zhì)量指標(biāo)通過抽樣進(jìn)行人工評估或?qū)Σ糠终埱筮\(yùn)行自動評估監(jiān)控答案質(zhì)量的波動。成本指標(biāo)每日/每月的Token消耗費(fèi)用特別是當(dāng)使用按量付費(fèi)的云服務(wù)時。反饋閉環(huán)在應(yīng)用界面提供“反饋”按鈕讓用戶標(biāo)記答案是否有用。這些反饋數(shù)據(jù)可以用于后續(xù)的模型微調(diào)或Prompt優(yōu)化。5.3 持續(xù)迭代與知識庫維護(hù)知識庫更新業(yè)務(wù)文檔是動態(tài)變化的。需要建立知識庫的定期或觸發(fā)式更新流程新文檔加入 - 自動處理清洗、分塊、向量化- 更新向量數(shù)據(jù)庫索引。注意處理好舊數(shù)據(jù)的失效問題。問題分析與歸因定期分析監(jiān)控日志和用戶反饋將問題歸類檢索失敗問題未命中相關(guān)文檔。需優(yōu)化分塊策略、嵌入模型或查詢改寫。生成失敗檢索到了文檔但答案不好。需優(yōu)化Prompt或考慮微調(diào)。拒答不當(dāng)該答的沒答或不該答的亂答。需調(diào)整拒答邏輯和系統(tǒng)指令。A/B測試對于重大的策略變更如切換模型、使用新的Prompt模板可以采用A/B測試將部分流量導(dǎo)向新版本客觀比較效果后再全量上線。6. 常見陷阱與實(shí)戰(zhàn)避坑指南根據(jù)我自己的踩坑經(jīng)驗(yàn)這里總結(jié)幾個高頻問題及其解決方案。陷阱一幻覺問題依舊嚴(yán)重即使使用了RAG模型仍可能基于檢索到的上下文“編造”細(xì)節(jié)。排查與解決檢查檢索質(zhì)量首先確認(rèn)檢索到的前3個文檔塊是否真的高度相關(guān)。如果不相關(guān)問題在檢索端。強(qiáng)化指令在Prompt中明確且強(qiáng)硬地要求“僅使用提供的上下文”“上下文未提及的內(nèi)容不要猜測”。引用溯源要求模型在答案中引用它所依據(jù)的上下文句子或段落編號。這不僅增加了可信度也便于人工復(fù)核。陷阱二檢索效果不穩(wěn)定時好時壞排查與解決查詢改寫/擴(kuò)展用戶的原始查詢可能不夠精準(zhǔn)?？梢韵扔靡粋€小模型對查詢進(jìn)行改寫或擴(kuò)展。例如將“怎么報(bào)銷”自動擴(kuò)展為“員工差旅費(fèi)用報(bào)銷流程和所需材料”?；旌纤阉鞑灰灰蕾囅蛄肯嗨菩运阉髡Z義搜索。結(jié)合關(guān)鍵詞搜索如BM25進(jìn)行加權(quán)融合。語義搜索負(fù)責(zé)召回相關(guān)概念關(guān)鍵詞搜索負(fù)責(zé)鎖定精確術(shù)語。重排序向量搜索召回前K個結(jié)果如K20后使用一個更精細(xì)的交叉編碼器模型對它們進(jìn)行重新排序選出最相關(guān)的前N個如N5作為上下文。這能顯著提升精度。陷阱三處理長文檔或復(fù)雜問題時上下文不足LLM有上下文窗口限制如128K但有時即使窗口足夠塞入太多無關(guān)信息也會干擾模型。排查與解決Map-Reduce將長文檔分成多個部分讓模型分別總結(jié)每個部分Map再總結(jié)這些部分摘要得到最終答案Reduce。層次化檢索先檢索到文檔級別再定位到該文檔內(nèi)的具體相關(guān)段落。智能體規(guī)劃對于復(fù)雜問題讓智能體主動規(guī)劃多次檢索和工具調(diào)用分步解決而不是一次性注入所有信息。陷阱四延遲高、成本失控排查與解決緩存如前所述實(shí)現(xiàn)請求-響應(yīng)緩存。模型分級對于簡單查詢?nèi)鐔柡?、簡單事?shí)問答使用便宜快速的小模型如GPT-3.5-Turbo對于復(fù)雜分析才調(diào)用大模型如GPT-4。流式輸出對于長文本生成使用服務(wù)器發(fā)送事件SSE實(shí)現(xiàn)流式傳輸讓用戶盡快看到首字提升體驗(yàn)。預(yù)算與告警在云服務(wù)商處設(shè)置每月預(yù)算和告警防止意外費(fèi)用。陷阱五Agent陷入循環(huán)或執(zhí)行錯誤動作排查與解決明確停止條件在Agent的規(guī)劃指令中明確最大步驟數(shù)。例如“最多執(zhí)行5個步驟如果仍未解決則終止并總結(jié)當(dāng)前進(jìn)展”。工具驗(yàn)證在執(zhí)行工具調(diào)用前對參數(shù)進(jìn)行基礎(chǔ)驗(yàn)證如類型、范圍。工具執(zhí)行后檢查返回結(jié)果是否異常。人工審核環(huán)對于高風(fēng)險(xiǎn)操作如發(fā)送郵件、修改數(shù)據(jù)庫設(shè)計(jì)“人工確認(rèn)”環(huán)節(jié)Agent生成待執(zhí)行命令后需經(jīng)用戶或管理員確認(rèn)后才真正執(zhí)行。LLM開發(fā)的旅程是一個在不確定性中尋找確定性的過程。它沒有銀彈任何一個成功的應(yīng)用背后都是對業(yè)務(wù)場景的深刻理解、嚴(yán)謹(jǐn)?shù)墓こ虒?shí)踐和持續(xù)的數(shù)據(jù)驅(qū)動的優(yōu)化。這套整體流程的價值就在于它提供了一個從混沌到有序的行動地圖。記住最重要的不是一開始就設(shè)計(jì)一個完美的系統(tǒng)而是建立一個能夠快速試錯、度量和改進(jìn)的循環(huán)。從一個小而具體的問題開始跑通這個流程獲得正反饋然后再逐步擴(kuò)展它的邊界和能力。在這個過程中你積累的不僅僅是代碼更是對“如何讓AI真正有用”的直覺和理解。