如果你正在尝试将大语言模型LLM应用到实际业务中可能会遇到一个典型的困境模型在演示时表现惊艳但一旦集成到真实系统效果就大打折扣变得不稳定、不可靠甚至产生“幻觉”。问题出在哪里是模型不够强还是你的提示词写得不好问题的核心往往不在于模型本身而在于工程化的缺失。我们太容易沉迷于模型的“智能”却忽略了将其变为一个稳定、可维护、可扩展的生产级服务所需要的系统性工作。这就像拥有了一台顶级发动机却没有为它设计底盘、传动系统和控制系统它永远无法成为一辆能上路的车。“大语言模型工程”正是为了解决这个断层而生。它不是一个单一的工具而是一整套方法论、最佳实践和工具链的集合目标是将LLM从实验室的“玩具”转变为支撑业务的“引擎”。本文将作为这个系列的上半部分为你系统梳理LLM工程的核心框架、关键组件以及你首先需要搭建的基础设施。读完本文你将能清晰地规划出一条从模型原型到生产部署的工程化路径避开那些让项目中途夭折的“坑”。1. 从“演示级”到“生产级”LLM工程要解决的核心问题在深入技术细节之前我们必须先统一认知LLM工程的目标是什么它不仅仅是让API调用跑通。1.1 生产级LLM应用的四大挑战可靠性Reliability如何保证服务的99.9%可用性如何处理模型API的限流、失败和超时可控性Controllability如何确保模型的输出符合业务规则、安全规范和事实依据如何减少“幻觉”性能与成本Performance Cost如何优化提示词、缓存结果以减少Token消耗如何平衡响应速度与推理成本可观测性Observability如何监控模型的使用情况、性能指标和输出质量出了问题如何快速定位1.2 传统软件工程 vs. LLM工程传统软件开发围绕确定的逻辑和数据进行。而LLM开发是“概率性”的核心变成了如何通过提示词、上下文和数据去“引导”和“约束”一个不确定的黑盒。因此LLM工程引入了许多新的概念和工具提示词管理取代了部分硬编码的业务逻辑。向量数据库为模型提供动态、可扩展的外部知识。评估与评测需要新的指标如相关性、忠实度、无害性来衡量非确定性输出。编排框架用于组装复杂的多步骤AI工作流即智能体Agent。理解了这些挑战和差异我们才能有的放矢地构建我们的工程体系。2. LLM工程核心架构与关键组件一个典型的、面向生产的LLM应用架构可以抽象为以下几个层次自底向上分别是2.1 基础设施层这是所有能力的基石。计算资源GPU服务器用于微调或本地部署、充足的CPU和内存。模型服务决定是使用云端API如OpenAI GPT、 Anthropic Claude、国内各大模型平台还是私有化部署开源模型如Llama、Qwen、GLM。这是最重要的早期技术选型。向量数据库用于存储和检索文档嵌入Embeddings是实现“模型拥有最新、特定知识”的关键。常见选择有Chroma、Weaviate、Qdrant、Milvus等。2.2 核心能力层在基础设施之上我们需要构建一系列可复用的核心能力。嵌入模型将文本、图像等数据转换为向量。可以选择与LLM同系列或专用的嵌入模型如text-embedding-ada-002,BGE。提示词模板引擎管理复杂的提示词支持变量注入、条件逻辑和多轮对话上下文管理。RAG流水线检索增强生成Retrieval-Augmented Generation的完整流程包括文档加载、切分、向量化、检索、重排和最终生成。智能体框架提供定义工具、规划任务、执行动作、管理记忆的基础框架。LangChain、LlamaIndex是早期的代表性框架而Dify、FastGPT等则提供了更开箱即用的体验。2.3 应用与编排层利用核心能力组装成具体的业务应用。AI工作流编排将多个LLM调用、工具使用、条件判断等步骤可视化为一个工作流。例如一个客服工单自动处理流程先分类再检索知识库最后生成回复。应用界面Web UI、API接口、聊天机器人插件等。2.4 运维与治理层确保应用健康、安全、可控。日志与监控记录每次调用的输入、输出、Token用量、延迟、成本并设置告警。评估与测试建立评估数据集对模型输出进行自动化或人工评估持续迭代提示词和流程。安全与合规内容过滤、输出审核、权限控制、数据隐私保护。这个架构图为你提供了一个全景视角。接下来我们从最基础的环节开始搭建。3. 环境准备与核心工具选型在开始任何代码之前做好环境和工具的准备能事半功倍。3.1 Python环境LLM工程生态目前以Python为主。建议使用conda或pyenv创建独立的虚拟环境。# 使用 conda 创建环境 conda create -n llm-engineering python3.10 conda activate llm-engineering # 或使用 venv python -m venv llm-env source llm-env/bin/activate # Linux/Mac # llm-env\Scripts\activate # Windows3.2 关键Python库以下是构建一个基础RAG应用可能需要的核心库pip install openai anthropic # 主流商业API pip install langchain langchain-community langchain-openai # 流行编排框架 pip install chromadb # 轻量级向量数据库 pip install pypdf python-docx markdown # 文档加载器支持 pip install tiktoken # Token计数 pip install sentence-transformers # 本地嵌入模型 pip install streamlit # 快速构建演示UI可选注意langchain是一个强大的框架但学习曲线较陡。对于快速原型也可以考虑LlamaIndex更专注于RAG或直接使用各云平台的SDK。3.3 模型服务选择API vs. 本地部署这是第一个重大决策点。云端API推荐起步优点是无运维负担、性能稳定、模型新。缺点是持续成本、数据出境合规问题、可能受限流影响。你需要准备相应的API Key。本地部署优点是数据完全私有、无网络延迟、一次性硬件成本。缺点是需要较强的运维能力、硬件成本高、模型性能可能落后于顶尖API。可以使用ollama、vLLM、text-generation-inference等工具来简化本地服务部署。对于大多数团队从云端API开始验证业务逻辑再对核心场景考虑本地化是更稳妥的路径。4. 构建你的第一个生产级组件可管理的提示词系统提示词是驱动LLM的“代码”。但把提示词硬编码在Python字符串里是灾难的开始。我们需要系统化管理它。4.1 从硬编码到模板化假设我们有一个客服场景的提示词# 糟糕的做法硬编码 prompt f你是一个专业的客服助手。 请根据以下用户问题和相关知识生成友好、专业的回复。 用户问题{user_question} 知识内容{knowledge} 请用中文回复。更好的做法是使用模板# 使用 LangChain 的 PromptTemplate from langchain.prompts import PromptTemplate template 你是一个专业的{role}。 请根据以下用户问题和相关知识生成友好、专业的回复。 用户问题{question} 知识内容{context} 请用{language}回复。 prompt_template PromptTemplate.from_template(template) formatted_prompt prompt_template.format( role客服助手, questionuser_question, contextknowledge, language中文 )这样提示词逻辑就和业务代码分离了。4.2 进阶多轮对话与Few-Shot示例对于复杂任务我们需要在提示词中包含对话历史或示例。from langchain.prompts import ChatPromptTemplate, MessagesPlaceholder from langchain_core.messages import HumanMessage, AIMessage # 定义一个包含对话历史和系统指令的提示词模板 chat_template ChatPromptTemplate.from_messages([ (system, 你是一个乐于助人的助手。), MessagesPlaceholder(variable_namechat_history), # 动态插入历史消息 (human, {input}) ]) # 模拟一段对话历史 chat_history [ HumanMessage(contentPython里怎么读文件), AIMessage(content你可以使用 open() 函数例如with open(file.txt, r) as f: content f.read()) ] # 生成当前轮次的提示词 current_prompt chat_template.format_messages( chat_historychat_history, input那怎么写文件呢 ) # 现在 current_prompt 包含了系统指令、历史对话和当前问题可以发送给LLM4.3 提示词的版本管理与测试将重要的提示词存储在配置文件如YAML或数据库中并为其添加版本号。# prompts/customer_service.yaml prompts: - id: cs_general_reply_v1 template: | 你是一个专业的客服助手。 用户问题{question} 知识内容{context} 请根据知识生成回复如果知识中未提及请如实告知“我暂时没有找到相关信息”。 description: 通用客服回复模板V1 - id: cs_sentiment_analysis_v1 template: | 分析以下用户反馈的情感倾向积极/消极/中性和主要诉求。 反馈{feedback} 输出JSON格式{{sentiment: ..., main_concern: ...}} description: 情感分析模板V1在代码中加载并使用特定版本的提示词便于A/B测试和回滚。5. 知识库构建核心RAG流水线实战RAG是当前解决LLM知识陈旧和幻觉问题最主流的技术。构建一个健壮的RAG流水线是LLM工程的核心。5.1 第一步文档加载与切分文档需要被预处理成模型适合处理的“块”。from langchain_community.document_loaders import PyPDFLoader from langchain.text_splitter import RecursiveCharacterTextSplitter # 1. 加载文档 loader PyPDFLoader(path/to/your/product_manual.pdf) documents loader.load() # 2. 切分文档 text_splitter RecursiveCharacterTextSplitter( chunk_size500, # 每个块的大小字符数 chunk_overlap50, # 块之间的重叠避免上下文断裂 separators[\n\n, \n, 。, , , , , ] # 中文分隔符 ) chunks text_splitter.split_documents(documents) print(f将文档切分成了 {len(chunks)} 个块。)关键点chunk_size需要权衡。太小会丢失上下文太大会降低检索精度并增加成本。通常需要根据文档类型和模型上下文长度进行实验。5.2 第二步向量化与存储将文本块转换为向量嵌入并存入向量数据库。from langchain_openai import OpenAIEmbeddings from langchain.vectorstores import Chroma # 1. 初始化嵌入模型这里使用OpenAI API也可换成本地模型 embeddings OpenAIEmbeddings(modeltext-embedding-3-small, api_keyyour-key) # 2. 将切分好的文本块转换为向量并存储到ChromaDB # persist_directory 指定数据持久化目录 vectorstore Chroma.from_documents( documentschunks, embeddingembeddings, persist_directory./chroma_db ) vectorstore.persist() # 持久化到磁盘 print(向量知识库构建完成)5.3 第三步检索与生成用户提问时先从向量库中检索相关上下文再连同问题一起提交给LLM生成答案。from langchain_openai import ChatOpenAI from langchain.chains import RetrievalQA # 1. 加载已存在的向量库 vectorstore Chroma(persist_directory./chroma_db, embedding_functionembeddings) # 2. 将其转换为检索器可以配置检索模式如相似度分数阈值、返回数量 retriever vectorstore.as_retriever(search_kwargs{k: 4}) # 返回最相关的4个块 # 3. 创建LLM实例 llm ChatOpenAI(modelgpt-3.5-turbo, temperature0, api_keyyour-key) # 4. 创建RAG链 qa_chain RetrievalQA.from_chain_type( llmllm, chain_typestuff, # 将检索到的所有上下文“塞”进提示词 retrieverretriever, return_source_documentsTrue, # 返回源文档便于溯源 chain_type_kwargs{ prompt: prompt_template # 可以使用前面定义好的提示词模板 } ) # 5. 进行问答 question 你们的产品支持哪些支付方式 result qa_chain.invoke({query: question}) print(答案, result[result]) print(来源, [doc.metadata for doc in result[source_documents]])至此一个具备知识库查询能力的RAG应用就搭建起来了。但这仅仅是开始。6. 超越基础RAG提升效果的工程化技巧基础的RAG可能效果不佳以下是几个必须考虑的优化方向。6.1 检索优化元数据过滤在存储时为每个文本块添加元数据如章节标题、文档类型、日期。检索时可以进行过滤例如“只检索2023年之后的用户手册”。# 创建带元数据的文档 from langchain.schema import Document doc Document(page_content文本内容, metadata{source: manual_v2.pdf, section: 支付, year: 2023})重排序初步检索出N个相关块后使用一个更精细的模型或交叉编码器对它们进行重新排序将最相关的放在前面再送入LLM。6.2 提示词优化指令明确明确要求模型“基于给定的上下文回答”并“如果上下文未提供足够信息则回答不知道”。指定输出格式要求以JSON、列表或特定标记格式输出便于后续程序化处理。6.3 架构优化Hybrid Search混合搜索结合关键词搜索如BM25和向量搜索兼顾精确匹配和语义相似度。Query Rewriting查询重写在检索前先用LLM对用户原始问题进行优化、扩展或纠错提升检索命中率。# 简化的查询重写示例 rewrite_prompt 将以下用户问题改写为更适合知识库检索的版本。 原问题{original_question} 改写后的问题 # ... 调用LLM进行改写然后用改写后的问题进行检索7. 常见问题与排查指南在开发过程中你一定会遇到以下问题。问题现象可能原因排查步骤解决方案LLM回答“我不知道”或与知识库无关1. 检索失败未找到相关上下文。2. 提示词未强制要求基于上下文回答。1. 检查检索器返回的source_documents内容是否相关。2. 打印出发送给LLM的完整提示词检查上下文是否被正确插入。1. 优化检索调整chunk_size尝试混合搜索添加元数据过滤。2. 强化提示词加入“你必须且只能根据以下上下文回答”等强指令。回答包含事实性错误幻觉1. 检索到的上下文本身有误或不完整。2. 模型过度依赖自身知识忽略了上下文。1. 核对source_documents中的原文。2. 在提示词中降低temperature参数并强调“严格基于上下文”。1. 清理和校验知识库源数据。2. 使用“引用”格式要求模型在答案中注明出处段落编号便于人工复核。响应速度非常慢1. 嵌入模型调用或LLM调用网络延迟高。2. 检索的块k值太多导致提示词过长。3. 本地模型硬件不足。1. 使用监控工具记录各环节耗时。2. 统计每次请求的Token数量。1. 考虑部署本地嵌入模型减少网络调用。2. 减少k值或对检索结果进行摘要后再送入LLM。3. 对LLM响应进行流式输出Streaming以提升感知速度。向量数据库查询结果不准确1. 嵌入模型不适合当前领域文本。2. 文本切分不合理破坏了语义完整性。1. 在小样本上测试不同嵌入模型的效果。2. 人工检查一些查询对应的检索结果。1. 尝试领域适配的嵌入模型如针对中文优化的BGE。2. 尝试按段落、标题等语义边界进行切分而非单纯按字符数。处理长文档时提示词超长单个文档或检索到的总上下文超过模型Token限制。计算输入Token总数使用tiktoken库。1. 使用Map-Reduce或Refine等链式方法将长文档分而治之。2. 对检索到的上下文进行摘要或选择性提取。8. 迈向生产监控、评估与持续迭代一个没有监控和评估的LLM应用就像在黑夜中航行。8.1 核心监控指标性能指标请求延迟P50, P99、每秒查询率QPS、Token消耗速率。业务指标回答满意度可设计反馈按钮、任务完成率、人工接管率。成本指标按模型、按API、按项目维度的每日/每月成本。质量指标幻觉率需人工或模型辅助评估、检索相关性评分。8.2 实现基础日志与监控在每个LLM调用点记录关键信息。import logging import time from langchain.callbacks.base import BaseCallbackHandler class LoggingCallbackHandler(BaseCallbackHandler): def on_llm_start(self, serialized, prompts, **kwargs): self.start_time time.time() self.prompt prompts[0] logging.info(fLLM调用开始提示词长度{len(self.prompt)}) def on_llm_end(self, response, **kwargs): latency time.time() - self.start_time token_usage response.llm_output.get(token_usage, {}) if hasattr(response, llm_output) else {} logging.info(fLLM调用结束耗时{latency:.2f}sToken使用{token_usage}) # 可以将日志发送到监控系统如Prometheus, Datadog # 在调用链中使用 llm ChatOpenAI(..., callbacks[LoggingCallbackHandler()])8.3 构建评估流水线创建一组包含标准问题和期望答案的测试集定期运行跟踪模型表现的变化。# 一个简单的评估脚本示例 eval_questions [ {question: 产品保修期多久, expected_answer: 2年, context: ...}, # ... ] for item in eval_questions: result qa_chain.invoke({query: item[question]}) # 使用另一个LLM或规则判断 result[result] 与 item[expected_answer] 的匹配度 # 记录得分自动化评估能让你在修改提示词、更新知识库或切换模型后快速了解影响是正面还是负面。在第一部分我们系统性地梳理了LLM工程的价值、核心架构并深入实战了从环境搭建、提示词管理到RAG流水线构建的全过程。我们刻意将智能体这个更复杂的话题留到了下一篇。因为一个稳定、可靠、拥有良好知识基础的LLM服务是构建任何复杂智能体的前提。在下一篇中我们将探讨如何让LLM不仅“回答”还能“行动”即智能体开发。我们会深入任务规划、工具使用、记忆机制等核心概念并分析LangChain、AutoGen等框架的优劣帮助你设计出能自动完成多步骤任务的AI助手。现在你可以先着手将本文的RAG系统搭建起来并为其添加上监控和评估这是你通往高级LLM应用最坚实的基石。