把标题落在实际项目上我们内部给它起了个代号“炬火计划”。这一年多我带着一个不到十人的团队把“以科技创新为炬照AI时代征程”这句话从墙上的标语变成了一个跑在线上、每天被上千人使用的智能文档问答平台。这篇不是什么宏大叙事就是一次真实落地的复盘——从选型、数据、部署到运维把过程中想明白的事、踩过的坑一并交代清楚。如果你想做RAG应用、私有化部署大模型或者只是好奇一个AI项目是怎么从0到1活下来的这篇值得你花十分钟细看。1. 项目开局为什么我们判定“AI能打这一仗”1.1 一个被文档淹没的业务场景我们当时切入的痛点其实特别朴素公司内部有成堆的合同、技术文档、验收报告、FAQ分散在不同系统里。业务部门每天要花大量时间翻找资料客服团队回答问题靠“老员工记忆”新入职的人前三个月基本处于“找不到东西”的状态。做过企业信息化的人都懂知识不流转再好的业务设计也会被重复劳动拖垮。一开始我们想过做传统的搜索引擎改良——给文档打标签、建关键字库、做分词优化。但算了一笔账之后发现这条路走不通文档覆盖的业务线超过二十个关键词规则需要每个业务线各维护一套词表规则之间还会互相打架。更麻烦的是用户问的问题和文档里的写法往往不是同一套话。比如文档里写“验收未通过”用户问的是“为什么钱还没打过去”。这种语义鸿沟传统检索解决不了所以我们把目光投向了大模型。这个判断做得很关键AI能不能解决不看技术本身多炫而看问题是不是“语义匹配型”的问题。只要问题存在“用不同的话描述同一件事”的场景就值得尝试生成式AI落地。1.2 先回答三个“能不能”项目启动前我们花了整整一周回答三个问题数据能不能脱敏合规、模型能不能私有化部署、成本能不能兜住。当时外部大模型API已经很成熟调用方便、效果也好但公司业务涉及大量敏感信息数据不能出内网所以“私有化部署”是硬前提不是可选项。我们把所有候选方案放在一张表上做过对比方案数据合规定制能力部署成本初始效果最终结论外部大模型API不满足强低高放弃开源模型私有部署满足中中中采用传统检索满足弱低低放弃混合检索开源模型满足强中中高采用结论是整体走 RAG检索增强生成路线底层用开源模型私有化部署检索层用“向量 关键词”混合召回。这套组合在当时不是最酷的解法但它是约束条件下最扎实的解法。做工程的人容易陷入“追新”的冲动但真正该追的是约束条件下的最优解。1.3 把“征程”拆成里程碑“AI时代征程”这种话在项目周报里毫无意义我们对外的说法是先做个能用的再做靠谱的最后做便宜的。三个里程碑对应三个KPI可用性——能不能回答准确率——答得对不对成本——能不能长期养得起。第一版目标很简单把检索准确率做到80%答案被用户采纳率达到70%单次回答延迟控制在5秒以内。能达到这个水平业务方就愿意用项目就能活下去。这个目标不高但足够清晰所有技术选型都朝着这三个数字使劲。2. 技术底座模型、数据与算力的“三角平衡”2.1 模型选型为什么不追“最强”模型选型阶段团队争议最大。当时圈子里流行“模型越大越好”有人建议直接用70B级别的开源模型理由是效果上限高也有人建议用几百M的小模型理由是跑得快。双方吵了一周最后我们做了一个折中主模型用7B级别的中英文双语模型同时保留一个1.5B的小模型做粗排重的生成任务走7B轻量的提取任务走1.5B。逻辑其实不难理解大模型效果好但显存占用高、单卡吞吐低按我们当时的流量来算70B模型至少需要8张卡才能跑起来推理成本直接翻三倍。而7B模型在量化之后两张卡就能稳住延迟还在可接受范围内。至于效果差距完全可以用RAG的知识召回和提示词约束来补。先把系统跑起来再让业务数据反哺模型这是一个被低估的迭代路径。部署上我们用了vLLM作为推理框架开启PagedAttention和Continuous Batching单卡并发吞吐比原生方案高出一截。这里有个经验开源框架和推理框架的版本要严格匹配我们刚开始图省事用了最新的vLLM配旧版模型权重结果张量并行的时候卡死排查了整整两天。后来所有组件全部锁版本再没出过类似问题。2.2 数据治理被所有人低估的“硬骨头”模型是选出来的但项目成败其实是数据决定的。我们当时手里有电子化文档十几万份但质量参差不齐有的是扫描件、有的是多层嵌套表格、有的版本混乱。数据团队花了47天做清洗比训练模型的时间长得多。清洗流程现在是我们的标准操作格式解析——文本抽取——分段切分——质量打分——人工抽检。文本抽取环节最脏PDF里经常混着页眉页脚、水印、乱码。我们用OCR加版面分析把标题、正文、表格拆开规则没法覆盖的再用正则补几刀。这里的关键不是“完美清洗”而是“让噪声低到不严重干扰检索”。我们定了一个量化标准单篇文档的正文纯度不低于90%低于这个线就重跑抽取。分段切分是另一个容易翻车的点。很多人直接把文档按固定字数切块结果一个完整段落被拦腰截断语义残破召回质量直线下降。我们的做法是先按标题层级做结构化切分段落太长的再按句子边界二次切分每个chunk控制在300到500字之间。切分之后要给每个chunk打上来源文档ID、章节路径、页码这些元信息在后面做引用溯源时帮了大忙。2.3 算力规划把钱花在刀刃上算力预算一向敏感我们做了一套成本模型来估算需求并发峰值、平均请求长度、每token耗时、目标延迟四项相乘再加余量。按当时日均两千次调用、峰值并发20来算7B量化模型在两张卡上就能扛住。后来实际流量翻了三倍我们才又加了四张卡。为了控制长期成本我们把一些高频但简单的任务拆出来比如“抽取合同编号”“识别文档类型”这类操作交给了1.5B小模型处理大模型只回答复杂问题。这套“大模型为主、小模型分流”的混合架构直接让GPU资源占用下降了将近三成。另外所有答案在进模型之前先走缓存同一个问题命中缓存就直接返回实测缓存命中率能到15%左右虽然不高但胜在零成本。3. 系统落地从Demo到生产环境到底远不远3.1 架构设计把AI能力拆成一个个“服务”表面看我们做了一个问答机器人但内部其实是一套服务化平台文档解析服务、向量化服务、检索服务、重排服务、生成服务五个模块各司其职用FastAPI包成独立接口。这样做的好处是每一环都能单独迭代、单独扩容。完整链路是这样的用户提问进入网关先做意图识别和改写然后并行发起两路检索——一路走向量相似度一路走BM25关键词。两队结果合并后进重排模型打分选出Top5文档块再把文档块拼进提示词交给大模型生成答案。最后还有一个“引用检查”环节如果答案里提到了数字、日期、金额系统会自动比对原文块不一致就拒绝生成并返回依据片段。这一步是我们在吃了若干次“AI编造合同金额”的亏之后加上的。架构上有一点必须提醒AI服务别和业务系统硬耦合。我们把所有模型接口统一封装成“异步任务”——任务进来先入队处理完再回调。一开始业务方希望同步等结果但同步模式一遇到模型推理抖动整个接口就跟着超时。改成异步之后用户看到的是“处理中”的状态而不是白屏报错体感稳定很多。3.2 评测体系给模型设一道“及格线”没有评测体系就上线相当于没考驾照就上路。我们构建了一套三层评测集第一层是200条通用业务问答覆盖高频问题第二层是100条长尾场景包括多跳问题、比较类问题和否定类问题第三层是50条对抗样本专门构造容易让模型犯错的问法比如“如果甲方违约会怎样”“哪些情况不算验收通过”。每条评测样本都必须包含标准答案、答案出处、允许的答案范围。我们打过分后发现单看“答案是否准确”并不够还要看“引用是否正确”。很多模型能答对结论但引用的文档块是错的这在专业场景里是致命的。所以最终考核指标有三项答案准确率、引用正确率、无答案率。“无答案率”的意思是检索结果不足以支撑答案时模型要敢于说“不知道”而不是硬答。理想的无答案率控制在10%以下过高说明知识覆盖不足过低说明模型在瞎猜。评测跑起来之后还有一个额外收益它成了模型的“体检单”。每次换模型版本、调提示词都先跑一遍评测集用数字说话。后来我们再没经历过“感觉变好了”这种凭直觉做决策的状态。3.3 上线与灰度信任是一点点攒出来的系统上线方式我们选了灰度发布而不是一次性全量切换。前两周只开放给内部技术团队使用问题随便提但答案仅供测试第三周开放给一个业务线试点每天限额50次跑通一个月之后才逐步放开给全公司。灰度期间最重要的不是功能而是“用户信任”。AI答错一次用户就会觉得“这东西不靠谱”。所以我们做了两个补偿机制每个答案下面必须展示引用来源用户点开能看到原文内容同时提供“反馈按钮”用户认为答案有问题一键提交给人工复核。这两个机制看起来简单但对留存率的影响极大。实测第一个月的答案采纳率只有61%三个月后涨到79%就是因为反馈闭环在不断修正。上线后的运维我们制定了“四个实时”日志实时采集、错误实时告警、模型版本实时可回滚、调用量实时可查。每两周一次回顾会把线上用户反馈的问题样例拉出来逐条过——是检索漏了、还是模型答偏、还是文档本身没覆盖。大多数问题最后都回到数据上真正改动模型参数的情况反而很少。4. 团队分工与项目管理科技创新背后的“软底座”4.1 新角色带来的协作模式变化AI项目对团队结构的冲击比技术本身大得多。传统研发团队“产品提需求—开发写代码—测试验收”的老三样在AI项目里行不通因为模型行为没法像写死功能一样被精确预测。我们后来把团队拆成三个角色算法工程师负责模型训练和提示词数据工程师负责文档清洗和样本标注产品运营负责业务反馈和效果验收。三个角色每周合开三次站会站会主题就一个——这周哪些问题答错了、答错的原因是什么。标注团队是另一个容易被低估的角色。最初我们想让外包快速标注但外包对业务背景不了解标注出来的答案质量堪忧。后来改成“业务专家兼职标注算法工程师复核”的模式质量和速度反而都上来了。这里想强调一个反直觉的经验AI项目的数据标注不能全指望外包业务侧一定得深度介入否则你只是在用错误数据训练一个错误模型。4.2 推进节奏小步快跑比憋大招管用项目周期拉长之后团队士气是个大问题。我们定了“每两周一个可演示版本”的节奏不管多小的进步都必须产出一个能给别人看的增量。第一次版本演示我们只做了“文档解析单条检索”界面粗糙得不行但业务方看到关键词可以命中段落已经愿意投入配合了。后续每一轮迭代都围绕一个明确主题第一轮解决“能不能检索”第二轮解决“答案像不像样”第三轮解决“引用对不对”第四轮解决“跑得快不快”。四个迭代串在一起产品形态就完整了。这种节奏最大的好处是每个阶段都有验收点不会有“闷头干了半年忽然发现方向不对”的翻车时刻。4.3 项目里印象最深的三个坑第一个坑是环境复现。我们有三台GPU机器系统环境配置各不相同同一个模型在不同机器上跑出来的结果居然存在明显差异。后来统一用容器镜像固化环境从此再也没人遇到“在我机器上明明是好的”这种问题。第二个坑是模型微调把旧知识“洗掉”了。我们本意是用业务数据微调模型结果模型在业务问题上表现提升但通用能力明显下降连“介绍一下什么是RAG”都回答得磕磕绊绊。后来我们把微调数据里混入15%的通用对话数据这个问题才缓解。微调不是灌数据是“配药”比例稍有不对就出副作用。第三个坑更隐蔽——检索结果的“回声效应”。向量检索对高频词过于敏感很多不相关的文档块因为包含同一个热门词汇被召回挤掉了真正相关的文档块。后来我们同时引入BM25关键词召回再用重排模型合并排序这个问题基本被压下去了。检索增强生成里检索端永远比生成端更值得花精力。5. 经验沉淀这套方法还能复用到哪里5.1 三条最核心的经验第一条经验AI项目的核心是评测体系不是模型本身。没有评测你根本不知道自己改完模型之后是变好还是变坏一切优化都是盲人摸象。早点建评测集越早越好哪怕先拿五十条问题凑合也比没有强。第二条经验善用“不合理”的方案组合。大模型很强但不必所有问题都用大模型。结构化提取用规则轻量分类用小模型复杂生成才上大模型。这样组合下来成本和延迟反而更可控。第三条经验用户的信任是从“你敢承认不知道”开始的。AI答错不丢人答错了还硬着头皮编才致命。我们在提示词里强制加入“知识不足时明确声明”无答案率虽然上升了一些但用户信任感反而更强了采纳率也在同步上升。对任何一个刚起步做AI应用的团队我的建议是先别追求换个更大的模型先把你手上的一万条文档洗干净再找业务专家抽一百个真实问题跑通一条完整的RAG链路。做到这一步你就已经跑赢市面上大半只停留在Demo阶段的项目了。5.2 常见问题速查表问题现象可能原因排查手段答案和引用对不上生成阶段没有约束引用启用引用校验数字类内容强制比对原文检索召回了大量无关文档向量模型对领域词汇不敏感混入BM25关键词召回增加重排模型模型总是答非所问检索结果Top1质量差看检索中间结果别只盯着最终答案微调后通用能力退化业务数据比例过高混入通用对话数据控制在85/15比例附近同一问题答案不稳定采样参数没固定生成阶段关闭随机采样或降低temperature上线后响应变慢请求排队膨胀开启异步任务扩容推理实例加缓存系统里没有某个知识文档解析没覆盖查文档入库率很多问题根源是文档压根没进来5.3 下一步把“会问”变成“能干”第一版问答平台跑顺之后我们的方向开始从“被动问”转向“主动干”。具体来说下一步准备把平台接入业务系统做成“智能助手”的形态用户提问之后系统不只是给答案还能直接生成一个可执行的后续动作——比如一键调出合同关键条款、自动填充审批理由、把答复推送给相关责任人。技术栈不用推倒重来检索层和生成层可以继续复用只是需要在生成环节增加“工具调用”能力让模型学会输出结构化的动作指令。这个方向上RAG仍然会作为底座因为AI一旦要代替人做决策每一句话都必须有据可查。最后分享一个我个人的体会做AI项目最让人上头的不是模型突然变得很聪明的那一瞬间而是业务方说“以前这个事我要查一小时现在一分钟就搞定了”的时候。所谓“以科技创新为炬”落到实处就是帮一个具体的人省下一段具体的时间。往后不管技术怎么变这个判断标准我会一直放在心里。