企业官网建设流程全解析

如果你正在尝试将大语言模型（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 python=3.10 conda activate llm-engineering # 或使用 venv python -m venv llm-env source llm-env/bin/activate # Linux/Mac # llm-env\Scripts\activate # Windows

3.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="客服助手", question=user_question, context=knowledge, 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_name="chat_history"), # 动态插入历史消息 ("human", "{input}") ]) # 模拟一段对话历史 chat_history = [ HumanMessage(content="Python里怎么读文件？"), AIMessage(content="你可以使用 open() 函数，例如：with open('file.txt', 'r') as f: content = f.read()") ] # 生成当前轮次的提示词 current_prompt = chat_template.format_messages( chat_history=chat_history, input="那怎么写文件呢？" ) # 现在 current_prompt 包含了系统指令、历史对话和当前问题，可以发送给LLM

4.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_size=500, # 每个块的大小（字符数） chunk_overlap=50, # 块之间的重叠，避免上下文断裂 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(model="text-embedding-3-small", api_key="your-key") # 2. 将切分好的文本块转换为向量并存储到ChromaDB # persist_directory 指定数据持久化目录 vectorstore = Chroma.from_documents( documents=chunks, embedding=embeddings, 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_function=embeddings) # 2. 将其转换为检索器，可以配置检索模式（如相似度分数阈值、返回数量） retriever = vectorstore.as_retriever(search_kwargs={"k": 4}) # 返回最相关的4个块 # 3. 创建LLM实例 llm = ChatOpenAI(model="gpt-3.5-turbo", temperature=0, api_key="your-key") # 4. 创建RAG链 qa_chain = RetrievalQA.from_chain_type( llm=llm, chain_type="stuff", # 将检索到的所有上下文“塞”进提示词 retriever=retriever, return_source_documents=True, # 返回源文档，便于溯源 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. 常见问题与排查指南

在开发过程中，你一定会遇到以下问题。

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(f"LLM调用开始，提示词长度：{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(f"LLM调用结束，耗时：{latency:.2f}s，Token使用：{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应用最坚实的基石。