从去年开始越来越多的团队把大语言模型接进业务系统从客服问答、内容生成到代码辅助落地场景越来越丰富。但真正把 LLM 用起来之后问题也随之而来模型幻觉怎么控制上下文窗口为什么总是不够推理速度慢、成本高怎么优化本地部署到底需要什么配置ComfyUI 和 LLM 到底能不能装在不同电脑上这些问题的答案往往分散在官方文档、社区帖子和技术博客里缺少一份从原理到实践的整理。这篇文章会把 LLM 落地过程中最常见的工程问题系统梳理一遍结合真实场景给出排查思路和可用代码示例。无论是刚开始接触大模型的新手还是已经在做 LLM 应用开发的工程师都能在文章里找到值得对照参考的内容。1. 背景与核心概念1.1 大语言模型解决什么问题大语言模型Large Language ModelLLM是一类基于海量文本数据训练的深度学习模型核心能力是理解和生成自然语言。它的本质是一个概率模型通过预测下一个 token词元来生成连贯文本。相比传统的关键词匹配、规则引擎或者小型机器学习模型LLM 最明显的优势在于理解语义而非单纯匹配关键词可以处理同义改写和模糊表达。零样本和少样本学习能力强不需要为每个任务单独训练模型。具备上下文理解能力能够在多轮对话中保持话题连贯。可以完成多种任务问答、摘要、翻译、代码生成、结构化信息抽取。但“能力强”不等于“没有限制”。实际接入业务时工程师最先感受到的往往不是模型有多聪明而是它在某些场景下有多不可控。比如答非所问、一本正经地胡说八道、格式不稳定、响应太慢、费用飙升——这些问题单独看像是 bug本质上却是大模型当前技术阶段的固有特性。1.2 LLM 应用栈的基本组成一个完整的 LLM 应用通常由以下部分组成模块作用常见选择模型层负责文本生成GPT-4、Claude、Qwen、DeepSeek、Llama推理服务部署模型并暴露 APIvLLM、Ollama、TGI、SGLang编排层管理提示词、调用模型、处理上下文LangChain、LlamaIndex、Dify向量数据库存储和检索知识片段Milvus、Qdrant、Chromadb、pgvectorAgent 框架让模型调用工具、完成多步任务Function Calling、AutoGPT、ReAct图中的每一层都会产生特有的问题。模型层有幻觉和上下文限制推理服务有性能和并发问题编排层有提示词失控和链路稳定性问题向量数据库有检索不准的问题。后面几个章节会逐一拆解。2. 环境准备与版本说明2.1 本文的示例环境由于 LLM 生态迭代速度非常快不同版本的依赖变化很大这里先说明本文示例环境。实际使用时请根据项目自身情况调整重点是理解配置思路。操作系统Ubuntu 22.04 / macOS 14 均可 Python3.10 或 3.113.12 部分依赖可能还不兼容 模型Qwen2.5-7B-Instruct开源本地部署 推理框架Ollama 或 vLLM本例以 Ollama 为主 向量库ChromaDB纯 Python适合原型验证 编排层LangChain 0.3.x 或直接调用 OpenAI 兼容 API对于不想本地部署模型的场景也可以使用云端 API代码逻辑基本一致只是 base_url 和 API Key 不同。2.2 Python 依赖安装建议使用虚拟环境避免污染系统 Python。mkdir llm-problems-demo cd llm-problems-demo python3 -m venv .venv source .venv/bin/activate pip install openai langchain langchain-community chromadb需要说明的是LangChain 0.3 版本之后拆分比较细部分模块的导入路径发生了变化。如果安装时提示模块不存在优先检查是不是版本过新导致的路径变动而不是代码写错。3. LLM 的核心问题拆解这一节是全文的重点。下面把 LLM 应用开发中最高频的四类核心问题展开讲解结合原理说明为什么会出现这些问题。3.1 幻觉问题模型一本正经地胡说八道幻觉Hallucination是 LLM 最被诟病的问题之一。表现为模型生成的内容流畅自然但事实错误或者完全编造。产生原因训练数据本身不完整或包含错误信息。模型本质是概率分布没有真正理解“事实”的概念。生成时为了流畅性会在信息不足时“补全”内容。提示词中给了模型过大的发挥空间。缓解手段RAG检索增强生成先检索相关资料再让模型基于资料回答。约束兜底话术模型不确定时明确要求回答“未知”而不是猜测。降低温度参数Temperature 调低让生成更保守。后置校验关键信息用规则或小型模型二次校验。一个简单的提示词兜底示例prompt 你是企业内部客服助手。 请严格根据下面的资料回答问题。如果资料中没有相关信息请直接回答“资料中未找到相关信息”不要自行推测。 资料内容 {context} 用户问题{question} 3.2 上下文长度限制记不住前面的对话每个模型都有输入 token 上限比如 4K、8K、32K、128K 不等。当对话轮次变多历史消息占满上下文后早期信息会被截断模型就“忘记”了之前的约定。常见表现多轮对话后模型开始答非所问。明明在前面已经告诉过模型的信息它转过头就“失忆”。直接报错context length exceeded。解决思路方案说明适用场景滑动窗口只保留最近 N 轮对话客服、闲聊等轻上下文场景历史摘要将早期对话压缩成摘要长对话、需要追溯早期信息精简系统提示词减少固定占用的 token所有场景外部记忆把关键信息写入向量库或数据库知识问答、个性化助手滑动窗口是工程中最常见的做法。核心思路是超出窗口时最早的消息优先丢弃。from collections import deque class SlidingWindowChatMemory: def __init__(self, max_messages10): self.messages deque(maxlenmax_messages) def add_message(self, role, content): self.messages.append({role: role, content: content}) def get_messages(self): return list(self.messages)3.3 推理速度与成本响应慢、费用高模型参数量越大推理耗时越长、单位成本越高。这是硬件算力和商业 API 定价共同决定的事实。性能瓶颈点预填充阶段Prefill处理输入的 prompt计算量大。解码阶段Decode逐 token 生成存在串行依赖。并发请求显存不足时排队吞吐量下降。优化策略模型层面选择更小但满足需求的模型如 7B 或 13B 替代 70B。推理层面使用 vLLM 的 PagedAttention、连续批处理或使用 TensorRT-LLM 做算子优化。输入层面精简系统提示词减少无关历史。输出层面限制max_tokens避免模型长篇大论。缓存层面对高频提问做语义缓存相同问题直接返回结果。3.4 模型选型困境开源还是闭源、本地还是云端选型没有标准答案关键在于业务约束。当团队数据敏感度较高、必须内网部署时开源模型是主要选择。当业务需要最强推理能力且可以接受数据出域时商业 API 更省心。一个简单选型判断表判断维度倾向开源本地部署倾向商业 API数据隐私要求高低算力资源充足有限效果要求中等高预算方式前期硬件投入按量付费技术团队规模有推理优化能力偏应用层开发需要注意的是开源模型和商业模型之间的效果差距正在快速缩小尤其是中文场景下Qwen 系列和 DeepSeek 系列已经具备很强的实力。选型时可以先用商业 API 验证效果再在需要私密部署时迁移到开源模型。4. 完整实战案例基于 RAG 解决领域问答幻觉前面讲了不少理论这一章做一个可以直接上手的实战项目。需求是企业内部文档问答核心目标是通过 RAG 方式降低模型幻觉让回答有据可依。4.1 项目结构设计llm-rag-demo/ ├── data/ │ └── company_manual.md # 企业制度文档 ├── ingest.py # 文档切片 写入向量库 ├── query.py # 检索 生成回答 └── requirements.txt # 依赖清单4.2 编写文档入库脚本先准备一份简单的文档内容可以替换成自己的资料。为了保证向量检索效果文档需要先做切片。# 文件路径ingest.py from langchain_community.document_loaders import TextLoader from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_community.embeddings import HuggingFaceEmbeddings from langchain_community.vectorstores import Chroma # 1. 加载文档 loader TextLoader(data/company_manual.md, encodingutf-8) documents loader.load() # 2. 文档切片 text_splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap50, separators[\n\n, \n, 。, , , , ] ) docs text_splitter.split_documents(documents) print(f文档切片数量: {len(docs)}) # 3. 向量化并写入向量库 embedding HuggingFaceEmbeddings(model_nameBAAI/bge-small-zh-v1.5) vectordb Chroma.from_documents( documentsdocs, embeddingembedding, persist_directory./chroma_db ) vectordb.persist() print(向量库写入完成)这里选用的BAAI/bge-small-zh-v1.5是中文场景下比较常用的 embedding 模型体积小、效果不错。第一次运行会自动下载模型文件需要保持网络畅通。4.3 编写问答查询脚本# 文件路径query.py from langchain_community.embeddings import HuggingFaceEmbeddings from langchain_community.vectorstores import Chroma embedding HuggingFaceEmbeddings(model_nameBAAI/bge-small-zh-v1.5) vectordb Chroma( persist_directory./chroma_db, embedding_functionembedding ) def get_relevant_context(question, k3): results vectordb.similarity_search(question, kk) return \n.join([doc.page_content for doc in results]) def ask_llm(question, context): # 这里以 Ollama 为例也可以换成其他兼容 OpenAI 协议的 API from openai import OpenAI client OpenAI( base_urlhttp://localhost:11434/v1, api_keyollama ) messages [ {role: system, content: 你是企业文档问答助手请严格根据参考资料回答。}, {role: user, content: f参考资料\n{context}\n\n问题{question}} ] response client.chat.completions.create( modelqwen2.5:7b, messagesmessages, temperature0.3, max_tokens500 ) return response.choices[0].message.content if __name__ __main__: question input(请输入问题) context get_relevant_context(question) answer ask_llm(question, context) print(\n--- 回答 ---) print(answer)4.4 运行与验证# 先启动 Ollama 并拉取模型 ollama pull qwen2.5:7b # 入库 python ingest.py # 提问 python query.py预期效果当问题在文档中有明确答案时模型会基于检索结果作答并且不会引入资料之外的内容。如果问题不在文档中模型会返回类似“资料中未找到相关信息”的兜底回答而不是强行编造。4.5 结果说明这个案例体现了 RAG 的两个核心收益答案有据可依降低了幻觉概率。更新知识不需要重新训练模型只需更新向量库。代价是需要维护多一套检索链路。检索质量直接影响回答质量如果切片太大容易混入无关内容如果切片太小上下文信息容易丢失。后续可以通过调节chunk_size和k值做针对性优化。5. 常见问题与排查思路LLM 应用开发的报错千奇百怪但很多问题背后有共通的原因。下面整理了一份高频问题排查表。问题现象常见原因解决思路模型回答事实错误幻觉、缺少可靠资料引入 RAG增加兜底话术降低温度对话超过上下文限制报错历史累积过多加滑动窗口做历史摘要首字延迟过长输入 prompt 太长、模型太大精简 prompt换更小模型使用 vLLM并发一高就超时或OOM显存不足、未做并发控制增加批处理、限制并发、换大显存机器中文效果差embedding 模型或基座模型不适合中文换中文优化模型如 bge、Qwen向量检索结果不相关切片策略不合理调短 chunk增大 overlap换 embedding 模型API 调用报 401API Key 错误或未设置环境变量检查 key 和 base_urlLangChain 导入报错版本更新导致路径变化去官方文档查当前版本的导入路径5.1 “ComfyUI 与 LLM 必须在同一台电脑上吗”这是一个比较常见的误区。ComfyUI 主要用于 Stable Diffusion 等图像生成模型的节点式编排LLM 负责文本理解和生成两者不是同一个系统。它们可以安装在同一台电脑上但这不是强制要求。实际架构取决于你的使用场景如果只是本地玩耍ComfyUI 和 LLM 装在同一台机器最方便模型加载和文件交换都在本地完成。如果是做服务化部署ComfyUI 和 LLM 完全可以拆到不同机器。ComfyUI 走 HTTP APILLM 走 OpenAI 兼容 API两者之间通过接口通信即可。举个例子一个典型的服务化架构用户请求 - LLM服务服务器A - 识别的文字/意图 - ComfyUI API服务器B - 生成图片 - 返回给用户这种情况下两端只需要网络互通即可不存在“必须同机”的约束。如果遇到类似需求优先考虑的是延迟和带宽图像传输和 API 调用频率是否在可接受范围内。相反如果两台机器跨公网且传输频繁内网部署会更稳定。5.2 排查思路三步走遇到问题时推荐按以下顺序排查先复现最小场景。去掉 RAG、去掉 Agent、去掉复杂提示词仅仅调用一次模型确认基础链路是否正常。再做模块隔离。分别测试文档加载、向量检索、提示词拼接、模型推理这几个环节哪一步输出异常就优化哪一步。最后做参数调整。不要一次改多个变量每次只改一个参数并记录效果。这套方法对大多数 LLM 项目都适用。很多问题看似在模型层调试后才发现是上游的文本切割或检索环节出了问题。6. 最佳实践与工程建议6.1 提示词版本管理提示词不是写一次就能一劳永逸的。业务调整、模型换版、badcase 修复都会让提示词频繁变化。建议把提示词模板放到独立配置文件或数据库中而不是散落在代码里。# 文件路径prompts.yaml customer_service: system: | 你是企业客服助手。请根据以下资料回答问题。 如果资料不包含答案请回答“抱歉我没有找到相关信息。” temperature: 0.2 max_tokens: 300 code_review: system: | 你是资深代码评审专家。请从正确性、可维护性、性能三个方面给出评审意见。 temperature: 0.1 max_tokens: 800这样修改提示词不需要重新发布代码同时也方便做 A/B 效果对比。6.2 配置管理原则涉及模型地址、API Key、模型名称等配置一律使用环境变量或配置中心不要硬编码在代码里。export LLM_API_BASEhttp://localhost:11434/v1 export LLM_API_KEYollama export LLM_MODEL_NAMEqwen2.5:7b如果是多个环境开发、测试、生产建议拆分配置文件避免误连错误的模型服务。6.3 日志与可观测性LLM 应用的黑盒特性决定了日志比普通应用更重要。每次请求至少记录以下信息完整的 prompt注意脱敏避免记录敏感信息。模型返回内容。token 消耗量输入/输出分开。响应耗时。温度、max_tokens 等生成参数。检索到的上下文片段和相似度分数。有了这些信息才能在 badcase 出现后复盘定位。否则以模型输出的随机性问题很难复现。6.4 安全边界LLM 应用的安全问题不能忽视尤其是面向外部用户的场景。提示词注入用户可能在输入中夹带“忽略之前的指令”等攻击语句。应对方法包括对系统提示词做强约束、对输入内容做过滤、在系统提示词中明确边界。数据泄露不要将敏感数据直接拼进 prompt。优先通过 RAG 控制资料可见范围并对日志做脱敏处理。权限控制模型能访问的工具和知识库必须有权限隔离。用户能问什么、能调用哪些工具应该在应用层严格校验而不是信任模型自行判断。输出校验模型生成的内容需要合规校验后才可使用必要时叠加审核组件。6.5 性能优化与成本控制从工程角度性能和成本是同一个问题的两面。推荐按下面的优先级处理减少不必要的输入长度。历史摘要、精简提示词是最低成本的优化手段。引入语义缓存。高频问题直接命中缓存省去模型调用。模型分层。简单问题走小模型复杂问题才调大模型。批量异步化。不要求实时返回的场景改为异步任务处理。7. 总结与学习路线这篇文章梳理了 LLM 应用落地中最常见的几类问题幻觉、上下文限制、推理速度、成本、模型选型并用一个完整的 RAG 项目演示了如何降低幻觉、让回答有据可依。此外整理了排查思路、提示词管理、配置管理、日志安全等工程侧的注意事项。对于初学者建议按下面的路线继续深入先掌握提示词工程理解模型如何理解指令。再上手 RAG学会管理和利用外部知识。然后研究 Agent/Function Calling让模型具备工具调用能力。最后接触推理优化和模型微调解决性能和领域适配问题。每个阶段都值得花时间做小项目验证。比如先做一个简单的文档问答再逐步加入多轮对话、工具调用、权限控制在迭代过程中慢慢体会模型的边界和优化方向。大模型技术更新很快但核心的问题框架相对稳定掌握了排查方法论后续无论模型怎么换解决问题的路径都不会变。