最近在复盘我们团队自己的AI项目时我最大的感受是大家往往在Demo阶段冲得很快模型选型、Prompt试调、效果展示都很有热情可一旦进入生产环境问题就接二连三地暴露出来——数据质量差、接口不稳定、效果不可控、迭代没有方向。恰好这时候看到一条关于腾讯AI的讨论有观点认为“AI竞争不是短跑熬得久比起得早更重要”。先不评判企业战略这句话放到AI工程实践里确实是一个值得反复咀嚼的提醒。这篇文章不聊公司竞争也不做行业点评。我想把“AI竞争是长跑”这个观点拆解成AI应用开发中的真实技术问题环境怎么搭、数据怎么管、模型怎么部署、服务怎么上线、效果怎么持续优化。无论你是刚接触AI开发的初学者还是已经在做AI应用落地的后端工程师都可以从这篇文章里找到一套可以照着做的工程思路。文章会以一个完整的RAG问答服务为例从零搭建可运行的代码并补充生产环境最常遇到的坑和排查方法。如果你正打算把AI能力沉淀到自己的业务系统里这篇文章可以作为一份工程化落地参考。1. 背景与核心概念1.1 从“起得早”到“熬得久”AI项目的定位AI行业每隔一段时间就会有一个新概念、新模型、新工具出现。今天刷到一个模型效果超越上一代明天看到一个Agent框架又更新了能力很容易让团队产生一种“必须立刻跟上”的焦虑。但实际做项目时你会发现“起得早”只是拿到了入场券真正决定项目成败的是后面漫长得多的阶段。一个AI应用要稳定运行在生产环境需要持续处理数据变化、模型效果退化、用户反馈、成本波动、安全风险等一堆工程问题。这些问题不是靠某个新模型就能解决的而是靠一套能长期运转的迭代机制去托底。所以“熬得久”并不是一句鸡汤它对应的是AI项目的真实生命周期管理能力。一个模型Demo可能只需要几天但一个AI服务要跑上一年并且越跑越好需要的是数据治理、评测体系、监控告警、灰度回滚等工程能力。1.2 AI应用开发的三阶段我习惯把AI应用开发分成三个阶段第一阶段是实验验证阶段。这个阶段的目标很简单用最小成本验证“大模型能不能解决这个问题”。你可以用现成的API写几条Prompt跑几个测试样本看看效果方向是否可行。这个阶段通常不需要复杂工程。第二阶段是工程化阶段。当效果基本满足要求后就要把脚本变成服务。这里需要处理并发、鉴权、日志、限流、缓存、向量数据库、模型部署、接口稳定性等一系列问题。很多团队就死在这个阶段因为Demo和线上服务之间隔着一条巨大的工程鸿沟。第三阶段是持续迭代阶段。服务上线只是开始接下来你需要收集线上数据建立评测集持续优化Prompt、检索策略、模型版本甚至要做A/B测试和灰度发布。没有这个阶段AI应用的效果会随着数据漂移和模型更新逐渐退化。这三个阶段中往往第二个和第三个阶段消耗的时间远超第一个阶段。这正是“熬得久”的工程含义。1.3 为什么技术领先不等于业务领先单独看模型效果技术领先确实存在但放到业务里技术领先并不等于产品体验领先。一个效果略好但响应要5秒、成本翻倍、时不时抽风的模型往往不如一个效果稳定、延迟可控、成本可接受的模型方案。AI竞争的核心正在从“谁的模型效果更好”转向“谁能把模型稳定、可控、低成本地嵌入到业务中”。这背后比拼的是数据工程、平台能力、评测机制、组织协同等等。这些都是慢功夫也都是“熬得久”的具体体现。2. 环境准备与版本说明进入实操之前先统一一下运行环境和依赖版本。AI相关工具链更新非常快我不建议照抄某一个固定版本更推荐把项目依赖明确写进配置文件在团队内保持一致。2.1 运行时与核心依赖本文示例以常见环境为主重点演示工程思路操作系统Ubuntu 22.04 或 macOS 均可Windows 通过 WSL 也可以。Python3.10 或更高版本。大模型推理可以调用云端API也可以用本地推理服务如 Ollama、vLLM提供兼容OpenAI协议的接口。向量数据库Chroma轻量易上手。服务框架FastAPI Uvicorn。RAG编排LangChain 0.3.x 生态。下面这份requirements.txt适用于本文示例fastapi0.115.6 uvicorn[standard]0.32.1 langchain0.3.7 langchain-openai0.2.14 langchain-community0.3.7 langchain-chroma0.1.4 langchain-text-splitters0.3.2 pydantic2.10.3 python-dotenv1.0.1版本不需要完全一致。如果你在安装时遇到依赖冲突可以选择降低或提高小版本但要注意LangChain生态中不同模块的版本需要保持兼容。2.2 示例项目结构为了便于后续扩展我们采用模块化结构ai_app/ ├── app/ │ ├── __init__.py │ ├── main.py # FastAPI 服务入口 │ ├── config.py # 全局配置 │ ├── rag/ │ │ ├── __init__.py │ │ ├── loader.py # 文档加载 │ │ ├── splitter.py # 文本切分 │ │ ├── embedder.py # 向量化 │ │ └── retriever.py # 向量检索 │ └── models/ │ ├── __init__.py │ ├── llm_client.py # 大模型客户端 │ └── prompt_template.py # Prompt 模板 ├── data/ # 原始文档存放目录 ├── tests/ # 测试目录 ├── requirements.txt └── .env.example3. 核心原理拆解AI应用落地的四项基本功无论做什么类型的AI应用有四件事绕不开数据、模型、工作流、评测。下面逐个拆解。3.1 数据与知识库决定AI质量的上限大模型虽然掌握了很多通用知识但对企业内部数据、私有文档、时事信息并不了解。RAGRetrieval-Augmented Generation检索增强生成是当前最主流的解决方案之一。RAG的思路很简单先从知识库中检索出与用户问题相关的文档片段再把检索结果和大模型指令组合成Prompt让模型基于给定资料回答。这样做有三个好处可以动态更新知识新文档进入知识库后模型回答立即能体现。可以有效降低幻觉概率因为模型只能基于检索到的上下文作答。可以避免针对每个场景做昂贵的微调。在RAG中知识库的质量直接决定了回答质量的上限。你需要考虑文档清洗、格式统一、切分粒度、元数据维护等一系列问题。切分尤其关键切得太粗检索结果可能包含大量无关内容切得太细又可能丢失上下文语义。通常需要根据文档结构、段落语义和模型窗口大小综合调优。3.2 模型选择与部署不是越大的模型越好很多团队一上来就追求70B、100B级别的大模型但实际效果未必比一个小模型加好Prompt更好成本和延迟却高得多。模型选型需要根据场景权衡通用对话场景云端API或中型模型即可。私有化、高安全场景必须本地部署小型模型配合RAG和微调。低延迟场景选择量化后的7B、13B模型或者蒸馏后的专用模型。本地部署时常用的方案有Ollama安装简单适合个人开发和测试。vLLM吞吐高适合生产环境。XTuner / FastChat适合微调后部署。在后面的实战中我会保留一个“任意兼容OpenAI协议”的大模型客户端配置这样你既可以直接使用云API也可以切换到本地Ollama或vLLM服务。3.3 Agent 工作流把简单交互变成复杂任务如果说RAG解决的是“让模型知道更多资料”Agent智能体解决的是“让模型能做更多事情”。一个基础Agent工作流通常包含四个环节接收用户任务。根据任务选择工具或步骤。执行工具调用并获取结果。汇总结果并返回最终答案。实际使用Agent时有一个常见误区把流程设计得太开放让模型随意发挥结果容易出现工具调用死循环、关键参数丢失、越权操作等问题。工程上更推荐“受控Agent”预先定义好可选工具每一步都加约束和兜底并对危险操作设置人工确认或权限控制。3.4 评测与反馈没有评测就没有长期迭代AI应用最大的特点是非确定性同样的输入模型输出可能每次都不一样。这导致“感觉变好了”不等于“真的变好了”。为了避免无效优化项目早期就要建立评测集。评测集至少应包含常见问题覆盖业务主要场景。边界问题例如模糊提问、缺失上下文。安全风险问题例如诱导越权、恶意指令。每次调整Prompt、模型或检索策略后都要跑一遍评测集对比回答质量、准确性、格式规范性。没有评测体系的AI项目迭代就像闭眼开车迟早会翻车。4. 完整实战案例构建一个可持续迭代的RAG问答服务现在进入代码环节。我们来实现一个完整的RAG问答服务前端不涉及只提供HTTP接口。4.1 创建项目结构按照上文规划在命令行创建目录mkdir -p ai_app/app/rag ai_app/app/models ai_app/data ai_app/tests然后进入项目目录cd ai_app4.2 添加依赖并安装创建requirements.txt写入上文的依赖列表然后执行pip install -r requirements.txt如果网络较慢可以使用国内镜像源pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple4.3 编写配置文件创建.env.example# 模型服务配置 OPENAI_API_KEYyour-api-key OPENAI_BASE_URLhttps://api.openai.com/v1 # 本地部署时可切换为 # OPENAI_BASE_URLhttp://localhost:11434/v1 # OPENAI_MODEL_NAMEqwen2.5:7b # 模型名称 OPENAI_MODEL_NAMEgpt-4o-mini # 向量模型 EMBEDDING_MODELtext-embedding-3-small # 向量库路径 CHROMA_PERSIST_DIR./chroma_db然后创建app/config.py# 文件路径app/config.py import os from dotenv import load_dotenv load_dotenv() class Settings: OPENAI_API_KEY: str os.getenv(OPENAI_API_KEY, ) OPENAI_BASE_URL: str os.getenv(OPENAI_BASE_URL, https://api.openai.com/v1) OPENAI_MODEL_NAME: str os.getenv(OPENAI_MODEL_NAME, gpt-4o-mini) EMBEDDING_MODEL: str os.getenv(EMBEDDING_MODEL, text-embedding-3-small) CHROMA_PERSIST_DIR: str os.getenv(CHROMA_PERSIST_DIR, ./chroma_db) settings Settings()4.4 文档加载与文本切分创建app/rag/loader.py# 文件路径app/rag/loader.py from langchain_community.document_loaders import DirectoryLoader, TextLoader def load_documents(data_dir: str ./data): loader DirectoryLoader( data_dir, glob**/*.md, loader_clsTextLoader, loader_kwargs{encoding: utf-8}, show_progressTrue, ) return loader.load()这里使用DirectoryLoader加载目录下所有.md文件。如果你的知识库里有PDF可以换成PyPDFLoader但需要额外安装。创建app/rag/splitter.py# 文件路径app/rag/splitter.py from langchain_text_splitters import RecursiveCharacterTextSplitter def get_splitter(chunk_size: int 500, chunk_overlap: int 80): return RecursiveCharacterTextSplitter( chunk_sizechunk_size, chunk_overlapchunk_overlap, separators[\n\n, \n, 。, , , ], )chunk_size表示每个片段的最大字符数chunk_overlap表示相邻片段之间的重叠字符数。为什么需要重叠如果切分过于刚硬检索时可能把一个完整概念截成两半导致模型拿到不完整的上下文。4.5 向量化与检索创建app/rag/embedder.py# 文件路径app/rag/embedder.py from langchain_openai import OpenAIEmbeddings from app.config import settings def get_embeddings(): return OpenAIEmbeddings( modelsettings.EMBEDDING_MODEL, api_keysettings.OPENAI_API_KEY, base_urlsettings.OPENAI_BASE_URL, )创建app/rag/retriever.py# 文件路径app/rag/retriever.py from langchain_chroma import Chroma from app.config import settings from app.rag.embedder import get_embeddings def get_vectorstore(): embeddings get_embeddings() return Chroma( collection_nameknowledge_base, embedding_functionembeddings, persist_directorysettings.CHROMA_PERSIST_DIR, )这里传入persist_directory后Chroma会自动持久化向量数据不需要手动调用persist()方法。4.6 大模型客户端与Prompt模板创建app/models/llm_client.py# 文件路径app/models/llm_client.py from langchain_openai import ChatOpenAI from app.config import settings def get_llm(temperature: float 0.1): return ChatOpenAI( modelsettings.OPENAI_MODEL_NAME, api_keysettings.OPENAI_API_KEY, base_urlsettings.OPENAI_BASE_URL, temperaturetemperature, )创建app/models/prompt_template.py# 文件路径app/models/prompt_template.py from langchain_core.prompts import ChatPromptTemplate prompt ChatPromptTemplate.from_messages( [ ( system, 你是一个专业的知识库问答助手。请严格根据给定的上下文回答问题。\n 如果上下文中没有答案请明确说“知识库中未找到相关信息”不要编造。\n 回答时使用中文保持简洁准确。\n\n 上下文\n{context}, ), (human, {input}), ] )4.7 构建RAG链路与FastAPI接口创建app/main.py# 文件路径app/main.py from fastapi import FastAPI from pydantic import BaseModel from langchain.chains import create_retrieval_chain from langchain.chains.combine_documents import create_stuff_documents_chain from app.models.llm_client import get_llm from app.models.prompt_template import prompt from app.rag.retriever import get_vectorstore app FastAPI(titleRAG 问答服务) class ChatRequest(BaseModel): question: str class ChatResponse(BaseModel): answer: str source_count: int def build_chain(): llm get_llm() vectorstore get_vectorstore() retriever vectorstore.as_retriever( search_typemmr, search_kwargs{k: 4, fetch_k: 20}, ) combine_docs_chain create_stuff_documents_chain(llm, prompt) return create_retrieval_chain(retriever, combine_docs_chain) rag_chain build_chain() app.post(/chat, response_modelChatResponse) def chat(request: ChatRequest): result rag_chain.invoke({input: request.question}) return ChatResponse( answerresult[answer], source_countlen(result[context]), ) app.get(/health) def health_check(): return {status: ok}这里的检索器用了mmr策略它会兼顾相关性和多样性减少重复内容。4.8 索引脚本为了把data目录下的文档写入向量库我们再创建一个索引脚本index_data.py# 文件路径index_data.py from app.rag.loader import load_documents from app.rag.splitter import get_splitter from app.rag.retriever import get_vectorstore def index_all(): docs load_documents() splitter get_splitter() chunks splitter.split_documents(docs) vectorstore get_vectorstore() vectorstore.add_documents(chunks) print(f索引完成共 {len(chunks)} 个文档片段) if __name__ __main__: index_all()4.9 运行与验证启动服务uvicorn app.main:app --reload --host 0.0.0.0 --port 8000打开另一个终端用curl测试接口curl -X POST http://localhost:8000/chat \ -H Content-Type: application/json \ -d {question: 你的知识库中提到了哪些常见问题}预期输出格式类似{ answer: 根据知识库中的内容常见问题包括……, source_count: 4 }如果你还没有准备知识库文档可以在data目录下创建几个简单的md文件然后执行python index_data.py重新启动服务后再次测试。5. 常见问题与排查思路在AI应用实际落地时下面几类问题出现频率最高我整理成了一份速查表。问题现象常见原因解决思路检索结果不相关文本切分参数不合适Embedding模型与业务不匹配调整切分大小和重叠度尝试领域语料微调的Embedding模型模型回答出现幻觉检索上下文不足Prompt没有约束模型基于上下文回答增加检索数量k在Prompt中强制模型引用原文或明确拒绝回答接口响应慢模型推理延迟高向量库查询慢开启流式输出使用量化模型增加语义缓存部署多个推理副本本地部署显存不足模型参数过大并发请求过多换用7B/13B量化模型限制并发使用vLLM的连续批处理能力答案前后不一致Prompt不够具体模型temperature过高降低temperature到0.1左右增加few-shot示例约束格式新文档不生效向量库没有更新检索命中了旧数据主动重新执行索引脚本增加文档更新时间过滤另外调试RAG时建议先分环节排查单独测试向量检索看看命中的上下文是否符合预期。再把命中的上下文手动拼进Prompt看模型是否能正确回答。如果检索正常但回答不好问题大概率在Prompt或模型选择上。6. 最佳实践与工程建议6.1 先定指标再调模型在AI项目启动时第一时间要做的不是选模型而是把效果衡量指标定下来。建议准备至少20条评测用例覆盖正常问题、边界问题、超纲问题。每次改动前先记录当前效果改动后再对比至少保证不退化。6.2 模型与数据分离治理模型配置、Prompt模板、知识库文档都应该与业务代码解耦。不要把Prompt硬编码在业务逻辑里也不要把数据文件散落在代码目录中。建议向量数据放在独立目录或对象存储。Prompt模板单独维护支持按环境切换。模型版本和权重文件用清晰的命名保存方便回滚。6.3 成本与延迟控制大模型调用成本通常是AI应用的主要成本。可以通过以下方式控制增加语义缓存相同或相似问题直接命中历史结果。缩短上下文检索到的文档先做重排只保留最相关的片段。设计模型分层简单问题用轻量模型复杂问题才调用大模型。在部署上优先考虑GPU资源池化避免每个业务各自独占一套推理资源。6.4 安全与合规边界AI应用会暴露出新的安全风险至少要关注三点Prompt注入用户输入可能携带绕过系统提示的恶意指令。建议对输入做长度限制并过滤敏感内容。权限校验AI接口只是入口最终执行数据操作时必须遵守原有权限体系不能因为模型“以为”有权限就放行。数据合规私有知识库中的个人数据和敏感信息需要脱敏后再向量化。任何涉及在线数据变更的AI Agent能力都要遵循最小权限原则必要时加入人工审批环节。6.5 灰度发布与回滚大模型应用不能像普通功能一样直接全量发布。比较稳妥的做法是先做离线评测确认新Prompt或新模型在评测集上效果不差。再以10%的流量灰度验证对比业务指标和用户反馈。确认稳定后再逐步放量同时保留历史模型和配置方便快速回滚。6.6 日志与监控AI服务的日志要比传统接口更丰富。每次请求至少记录用户原始输入。检索到的上下文文档ID。模型输出结果。Prompt模板版本。模型名称和参数。完整调用耗时和Token消耗。有了这些数据当线上出现问题时才有办法复现和定位。长期积累后还能拿真实日志反向补充评测集。7. 总结与下一步“AI竞争不是短跑熬得久比起得早更重要”这句话放在工程实践里意味着AI应用不是上线就结束而是一个需要持续迭代和治理的长期过程。这篇文章从工程视角拆解了AI应用落地的关键环节并通过一个RAG问答服务演示了从数据索引、向量检索到大模型调用的完整链路。如果你刚开始做AI应用下一步建议优先掌握三条主线提升RAG效果学习文档切分、查询改写、重排序、混合检索。理解Agent工程从单工具调用开始逐步加上规划、记忆和异常恢复。建立评估体系把评测集自动化跑通回归测试再谈优化。如果今天只做一件事就把你业务中的常见问题固化成一个评测集。这个“笨功夫”会是你后续所有AI优化的基准线。
最近在复盘我们团队自己的AI项目时我最大的感受是大家往往在Demo阶段冲得很快模型选型、Prompt试调、效果展示都很有热情可一旦进入生产环境问题就接二连三地暴露出来——数据质量差、接口不稳定、效果不可控、迭代没有方向。恰好这时候看到一条关于腾讯AI的讨论有观点认为“AI竞争不是短跑熬得久比起得早更重要”。先不评判企业战略这句话放到AI工程实践里确实是一个值得反复咀嚼的提醒。这篇文章不聊公司竞争也不做行业点评。我想把“AI竞争是长跑”这个观点拆解成AI应用开发中的真实技术问题环境怎么搭、数据怎么管、模型怎么部署、服务怎么上线、效果怎么持续优化。无论你是刚接触AI开发的初学者还是已经在做AI应用落地的后端工程师都可以从这篇文章里找到一套可以照着做的工程思路。文章会以一个完整的RAG问答服务为例从零搭建可运行的代码并补充生产环境最常遇到的坑和排查方法。如果你正打算把AI能力沉淀到自己的业务系统里这篇文章可以作为一份工程化落地参考。1. 背景与核心概念1.1 从“起得早”到“熬得久”AI项目的定位AI行业每隔一段时间就会有一个新概念、新模型、新工具出现。今天刷到一个模型效果超越上一代明天看到一个Agent框架又更新了能力很容易让团队产生一种“必须立刻跟上”的焦虑。但实际做项目时你会发现“起得早”只是拿到了入场券真正决定项目成败的是后面漫长得多的阶段。一个AI应用要稳定运行在生产环境需要持续处理数据变化、模型效果退化、用户反馈、成本波动、安全风险等一堆工程问题。这些问题不是靠某个新模型就能解决的而是靠一套能长期运转的迭代机制去托底。所以“熬得久”并不是一句鸡汤它对应的是AI项目的真实生命周期管理能力。一个模型Demo可能只需要几天但一个AI服务要跑上一年并且越跑越好需要的是数据治理、评测体系、监控告警、灰度回滚等工程能力。1.2 AI应用开发的三阶段我习惯把AI应用开发分成三个阶段第一阶段是实验验证阶段。这个阶段的目标很简单用最小成本验证“大模型能不能解决这个问题”。你可以用现成的API写几条Prompt跑几个测试样本看看效果方向是否可行。这个阶段通常不需要复杂工程。第二阶段是工程化阶段。当效果基本满足要求后就要把脚本变成服务。这里需要处理并发、鉴权、日志、限流、缓存、向量数据库、模型部署、接口稳定性等一系列问题。很多团队就死在这个阶段因为Demo和线上服务之间隔着一条巨大的工程鸿沟。第三阶段是持续迭代阶段。服务上线只是开始接下来你需要收集线上数据建立评测集持续优化Prompt、检索策略、模型版本甚至要做A/B测试和灰度发布。没有这个阶段AI应用的效果会随着数据漂移和模型更新逐渐退化。这三个阶段中往往第二个和第三个阶段消耗的时间远超第一个阶段。这正是“熬得久”的工程含义。1.3 为什么技术领先不等于业务领先单独看模型效果技术领先确实存在但放到业务里技术领先并不等于产品体验领先。一个效果略好但响应要5秒、成本翻倍、时不时抽风的模型往往不如一个效果稳定、延迟可控、成本可接受的模型方案。AI竞争的核心正在从“谁的模型效果更好”转向“谁能把模型稳定、可控、低成本地嵌入到业务中”。这背后比拼的是数据工程、平台能力、评测机制、组织协同等等。这些都是慢功夫也都是“熬得久”的具体体现。2. 环境准备与版本说明进入实操之前先统一一下运行环境和依赖版本。AI相关工具链更新非常快我不建议照抄某一个固定版本更推荐把项目依赖明确写进配置文件在团队内保持一致。2.1 运行时与核心依赖本文示例以常见环境为主重点演示工程思路操作系统Ubuntu 22.04 或 macOS 均可Windows 通过 WSL 也可以。Python3.10 或更高版本。大模型推理可以调用云端API也可以用本地推理服务如 Ollama、vLLM提供兼容OpenAI协议的接口。向量数据库Chroma轻量易上手。服务框架FastAPI Uvicorn。RAG编排LangChain 0.3.x 生态。下面这份requirements.txt适用于本文示例fastapi0.115.6 uvicorn[standard]0.32.1 langchain0.3.7 langchain-openai0.2.14 langchain-community0.3.7 langchain-chroma0.1.4 langchain-text-splitters0.3.2 pydantic2.10.3 python-dotenv1.0.1版本不需要完全一致。如果你在安装时遇到依赖冲突可以选择降低或提高小版本但要注意LangChain生态中不同模块的版本需要保持兼容。2.2 示例项目结构为了便于后续扩展我们采用模块化结构ai_app/ ├── app/ │ ├── __init__.py │ ├── main.py # FastAPI 服务入口 │ ├── config.py # 全局配置 │ ├── rag/ │ │ ├── __init__.py │ │ ├── loader.py # 文档加载 │ │ ├── splitter.py # 文本切分 │ │ ├── embedder.py # 向量化 │ │ └── retriever.py # 向量检索 │ └── models/ │ ├── __init__.py │ ├── llm_client.py # 大模型客户端 │ └── prompt_template.py # Prompt 模板 ├── data/ # 原始文档存放目录 ├── tests/ # 测试目录 ├── requirements.txt └── .env.example3. 核心原理拆解AI应用落地的四项基本功无论做什么类型的AI应用有四件事绕不开数据、模型、工作流、评测。下面逐个拆解。3.1 数据与知识库决定AI质量的上限大模型虽然掌握了很多通用知识但对企业内部数据、私有文档、时事信息并不了解。RAGRetrieval-Augmented Generation检索增强生成是当前最主流的解决方案之一。RAG的思路很简单先从知识库中检索出与用户问题相关的文档片段再把检索结果和大模型指令组合成Prompt让模型基于给定资料回答。这样做有三个好处可以动态更新知识新文档进入知识库后模型回答立即能体现。可以有效降低幻觉概率因为模型只能基于检索到的上下文作答。可以避免针对每个场景做昂贵的微调。在RAG中知识库的质量直接决定了回答质量的上限。你需要考虑文档清洗、格式统一、切分粒度、元数据维护等一系列问题。切分尤其关键切得太粗检索结果可能包含大量无关内容切得太细又可能丢失上下文语义。通常需要根据文档结构、段落语义和模型窗口大小综合调优。3.2 模型选择与部署不是越大的模型越好很多团队一上来就追求70B、100B级别的大模型但实际效果未必比一个小模型加好Prompt更好成本和延迟却高得多。模型选型需要根据场景权衡通用对话场景云端API或中型模型即可。私有化、高安全场景必须本地部署小型模型配合RAG和微调。低延迟场景选择量化后的7B、13B模型或者蒸馏后的专用模型。本地部署时常用的方案有Ollama安装简单适合个人开发和测试。vLLM吞吐高适合生产环境。XTuner / FastChat适合微调后部署。在后面的实战中我会保留一个“任意兼容OpenAI协议”的大模型客户端配置这样你既可以直接使用云API也可以切换到本地Ollama或vLLM服务。3.3 Agent 工作流把简单交互变成复杂任务如果说RAG解决的是“让模型知道更多资料”Agent智能体解决的是“让模型能做更多事情”。一个基础Agent工作流通常包含四个环节接收用户任务。根据任务选择工具或步骤。执行工具调用并获取结果。汇总结果并返回最终答案。实际使用Agent时有一个常见误区把流程设计得太开放让模型随意发挥结果容易出现工具调用死循环、关键参数丢失、越权操作等问题。工程上更推荐“受控Agent”预先定义好可选工具每一步都加约束和兜底并对危险操作设置人工确认或权限控制。3.4 评测与反馈没有评测就没有长期迭代AI应用最大的特点是非确定性同样的输入模型输出可能每次都不一样。这导致“感觉变好了”不等于“真的变好了”。为了避免无效优化项目早期就要建立评测集。评测集至少应包含常见问题覆盖业务主要场景。边界问题例如模糊提问、缺失上下文。安全风险问题例如诱导越权、恶意指令。每次调整Prompt、模型或检索策略后都要跑一遍评测集对比回答质量、准确性、格式规范性。没有评测体系的AI项目迭代就像闭眼开车迟早会翻车。4. 完整实战案例构建一个可持续迭代的RAG问答服务现在进入代码环节。我们来实现一个完整的RAG问答服务前端不涉及只提供HTTP接口。4.1 创建项目结构按照上文规划在命令行创建目录mkdir -p ai_app/app/rag ai_app/app/models ai_app/data ai_app/tests然后进入项目目录cd ai_app4.2 添加依赖并安装创建requirements.txt写入上文的依赖列表然后执行pip install -r requirements.txt如果网络较慢可以使用国内镜像源pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple4.3 编写配置文件创建.env.example# 模型服务配置 OPENAI_API_KEYyour-api-key OPENAI_BASE_URLhttps://api.openai.com/v1 # 本地部署时可切换为 # OPENAI_BASE_URLhttp://localhost:11434/v1 # OPENAI_MODEL_NAMEqwen2.5:7b # 模型名称 OPENAI_MODEL_NAMEgpt-4o-mini # 向量模型 EMBEDDING_MODELtext-embedding-3-small # 向量库路径 CHROMA_PERSIST_DIR./chroma_db然后创建app/config.py# 文件路径app/config.py import os from dotenv import load_dotenv load_dotenv() class Settings: OPENAI_API_KEY: str os.getenv(OPENAI_API_KEY, ) OPENAI_BASE_URL: str os.getenv(OPENAI_BASE_URL, https://api.openai.com/v1) OPENAI_MODEL_NAME: str os.getenv(OPENAI_MODEL_NAME, gpt-4o-mini) EMBEDDING_MODEL: str os.getenv(EMBEDDING_MODEL, text-embedding-3-small) CHROMA_PERSIST_DIR: str os.getenv(CHROMA_PERSIST_DIR, ./chroma_db) settings Settings()4.4 文档加载与文本切分创建app/rag/loader.py# 文件路径app/rag/loader.py from langchain_community.document_loaders import DirectoryLoader, TextLoader def load_documents(data_dir: str ./data): loader DirectoryLoader( data_dir, glob**/*.md, loader_clsTextLoader, loader_kwargs{encoding: utf-8}, show_progressTrue, ) return loader.load()这里使用DirectoryLoader加载目录下所有.md文件。如果你的知识库里有PDF可以换成PyPDFLoader但需要额外安装。创建app/rag/splitter.py# 文件路径app/rag/splitter.py from langchain_text_splitters import RecursiveCharacterTextSplitter def get_splitter(chunk_size: int 500, chunk_overlap: int 80): return RecursiveCharacterTextSplitter( chunk_sizechunk_size, chunk_overlapchunk_overlap, separators[\n\n, \n, 。, , , ], )chunk_size表示每个片段的最大字符数chunk_overlap表示相邻片段之间的重叠字符数。为什么需要重叠如果切分过于刚硬检索时可能把一个完整概念截成两半导致模型拿到不完整的上下文。4.5 向量化与检索创建app/rag/embedder.py# 文件路径app/rag/embedder.py from langchain_openai import OpenAIEmbeddings from app.config import settings def get_embeddings(): return OpenAIEmbeddings( modelsettings.EMBEDDING_MODEL, api_keysettings.OPENAI_API_KEY, base_urlsettings.OPENAI_BASE_URL, )创建app/rag/retriever.py# 文件路径app/rag/retriever.py from langchain_chroma import Chroma from app.config import settings from app.rag.embedder import get_embeddings def get_vectorstore(): embeddings get_embeddings() return Chroma( collection_nameknowledge_base, embedding_functionembeddings, persist_directorysettings.CHROMA_PERSIST_DIR, )这里传入persist_directory后Chroma会自动持久化向量数据不需要手动调用persist()方法。4.6 大模型客户端与Prompt模板创建app/models/llm_client.py# 文件路径app/models/llm_client.py from langchain_openai import ChatOpenAI from app.config import settings def get_llm(temperature: float 0.1): return ChatOpenAI( modelsettings.OPENAI_MODEL_NAME, api_keysettings.OPENAI_API_KEY, base_urlsettings.OPENAI_BASE_URL, temperaturetemperature, )创建app/models/prompt_template.py# 文件路径app/models/prompt_template.py from langchain_core.prompts import ChatPromptTemplate prompt ChatPromptTemplate.from_messages( [ ( system, 你是一个专业的知识库问答助手。请严格根据给定的上下文回答问题。\n 如果上下文中没有答案请明确说“知识库中未找到相关信息”不要编造。\n 回答时使用中文保持简洁准确。\n\n 上下文\n{context}, ), (human, {input}), ] )4.7 构建RAG链路与FastAPI接口创建app/main.py# 文件路径app/main.py from fastapi import FastAPI from pydantic import BaseModel from langchain.chains import create_retrieval_chain from langchain.chains.combine_documents import create_stuff_documents_chain from app.models.llm_client import get_llm from app.models.prompt_template import prompt from app.rag.retriever import get_vectorstore app FastAPI(titleRAG 问答服务) class ChatRequest(BaseModel): question: str class ChatResponse(BaseModel): answer: str source_count: int def build_chain(): llm get_llm() vectorstore get_vectorstore() retriever vectorstore.as_retriever( search_typemmr, search_kwargs{k: 4, fetch_k: 20}, ) combine_docs_chain create_stuff_documents_chain(llm, prompt) return create_retrieval_chain(retriever, combine_docs_chain) rag_chain build_chain() app.post(/chat, response_modelChatResponse) def chat(request: ChatRequest): result rag_chain.invoke({input: request.question}) return ChatResponse( answerresult[answer], source_countlen(result[context]), ) app.get(/health) def health_check(): return {status: ok}这里的检索器用了mmr策略它会兼顾相关性和多样性减少重复内容。4.8 索引脚本为了把data目录下的文档写入向量库我们再创建一个索引脚本index_data.py# 文件路径index_data.py from app.rag.loader import load_documents from app.rag.splitter import get_splitter from app.rag.retriever import get_vectorstore def index_all(): docs load_documents() splitter get_splitter() chunks splitter.split_documents(docs) vectorstore get_vectorstore() vectorstore.add_documents(chunks) print(f索引完成共 {len(chunks)} 个文档片段) if __name__ __main__: index_all()4.9 运行与验证启动服务uvicorn app.main:app --reload --host 0.0.0.0 --port 8000打开另一个终端用curl测试接口curl -X POST http://localhost:8000/chat \ -H Content-Type: application/json \ -d {question: 你的知识库中提到了哪些常见问题}预期输出格式类似{ answer: 根据知识库中的内容常见问题包括……, source_count: 4 }如果你还没有准备知识库文档可以在data目录下创建几个简单的md文件然后执行python index_data.py重新启动服务后再次测试。5. 常见问题与排查思路在AI应用实际落地时下面几类问题出现频率最高我整理成了一份速查表。问题现象常见原因解决思路检索结果不相关文本切分参数不合适Embedding模型与业务不匹配调整切分大小和重叠度尝试领域语料微调的Embedding模型模型回答出现幻觉检索上下文不足Prompt没有约束模型基于上下文回答增加检索数量k在Prompt中强制模型引用原文或明确拒绝回答接口响应慢模型推理延迟高向量库查询慢开启流式输出使用量化模型增加语义缓存部署多个推理副本本地部署显存不足模型参数过大并发请求过多换用7B/13B量化模型限制并发使用vLLM的连续批处理能力答案前后不一致Prompt不够具体模型temperature过高降低temperature到0.1左右增加few-shot示例约束格式新文档不生效向量库没有更新检索命中了旧数据主动重新执行索引脚本增加文档更新时间过滤另外调试RAG时建议先分环节排查单独测试向量检索看看命中的上下文是否符合预期。再把命中的上下文手动拼进Prompt看模型是否能正确回答。如果检索正常但回答不好问题大概率在Prompt或模型选择上。6. 最佳实践与工程建议6.1 先定指标再调模型在AI项目启动时第一时间要做的不是选模型而是把效果衡量指标定下来。建议准备至少20条评测用例覆盖正常问题、边界问题、超纲问题。每次改动前先记录当前效果改动后再对比至少保证不退化。6.2 模型与数据分离治理模型配置、Prompt模板、知识库文档都应该与业务代码解耦。不要把Prompt硬编码在业务逻辑里也不要把数据文件散落在代码目录中。建议向量数据放在独立目录或对象存储。Prompt模板单独维护支持按环境切换。模型版本和权重文件用清晰的命名保存方便回滚。6.3 成本与延迟控制大模型调用成本通常是AI应用的主要成本。可以通过以下方式控制增加语义缓存相同或相似问题直接命中历史结果。缩短上下文检索到的文档先做重排只保留最相关的片段。设计模型分层简单问题用轻量模型复杂问题才调用大模型。在部署上优先考虑GPU资源池化避免每个业务各自独占一套推理资源。6.4 安全与合规边界AI应用会暴露出新的安全风险至少要关注三点Prompt注入用户输入可能携带绕过系统提示的恶意指令。建议对输入做长度限制并过滤敏感内容。权限校验AI接口只是入口最终执行数据操作时必须遵守原有权限体系不能因为模型“以为”有权限就放行。数据合规私有知识库中的个人数据和敏感信息需要脱敏后再向量化。任何涉及在线数据变更的AI Agent能力都要遵循最小权限原则必要时加入人工审批环节。6.5 灰度发布与回滚大模型应用不能像普通功能一样直接全量发布。比较稳妥的做法是先做离线评测确认新Prompt或新模型在评测集上效果不差。再以10%的流量灰度验证对比业务指标和用户反馈。确认稳定后再逐步放量同时保留历史模型和配置方便快速回滚。6.6 日志与监控AI服务的日志要比传统接口更丰富。每次请求至少记录用户原始输入。检索到的上下文文档ID。模型输出结果。Prompt模板版本。模型名称和参数。完整调用耗时和Token消耗。有了这些数据当线上出现问题时才有办法复现和定位。长期积累后还能拿真实日志反向补充评测集。7. 总结与下一步“AI竞争不是短跑熬得久比起得早更重要”这句话放在工程实践里意味着AI应用不是上线就结束而是一个需要持续迭代和治理的长期过程。这篇文章从工程视角拆解了AI应用落地的关键环节并通过一个RAG问答服务演示了从数据索引、向量检索到大模型调用的完整链路。如果你刚开始做AI应用下一步建议优先掌握三条主线提升RAG效果学习文档切分、查询改写、重排序、混合检索。理解Agent工程从单工具调用开始逐步加上规划、记忆和异常恢复。建立评估体系把评测集自动化跑通回归测试再谈优化。如果今天只做一件事就把你业务中的常见问题固化成一个评测集。这个“笨功夫”会是你后续所有AI优化的基准线。
