大模型集成避坑指南Prompt 工程不是万能药一、Prompt 工程的热度掩盖了系统工程的缺位2023 年到 2024 年Prompt 工程这个词被过度消费了。无数的教程和课程告诉你只要写好 Prompt就能让大模型成为你的全能助手。但将大模型集成到生产系统中时实际情况完全不同。在一个在线客服系统的 LLM 集成项目中我们投入了 3 周时间打磨 Prompt让模型在测试集上的回答准确率达到 87%。上线第一周用户的真实对话让准确率跌到了 61%。问题不在于 Prompt而在于真实用户会用大量口语、缩写、歧义表达、甚至包含多个问题的复合语句来提问。核心结论Prompt 工程解决的是在理想输入下如何获得理想输出。生产系统中真正的挑战是在混乱输入下如何保持可控输出。这是两个完全不同的问题域。二、坑一把 Prompt 当作传统代码的等价物传统代码的行为是确定性的同样的输入必定产生相同的输出。Prompt 的行为是概率性的同样的输入在不同时间可能产生不同的输出。把 Prompt 当作代码来编写、测试、上线会错失对整个系统的理解。// 这是一个常见的 LLM 集成代码 —— 看起来像是传统 API 调用 async function answerQuestion(question: string): Promisestring { const response await openai.chat.completions.create({ model: gpt-4o, messages: [ { role: system, content: 你是一个专业的客服助手。请根据以下规则回答问题 1. 如果不知道答案说我不确定让我转接人工客服 2. 回答要简洁不超过 100 字 3. 语气友好专业, }, { role: user, content: question }, ], }); return response.choices[0]?.message?.content ?? 系统繁忙请稍后再试; } // 这段代码的问题 // 1. 没有对输出做任何校验 —— LLM 可能无视字数限制输出 500 字 // 2. 没有处理我不知道以外的异常情况 // 3. 没有记录 token 消耗 // 4. 没有超时、重试、降级策略 // 5. 没有对用户输入做安全过滤正确的集成方式是一个多层管道而非单次 API 调用interface LLMPipeline { // 输入层清洗、分类、限流 inputGuard: InputGuard; // 检索层RAG 知识库增强 retriever: Retriever; // 生成层LLM 调用 重试 降级 generator: Generator; // 输出层校验、格式化、安全审查 outputGuard: OutputGuard; } // 一个实际可用的 LLM 集成管道 async function reliableLLMQuery( userInput: string, context: QueryContext ): PromiseLLMResponse { // Step 1: 输入安全审查 const sanitized await inputGuard.filter(userInput); if (!sanitized.safe) { return { type: rejected, reason: sanitized.reason }; } // Step 2: 检索相关知识RAG const knowledge await retriever.search(sanitized.text, { topK: 5 }); // Step 3: 构建 PromptSystem Context User const prompt buildPrompt({ system: SYSTEM_PROMPT, context: knowledge, user: sanitized.text, }); // Step 4: 调用 LLM带重试和降级 const rawOutput await callLLMWithRetry(prompt, { maxRetries: 2, timeout: 15000, fallbackResponse: 抱歉我暂时无法回答这个问题。, }); // Step 5: 输出质量校验 const validated await outputGuard.validate(rawOutput); if (!validated.pass) { return { type: fallback, content: FALLBACK_RESPONSE }; } // Step 6: 格式化并返回 return { type: success, content: validated.text }; }三、坑二忽视 RAG 的Garbage In, Garbage Out陷阱RAG检索增强生成被当作大模型集成的标准方案。但 RAG 的效果上限不是模型的能力而是知识库的质量。如果在检索阶段返回了 3 条不相关或低质量的文档即使 GPT-4 也无法给出正确答案。实际数据在一个企业内部知识库的 RAG 系统中检索阶段 Top-5 的文档相关性仅为 0.621 为完全相关。这意味着 40% 的情况下模型看到的上下文是低质量或无用的。// RAG 检索质量的关键影响因素 interface RAGQualityFactors { // 1. 文档切分策略按字符切分 vs 按语义切分 chunkStrategy: fixed-size | semantic | recursive; // 固定大小切分简单但会切断语义 chunkSize: number; // 通常 512-1024 tokens // 语义切分保留文档结构但实现复杂 chunkOverlap: number; // 切块间重叠的 token 数 // 2. Embedding 模型选择 embeddingModel: text-embedding-3-small | text-embedding-3-large | bge-large-zh; // 3. 检索策略 retrievalTopK: number; // 返回文档数 similarityThreshold: number; // 相似度阈值低于此值的结果舍弃 // 4. 重排序Re-ranking useReranker: boolean; rerankerModel: string; } // 检索质量的评估与优化 async function evaluateRAGQuality( testQueries: Array{ query: string; expectedDocs: string[] } ): Promise{ precisionAt5: number; recallAt5: number; mrr: number; // Mean Reciprocal Rank } { let sumPrecision 0; let sumRecall 0; let sumMRR 0; for (const test of testQueries) { const results await retriever.search(test.query, { topK: 5 }); const retrievedIds results.map(r r.docId); // Precision5: 检索到的相关文档数 / 5 const relevant retrievedIds.filter(id test.expectedDocs.includes(id)); sumPrecision relevant.length / 5; // Recall5: 检索到的相关文档数 / 全部相关文档数 sumRecall relevant.length / test.expectedDocs.length; // MRR: 第一个相关文档的排名的倒数 const firstRelevantRank retrievedIds.findIndex(id test.expectedDocs.includes(id)); sumMRR firstRelevantRank 0 ? 1 / (firstRelevantRank 1) : 0; } return { precisionAt5: sumPrecision / testQueries.length, recallAt5: sumRecall / testQueries.length, mrr: sumMRR / testQueries.length, }; }关键建议在切分文档前先评估不同切分策略字符、段落、语义对检索结果的影响。没有通用最优解。Embedding 模型的选择对中文影响尤其大。text-embedding-3对中文的支持不如专门的bge-large-zh。检索后加一个 Re-ranker 模型如bge-reranker做二次排序可以将 Top-5 相关性从 0.62 提升到 0.81。四、坑三幻觉问题的检查幻觉很多人认为可以通过另一个 Prompt 来检查 LLM 输出的幻觉让 LLM 生成回答后再用另一个 LLM 调用来检查回答是否准确。但这个方案的逻辑回路是用可能有幻觉的模型去检查可能有幻觉的模型。这不是一个可扩展的解决方案。// 不可靠的检查方案 —— 循环依赖 async function checkWithAI(output: string, context: string): Promiseboolean { const checkPrompt 以下是基于已知信息生成的回答。请判断回答是否与已知信息一致。 已知信息${context} 回答${output} 如果一致回复是如果不一致回复否。; const result await callLLM(checkPrompt); return result.includes(是); } // 问题如果这个检查 LLM 本身也产生幻觉呢务实的幻觉控制策略// 分层防御 —— 不依赖 AI 自检 interface HallucinationDefense { // 第一层约束输出格式减少自由发挥空间 enforceStructuredOutput(): void; // 第二层限制模型只能引用检索到的文档中的信息 restrictToRetrievedDocs(output: string, docs: string[]): { allCitationsValid: boolean; unsupportedClaims: string[]; }; // 第三层对关键事实做规则校验 validateFacts(output: string, expectedFacts: FactRule[]): { pass: boolean; violations: string[]; }; } // 原则如果回答涉及金额、日期、ID等结构化数据不用 LLM 生成用模板填充 function formatResponse(template: string, data: Recordstring, string): string { // 使用确定性模板 数据库数据而非让 LLM 自由生成 return template.replace(/\{\{(\w)\}\}/g, (_, key) data[key] || ); } RESPONSE_TEMPLATES { orderStatus: 您的订单 {{orderId}} 当前状态为 {{status}}预计 {{deliveryDate}} 送达。, refundInfo: 退款 {{amount}} 元将在 {{timeframe}} 个工作日内退回您的原支付账户。, };核心原则能动用规则引擎的就不要用 LLM能动用数据库查询的就不要用 LLM能动用模板的就不要用 LLM。LLM 只用于理解自然语言这一步后续的信息提取、校验、格式化用确定性逻辑。五、坑四忽视 Token 限制与实际需求的矛盾128K 的上下文窗口看似巨大但在以下场景下仍然不够连续对话累积每轮对话都带上前面的消息历史10 轮对话后上下文可能已超过 20K tokens。多文档检索5 篇 2000 字的文档 约 15000 tokens加上 system prompt 和用户消息轻松超过 20000 tokens。长文档摘要一篇 5 万字的文档即使 cut 到 128K 窗口内模型对文档中间部分的注意力也会显著下降。// Token 预算管理 class TokenBudgetManager { private budget: number; private systemPromptTokens: number; private used: number 0; constructor(modelMaxTokens: number, systemPrompt: string) { this.budget modelMaxTokens; this.systemPromptTokens estimateTokens(systemPrompt); this.used this.systemPromptTokens; } // 为检索文档分配 token 预算 allocateForDocs(maxDocTokens: number): number { const available this.budget - this.used - 1000; // 预留 1000 给用户输入和输出 return Math.min(maxDocTokens, available); } // 截断文档以适应预算 truncateDocs(docs: string[], budget: number): string[] { const result: string[] []; let remaining budget; for (const doc of docs) { const tokens estimateTokens(doc); if (tokens remaining) { result.push(doc); remaining - tokens; } else if (remaining 500) { // 剩余空间足够时截断文档 result.push(truncateByTokens(doc, remaining)); remaining 0; } if (remaining 0) break; } return result; } // 滑动窗口管理对话历史 trimConversationHistory( messages: Array{ role: string; content: string }, maxHistoryTokens: number ): Array{ role: string; content: string } { // 保留最近的对话直到达到 token 上限 const result: Array{ role: string; content: string } []; let used 0; // 从后往前取优先保留最近的对话 for (let i messages.length - 1; i 0; i--) { const tokens estimateTokens(messages[i].content); if (used tokens maxHistoryTokens) { result.unshift(messages[i]); used tokens; } else { break; } } return result; } }窗口利用的中间失落现象研究Lost in the Middle表明模型对上下文窗口中间位置的信息利用率最低。因此最重要的信息放在 System Prompt 的开头或结尾。检索到的文档按相关性降序排列最重要的文档放在最前面。六、坑五把 LLM 当作数据库一个典型错误用户问我的订单 12345 在哪里系统将这个问题直接扔给 LLM期望 LLM 知道答案。LLM 不具备实时数据它会根据训练数据中的类似模式生成一个听起来合理的答案——但极大概率是错误的。// 正确模式LLM 做意图理解 参数提取数据库做查询 async function handleOrderQuery(userMessage: string): Promisestring { // Step 1: 用 LLM 提取意图和参数结构化输出 const extraction await extractIntent(userMessage, { tools: [{ type: function, function: { name: query_order, description: 查询订单信息, parameters: { type: object, properties: { orderId: { type: string, description: 订单号 }, queryType: { type: string, enum: [status, location, refund], }, }, required: [orderId], }, }, }], }); // Step 2: 调用数据库获取真实数据 if (extraction.toolCall?.name query_order) { const orderData await db.orders.findById(extraction.toolCall.args.orderId); if (!orderData) { return 未找到订单 ${extraction.toolCall.args.orderId}; } // Step 3: 用模板 真实数据生成回复不用 LLM 自由生成 return formatOrderResponse(orderData, extraction.toolCall.args.queryType); } // Step 4: 如果意图不明确用 LLM 生成澄清问题 return 请问您想查询订单的什么信息例如物流状态、退款进度、或者订单详情; }五、总结大模型集成避坑的核心要点生产系统需要多层管道而非单次 API 调用输入安全审查 → RAG 检索 → LLM 生成 重试降级 → 输出质量校验每一层都是必要的防线。RAG 的瓶颈在检索而非生成优化切分策略和 Reranker 的效果提升远超调 PromptTop-5 相关性从 0.62 到 0.81 的差距决定了系统可用性。幻觉不能用另一个 LLM 解决用规则引擎做格式校验、数据库做事实校验、模板做结构化输出LLM 只负责理解这一步。Token 预算管理是基础设施关键信息放在上下文开头或结尾中间位置信息利用率最低Lost in the Middle。LLM 是翻译器不是数据库意图提取用 LLM事实查询用数据库不要让模型直接回忆结构化信息。可执行建议本周为 LLM 集成系统添加三层防护——InputGuard安全过滤、OutputGuard格式/事实校验、FallbackResponse降级兜底这三项投入产出比最高。七、总结大模型集成的核心避坑原则不要用解决确定性问题的思维解决概率性问题。Prompt 的调参需要系统的测试框架不是靠开发者直觉。RAG 的瓶颈在检索不在生成。在优化 Prompt 之前先优化你的文档切分策略、Embedding 模型和检索 Top-K。幻觉问题不能用另一个 LLM 来解决。用规则引擎做格式校验用数据库做事实校验用模板做结构化输出。LLM 只负责理解这一步。Token 预算管理是基础设施不是优化项。在设计阶段就建立 Token 消耗模型和上下文窗口分配策略。LLM 是翻译器不是数据库。用户意图 → LLM 提取结构化参数 → 数据库查询 → 模板 数据生成回答。不要让 LLM 直接回忆事实信息。常见误区错误假设正确认知优化 Prompt 花费 80% 工时好 Prompt 好输出系统架构比 Prompt 更重要用 LLM 做事实校验LLM 可以自我纠错规则 数据库做校验LLM 做理解RAG 向量检索 LLM检索到文档就够了切分策略和 Reranker 是核心上下文窗口大就够用128K 能装下一切中间位置信息丢失需要优先级排序LLM 回答用户所有问题LLM 是万能查询引擎LLM 做意图提取数据库做事实查询