1. 从一次“成功”的线上故障说起
上个月，我们团队上线了一个新的智能客服功能，后端用 FastAPI 封装了一个大模型（LLM）的调用接口。上线前，我们做了充分的测试，接口响应码（HTTP Status Code）一直是 200，返回的 JSON 结构也完全符合规范。一切看起来都很完美。然而，上线第一天，我们就收到了大量用户投诉，说客服的回答“前言不搭后语”、“答非所问”，甚至出现了几例令人啼笑皆非的“胡说八道”。我们紧急排查日志，发现所有出问题的请求，接口返回的 HTTP 状态码依然是 200。
这个场景，相信很多正在或计划将 LLM 集成到产品中的开发者都遇到过，或者即将遇到。HTTP 200 这个状态码，在传统的 API 设计中，几乎等同于“成功”的代名词。但在 LLM 的世界里，它成了一个极具迷惑性的“烟雾弹”。它只代表网络请求和基础框架层面成功了，至于 LLM 这个“黑盒”内部究竟产出了什么，200 状态码对此一无所知。直接把这个“成功”返回的结果展示给用户，无异于在产品质量的钢丝上跳舞。
今天，我们就来深入聊聊，为什么 LLM 接口返回了 200，其结果却远不能直接交付给用户。这背后涉及从模型能力边界、提示工程（Prompt Engineering）的脆弱性，到 API 设计、内容安全过滤和用户体验设计的完整链路。我会结合我们踩过的坑，以及业内常见的实践，为你拆解其中的关键环节和应对策略。
2. HTTP 200 的“谎言”：LLM 输出质量的四重不确定性
当你的 FastAPI 服务成功调用了 OpenAI、DeepSeek 或任何其他 LLM 提供商的 API，并收到了一个 200 响应时，这仅仅意味着通信链路是通畅的。对于 LLM 返回的文本内容本身，至少存在以下四重不确定性，是 200 状态码无法揭示的。
2.1 内容相关性的“跑偏”
这是最常见的问题。用户问“如何重置密码”，LLM 可能开始滔滔不绝地讲述计算机密码学的发展史。虽然语法通顺、内容“正确”，但完全偏离了用户的核心意图。这种“跑偏”往往源于提示词（Prompt）设计不够精准，或者上下文（Context）中包含了干扰信息。例如，在 RAG（检索增强生成）系统中，如果检索到的参考文档质量不高或相关性弱，LLM 就很容易被带偏。
注意：相关性判断不能依赖 LLM 自评（比如在 Prompt 里加一句“请判断你的回答是否相关”），因为 LLM 倾向于肯定自己的输出。需要设计独立的相关性校验模块，或通过更精细的 Prompt 工程来约束。
2.2 事实准确性的“幻觉”
LLM 的“幻觉”问题已是老生常谈。它可能信心十足地编造一个不存在的产品功能、一段错误的历史日期，或一条虚假的引用文献。对于知识密集型或要求高准确性的场景（如客服、教育、医疗咨询），直接输出这类内容会造成严重的信任危机。HTTP 200 不会告诉你，返回的文本里掺杂了多少“想象”的成分。
应对策略对比表
| 策略 | 原理 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|
| 提示词约束 | 在 Prompt 中强调“基于已知信息回答”、“不知道请明确说明”。 | 实现简单，零成本。 | 约束力弱，模型仍可能“自信地”幻觉。 | 对准确性要求不高的闲聊、创意生成。 |
| 检索增强生成 | 先检索权威知识库，再将检索结果作为上下文提供给 LLM。 | 大幅提升事实准确性，答案可溯源。 | 系统复杂度高，依赖检索质量。 | 知识问答、文档摘要、智能客服。 |
| 后验事实核查 | LLM 生成答案后，用另一个流程（如二次检索、规则匹配）验证关键事实点。 | 准确性高，能发现隐蔽错误。 | 增加延迟和计算成本，核查范围难界定。 | 金融、法律、医疗等高风险领域。 |
2.3 内容安全与合规的“红线”
这是最危险的陷阱。LLM 可能生成包含偏见、歧视、暴力、色情或政治敏感的内容。主流 LLM API（如 OpenAI, Anthropic）都在服务端内置了安全过滤器（Moderation），但并非万无一失。此外，过滤器的标准可能与你业务的具体合规要求存在差异。一个返回 200 的响应，完全可能携带让你的应用下架的风险内容。我们曾遇到一个案例，用户用隐晦的方式提问，绕过了模型的基础安全过滤，产生了不合规的联想内容。
关键检查点：
- 服务端过滤：确认你使用的 LLM 提供商是否提供并开启了 Moderation API，或在调用前使用独立的审核服务。
- 业务规则过滤：建立你自己的关键词、正则表达式黑名单，对输出进行二次过滤。
- 上下文审查：在多轮对话中，审查整个对话历史的安全性是必要的，因为危险内容可能由用户和模型共同“演绎”出来。
2.4 格式与结构的“失控”
你期望 LLM 返回一个干净的 JSON 对象用于前端渲染，但它可能额外输出了解释性文字：“好的，以下是你需要的 JSON：”；或者 JSON 格式残缺，缺少引号、括号不匹配。你期望它用列表分点回答，它却写成了一段散文。虽然内容本身可能没问题，但糟糕的结构化输出会直接导致你的下游解析逻辑崩溃。FastAPI 的 Pydantic 模型验证能帮你捕获明显的 JSON 解析错误（此时可能返回 422），但对于“JSON 包裹在自然语言中”这种半结构化错误，它无能为力。
实操技巧：对于需要严格结构化输出的场景，强烈推荐使用 LLM 的“函数调用”或“JSON 模式”功能。例如，OpenAI 的response_format参数可以强制指定返回 JSON 对象，这从协议层面降低了格式失控的风险。如果所用模型不支持此功能，则必须在 Prompt 中进行极其严格的规定，并在后端添加鲁棒的解析和清洗逻辑，比如用正则表达式提取 JSON 部分。
3. 超越状态码：构建 LLM 输出质量的“防火墙”
既然不能相信 200，我们就必须自己建立一套质量评估与保障体系。这套体系应该在结果返回给用户之前，像一道道防火墙一样进行拦截和过滤。
3.1 设计鲁棒的提示工程与上下文管理
很多输出质量问题，根源在输入。一个健壮的 Prompt 是第一道防线。
- 角色与任务清晰化：不要只说“你是一个助手”。要说“你是一个专注于解决用户软件技术问题的客服专家，必须基于提供的产品文档进行回答，对于文档未提及的功能，应明确告知用户‘暂无此信息，建议联系人工客服’”。
- 结构化输出指令：明确要求格式。例如：“请用以下 JSON 格式回答：
{“answer”: “...”, “confidence”: 0-1, “source_doc_ids”: [...]}”。对于不支持 JSON 模式的模型，可以要求使用特定标记，如“用‘---’分隔每个要点”。 - 上下文长度与质量管控：LLM 有上下文窗口限制（如 128K tokens）。向模型“投喂”超长或无关的上下文，不仅浪费资源，还会稀释关键信息，导致输出质量下降。必须实现智能的上下文窗口管理，例如通过 Embedding 相似度筛选最相关的文档片段，或对长文档进行分块摘要。
一个常见的误区：试图用一个万能 Prompt 解决所有问题。更好的做法是根据不同的任务类型（问答、总结、创作、代码生成）设计不同的 Prompt 模板，并在调用时动态选择和填充。
3.2 实施输出内容的后处理校验链
在 LLM 生成文本后、返回给用户前，插入一系列自动化的校验步骤，构成一个“校验链”。
- 格式校验：首先，用程序验证输出是否符合预期的结构（如 JSON 解析是否成功，是否包含必填字段）。失败则触发重试或降级方案。
- 基础安全与合规过滤：使用关键词、正则表达式或轻量级文本分类模型，对输出进行快速扫描，过滤明显违规内容。这一步要快，延迟要低。
- 相关性打分：计算用户问题（Query）与 LLM 回答（Answer）的 Embedding 相似度。如果相似度低于阈值（如 0.7），则认为答案可能不相关，需要记录告警或触发人工审核。可以使用
text-embedding-ada-002这类轻量级模型。 - 事实性核查：对于关键事实陈述，可以尝试从回答中提取实体或主张，然后反向查询你的知识库或可信源，进行验证。这一步成本较高，可针对高风险领域或高置信度需求开启。
- 逻辑与一致性检查：对于较长的回答，可以提示另一个 LLM（或同一 LLM 的不同调用）扮演“评审员”，检查回答是否自相矛盾、是否完全回应了问题。
# 一个简化的后处理校验链示例（伪代码） async def process_llm_response(user_query: str, llm_raw_output: str) -> dict: # 1. 格式清洗与提取 cleaned_output = extract_structured_content(llm_raw_output) # 例如，剥离自然语言，提取JSON # 2. 格式验证 if not validate_structure(cleaned_output): # 格式错误，触发重试或返回友好错误 return await retry_or_fallback(user_query) # 3. 安全过滤 if safety_filter.contains_risk_content(cleaned_output['answer']): log_risk_event(user_query, cleaned_output) return {"answer": "您的问题可能涉及敏感内容，我无法回答。", "flagged": True} # 4. 相关性检查 relevance_score = calculate_similarity(user_query, cleaned_output['answer']) if relevance_score < RELEVANCE_THRESHOLD: # 记录低相关性日志，供后续优化Prompt或分析 log_low_relevance(user_query, cleaned_output, relevance_score) # 可以选择返回答案，但添加低置信度标记；或触发二次确认 cleaned_output['low_relevance_warning'] = True # 5. （可选）关键事实核查 if needs_fact_check(cleaned_output): fact_check_result = await fact_check_service.verify(cleaned_output['answer']) cleaned_output['fact_check'] = fact_check_result return cleaned_output3.3 定义清晰的用户端降级与交互策略
即使经过层层校验，仍有可能输出不完美或不确定的结果。这时，如何与用户沟通，就成了用户体验的关键。
- 置信度传达：不要只返回一个“是”或“否”的答案。可以附带一个置信度分数或定性描述（如“高置信度”、“仅供参考”）。例如，在答案旁显示一个“可信度：80%”的标签，或更柔和地表述为“根据现有信息，这可能是一个解决方案...”。
- 提供溯源：如果答案来源于特定文档（如在 RAG 中），提供引用来源的链接或片段。这不仅能增加可信度，也给了用户进一步验证的途径。
- 设计安全边界回复模板：当内容被安全过滤器拦截，或相关性极低时，不要返回一个生硬的“错误”或空结果。准备一系列友好的、引导性的回复模板，如：“这个问题可能超出了我的当前能力范围，您可以尝试重新表述您的问题，或联系我们的客服人员获取帮助。”
- 启用用户反馈机制：在答案下方提供“有帮助/没帮助”的按钮，或“报告错误”的入口。这些反馈数据是优化 Prompt、调整校验阈值和发现新问题模式的宝贵资源。
4. 从 API 设计到监控：构建可信 LLM 服务的系统工程
将 LLM 集成到产品中，不是一个简单的接口调用问题，而是一个系统工程。我们需要从 API 设计层面就开始考虑对不确定性的管理。
4.1 设计抗脆弱的 LLM 封装 API
你的 FastAPI 接口不应该只是 LLM 提供商 API 的简单代理。它应该是一个增加了业务逻辑层、错误处理层和降级策略的智能网关。
响应体设计示例：
{ "success": true, // 业务层面的成功，区别于 HTTP 200 "data": { "answer": "具体的回答文本...", "sources": ["doc_id_123", "doc_id_456"], // 溯源 "confidence": 0.85 // 置信度 }, "meta": { "model": "gpt-4-turbo", "tokens_used": 456, "has_risk_content": false, "needs_human_review": false // 是否需要人工审核标记 }, "warnings": [ // 非致命性警告 "答案相关性评分较低", "部分信息未能核实" ] }这样的设计，让前端能清晰地知道如何处理结果：高置信度的答案可以直接展示；低置信度的可以弱化显示或附加提示；标记了needs_human_review的可以转入人工队列。
4.2 实施全链路的可观测性
LLM 的“黑盒”特性使得监控和调试尤为困难。你需要比传统应用更细致的监控点。
- 输入输出日志：在遵守隐私政策的前提下，记录关键的 Prompt、用户问题、完整的模型输出。这对于事后分析“诡异”回答至关重要。务必对敏感信息进行脱敏处理。
- 性能与成本指标：监控每次调用的延迟、Token 消耗、计费情况。这有助于发现 Prompt 设计是否低效，或是否有异常流量。
- 质量指标：上文提到的相关性分数、安全过滤触发率、用户负反馈率等，应作为核心业务指标进行监控和告警。例如，当某个场景下的低相关性告警突然增多，可能意味着知识库需要更新或 Prompt 需要调整。
- 错误与限流处理：LLM 提供商 API 会返回各种错误，如
429（请求过多）、400（无效请求，如上下文超长）、503（服务过载）。你的封装 API 必须有完善的错误处理、重试和优雅降级机制（例如，切换到更便宜的模型，或返回缓存的通用答案）。
4.3 建立持续的迭代优化闭环
LLM 应用不是一次部署就完事的。你需要一个基于数据驱动的持续优化流程。
- 收集反馈数据：通过用户反馈按钮、客服工单、会话录音分析等方式，持续收集模型出错的案例。
- 分析根因：定期（如每周）回顾错误案例，分类归因：是 Prompt 问题、上下文问题、知识缺失，还是模型本身的局限性？
- 实验与评估：针对发现的问题，设计新的 Prompt 变体、调整上下文策略或引入新的后处理规则。通过 A/B 测试或离线评估（使用积累的测试用例集）来衡量改进效果。
- 部署与监控：将验证有效的改进部署上线，并密切监控相关质量指标的变化。
这个循环能让你系统地提升 LLM 服务的可靠性和用户满意度，而不是在问题出现时被动救火。
回到我们开头的那个故障案例。事后分析发现，问题出在上下文管理上。为了追求“全面”，我们向模型传入了过多的、有时效性的产品变更日志，导致模型在回答基础操作问题时，被过时或无关的变更信息干扰，产生了混淆和错误答案。我们的修复方案是：重构了上下文检索逻辑，优先保证核心文档的准确性，并为动态信息建立了独立的、有版本管理的知识片段。同时，我们在接口响应中加入了答案的“来源文档”字段，方便快速定位问题。从此，HTTP 200 对我们而言，不再是一个终点，而只是一个起点——一个标志着更复杂、更重要的质量保障流程开始的信号。
