做探索型项目最难的从来不是从0到1把原型跑通而是从1到N的这段路。我过去一年多带了一个本地部署的团队文档知识库问答系统从最初只是一个领导拍脑袋的能不能让AI帮我们读文档走到现在支撑全公司多个业务线的日常检索和问答中间踩过的坑、做过的取舍、推翻过重来的方案比之前做过的所有确定性项目加起来都多。这篇文章就是把这段演进过程完整拆开讲讲一个典型的探索型项目是怎么从原型验证一步步走向规模化的。如果你手头正好也有一个边界模糊、需求不清、但又被寄予厚望的探索型项目这篇文章里关于节奏控制、架构拆分、数据策略和故障复盘的部分应该能直接抄作业。1. 出发点为什么把项目定位成探索型而不是一开始就做完整规划1.1 项目背景和那个模糊到极致的原始需求事情的起因很普通。公司内部积累了上千份项目文档、技术方案、复盘报告分散在Wiki、网盘、各团队的本地目录里。新同学入职想了解某个系统的架构得问五六个人翻七八个地方老员工想找一个两年前的技术决策依据经常需要在聊天记录里翻半天。领导在某次会上问了一句市面上不是有很多AI问答吗能不能把咱们自己的文档都喂进去搞个内部版的问答机器人这句话就是全部需求。没有明确的用户规模没有要支持的文档格式清单没有回答准确率标准甚至没有说这到底是个Web工具还是集成到IM里的机器人。我当时的第一个反应是这项目没法排期。但冷静下来想了想类似这种什么都说不清楚的需求恰恰是最典型的探索型项目信号——需求方自己也不知道要什么只有个模糊的价值期待。1.2 探索型项目的定义和边界以及为什么不能一上来就画大图我当时给团队和领导同步了一个认知这是一个探索型项目不是交付型项目。两者的区别在于交付型项目的需求、边界、验收标准相对明确拼的是执行效率探索型项目要把验证一个核心假设作为第一目标拼的是学习速度和试错成本控制。对咱们这个项目而言真正需要验证的不是AI能不能读文档这种宽泛的问题而是三个具体假设假设一公司内部文档乱归乱但通过合理的解析和切分AI给出的回答具备可用的准确率假设二团队愿意改变检索文档的习惯把这个问答系统当作日常工具来用假设三本地化部署的算力成本在可接受范围内。围绕这三个假设我们定了几条硬边界第一阶段不承诺覆盖率、不承诺高并发、不做复杂权限体系。听起来像在给自己留退路但实际操作中这几个不承诺极大保护了项目前期的探索空间。如果一开始就把目标定成全公司全场景可用团队就会陷入无休止的基础建设根本没有精力去验证最核心的问题——这个AI问答到底有没有用。1.3 验证标准先行的做法原型还没写评价口径先定好探索型项目最容易翻车的一个点在于所有人的预期建立在 demo 上而 demo 往往只跑了最顺利的那条路。所以我在写第一行代码之前带着团队做了一件事从各业务线收集了50个真实问题做成第一批评估集。这些问题包括XX系统的超时时间配置在哪去年双活改造的备选方案为什么被否新入职的测试同学应该看哪些文档等等。这50个问题成了整个项目最重要的资产。后面每一次改切分逻辑、换嵌入模型、调提示词策略我们都会用这批问题跑一遍回归记录回答命中率和质量评分。很多探索型项目做着做着就走偏了就是因为缺少这种固定的评估标尺今天看这个demo效果好就换这个方案明天看那个demo惊艳又换过去最后凭感觉做决策项目大概率拖死在摇摆不定上。2. 原型验证阶段在能跑就算赢和尽早暴露风险之间找平衡2.1 第一版原型技术栈的选型逻辑和成本考量原型阶段的技术选型就一条原则用最快能跑通的方式选自己最熟的技术栈不要为了炫技引入新东西。我们当时选了PythonFastAPI做后端前端先拿一个简单的Web页面顶着向量数据库用开源的Qdrant文档解析用成熟的unstructured库加自研的格式兜底逻辑嵌入模型用bge-m3LLM接口先接通用的API方便快速迭代。这套组合的核心逻辑是每个环节都有明确的替换空间。比如Qdrant在我们当时的数据量下完全够用就没必要一开始上大规模的分布式向量库嵌入模型先跑通pipeline后面发现效果不行可以随时切成其他的。原型阶段最忌讳的就是过度设计——想着最终要支持几百GB文档一上来就搭分布式集群结果一个月过去了连个能演示的demo都拿不出来。2.2 一周跑通最小闭环从文档进来到答案出去中间走通了哪几步第一个可演示的版本大概用了一周多一点的时间。流程不复杂上传文档后先解析成纯文本再用固定长度加重叠的方式切分成chunk批量跑嵌入写入向量库用户提问的时候把问题也做嵌入在向量库做相似度检索取top相关的chunk拼成prompt最后交给LLM生成答案。那段时间团队几乎天天改接口改prompt但目标非常明确就是让这个闭环能走通。等到demo能跑我们立刻拉了几个业务方来试用让他们拿真实问题去问我们坐在旁边记录失败案例。这个阶段的真实反馈比任何技术指标都重要——比如我们发现很多文档是扫描件纯文本解析出来全是乱码这直接带出了OCR能力的优先级又比如我们发现用户提问时习惯性地使用口语化表达比如之前那个限额为啥改的而文档里的描述是出于风控考虑调整交易限额这种语义鸿沟不是换模型就能解决的需要在查询改写和切分策略上做文章。2.3 原型阶段最容易忽略的事给小规模真实用户用而不是停留在demo演示很多团队的原型验证是演示成功即结束这是大忌。demo演示只能证明在选定场景下系统表现不错证明不了在真实使用条件下是否同样成立。我们当时的做法是找了三类用户做小规模灰度第一类是文档维护者他们对内容最熟能快速判断回答对不对第二类是高频检索的研发人员他们关心的是找得到、找得快、引用准确第三类是偶尔查资料的运营同学他们的问题跨度大、表述随意最能暴露检索泛化能力的问题。这三类用户用了两周之后我们收集到了非常清晰的原型验证结论检索命中率在精确匹配类问题上表现不错但语义理解类问题和跨文档综合类问题有大量失败案例性能上单机Qdrant和批量嵌入在数据量达到10万级chunk时开始有明显延迟。这两条结论直接决定了项目要不要从原型走向规模化——答案是肯定的因为有真实的用户反馈说这个工具比翻wiki强多了同时问题清单也足够明确告诉我们规模化之后要优先解决哪些事。3. 规模化的第一波冲击从小作坊能跑到多点同时用暴露出的问题3.1 扩容后出现的第一个问题同步嵌入把服务拖到假死状态原型阶段文档解析和嵌入是同步执行的——上传文档的请求进来解析、切分、嵌入、写入向量库全部跑完才返回结果。小规模用的时候没人觉得有问题因为最多同时传几个小文件耗个几秒钟无感。但真正放开使用之后立刻出事故了。某个下午运营同学一次性传了一个200多MB的PDF压缩包服务端同步处理嵌入任务把CPU和内存全部吃满其他所有用户的检索请求全部超时服务整体假死。复盘的时候我们意识到这不是性能优化的问题而是架构设计的问题——嵌入这类耗时任务就不应该出现在请求-响应的主链路上必须异步化。后来我们引入了任务队列上传文档后先把任务丢进去前端立刻返回解析中后台用worker慢慢消费检索服务独立的线程池和资源配额彻底把两条链路隔离开。这个改动本身不复杂但暴露出的问题是探索型项目很典型的原型阶段用能跑掩盖了大量架构缺陷这些缺陷会在规模化的第一时间集中爆发。3.2 检索质量出现玄学式退化同一批问题昨天答得好好的今天就答非所问第一个性能问题解决后紧接着就遇到了更棘手的检索质量退化问题。这事发生在一次例行升级里我们把文本解析库从旧版本升级到新版顺手优化了PDF表格的抽取逻辑。升级当天没发现异样第二天业务方反馈查系统限额那个问题答案突然开始胡说八道了。定位过程非常痛苦。我们先后怀疑了向量库索引损坏、嵌入模型版本被意外覆盖、prompt模板被改动等多个方向排查了两天才发现问题出在切分逻辑上——新版解析库对表格的处理方式变了导致一个本来应该完整保留在一段的表格被拦腰切成了上下两半每个chunk里的表格语义都不完整检索到的top chunk虽然关键词匹配但拼出来的prompt完全读不通。这个事故让我意识到数据管线的任何一层改动最终都可能体现在检索质量上所以在评估集上的回归测试必须成为每一次升级的强制关卡而不是可选项。3.3 从单机扛一切到拆开各管各的第一次架构重构的触发点规模化的第一波冲击中我们一共做了三个方向的调整。第一个是前面说的异步化改造第二个是把解析、嵌入、检索、问答四个模块从单体服务里拆出来各自独立部署和扩容——因为三者的资源消耗特征差异太大一个吃CPU的内存密集一个吃GPU的算力密集一个吃IO的并发密集捆在一起谁拖累谁第三个是给检索和问答环节加了缓存和限流防止典型的搜索热点问题打垮后端——比如新入职季大家集中问入职流程有哪些材料同一类问题在一小时内的重复查询量可能就有上千次。这次重构之后系统才算有了点产品的样子。现在回看这段我的体会是探索型项目并不是说不用做架构设计而是做架构设计的时机应该选在真实瓶颈出现之后而不是在预期中把每一步都做得严丝合缝。规模化的过程其实是问题驱动的——出什么问题解决什么问题带着问题做演进每一步都有明确的目标和验证标准才不会做成一堆没人用的华丽结构。4. 走向规范化数据策略、评估闭环和索引机制的三次升级4.1 从固定切分到结构感知切分chunk大小和重叠窗口为什么不能一锤定音原型阶段我们用的切分方式很简单固定500字一段重叠50字。这个方案在文档数量少的时候问题不大但随着接入的文档类型增多缺陷变得不可忽视了。最典型的例子是代码类文档和表格类文档。代码文档按500字硬切经常把一个完整的函数定义拦腰切断检索的时候明明匹配到了函数名上下文却少了函数体表格类文档更夸张硬切之后一行一行散落在不同chunk里语义完全碎裂。我们升级为结构感知切分先按文档本身的标题层级做结构识别再在最小的语义单元内做切分代码按函数和类切、表格按行列语义切、普通文本按段落和主题切。chunk的大小也不再固定而是允许在256到1024个字符之间浮动重叠窗口根据文本类型动态调整。这次升级的直接效果是评估集上的检索命中率提升了大约十几个百分点。更关键的是失败案例的结构发生了变化——之前失败的多是查到了但上下文不完整之后变成了没查到位后者通过优化嵌入和重排更容易解决。这让我体会到数据管线的很多参数是真的需要根据你的语料特征调的没有放之四海而皆准的默认值。4.2 嵌入模型和检索策略的权衡单向量不够用重排和查询改写什么时候该上检索质量的第二个突破口在嵌入和检索策略上。刚开始我们只用了单一向量做相似度检索top-5直接进prompt。后来发现一个问题文档里的很多专业术语和内部黑话比如XX系统当时为什么选MySQL不选PG用户问法五花八门但文档里的原始表达是高度标准化的单纯的向量相似度在这种场景下表现不够稳定。我们的做法是分两层进化的。第一层是做查询改写把用户问题先交给LLM做个简单的语义扩展和术语映射生成多个不同表述的检索query合并搜索结果第二层是引入重排模型向量检索先粗召回top-50再用重排模型精排取top-5进prompt。这两层加上去之后检索质量又上了一个台阶但代价是响应延迟增加了大约300毫秒、成本增加了约30%。后来我们做了个配置化的开关内部简单问题走快速检索路径复杂问题才走完整的改写加精排链路兼顾了体验和成本。4.3 建立数据反馈闭环把每一次用户的点踩变成下一轮迭代的弹药这里我想特别强调一下数据闭环。探索型项目最常见的死法是模型和检索策略定下来之后就再也不动了数据和反馈不回流系统实际在持续退化。我们从一开始就在问答页面加了有用/没用的反馈按钮以及复制答案查看引用来源这些行为埋点。用户点没用的时候系统会把问题、当时的回答、命中的chunk、用户可选的补充说明一起落库。每两周我们会从反馈库里捞一批失败案例人工标注失败原因——是检索没召回、还是召回不对、还是prompt组织有歧义、还是知识库里根本没有对应文档——然后针对性改进。这套机制直接促成了几个非常重要的迭代。比如我们发现有一类失败是因为知识库里的文档已经过时了但系统没有版本感知能力仍然把旧文档当权威答案给出来。这个反馈直接推动我们做了一个轻量级的知识有效期机制文档入库时记录维护日期和责任人检索时对超期文档降权。类似这种问题没有数据闭环之前是完全发现不了的这也是我强烈建议所有做类似系统的团队哪怕原型阶段也要留好反馈接口的原因——你的系统会随着使用慢慢长出记忆但这个记忆是好是坏取决于你有没有铺好收集反馈的路。5. 工程化改造当能用的demo要变成可信赖的服务5.1 配置管理、版本控制和多环境隔离探索型项目也要有的工程底线项目进入规模化之后之前一直将就的工程问题开始集中报销。最典型的一次事故是在生产环境误改了prompt模板的配置导致所有问答结果都变成了请查看相关文档的兜底话术业务方的第一反应是系统被黑客攻击了。排查了快两个小时才发现是有同事在调试的时候直接改了生产环境的配置文件。从那以后我们把配置管理全部纳入版本控制prompt模板、检索参数、模型开关这些全部放到配置中心管理并且严格区分开发、测试、生产三套环境任何改动都得走评审和发布流程。同时把嵌入模型、重排模型的版本号、向量库的schema版本这些全部纳入元数据管理线上系统跑的是哪一版模型、哪一版切分逻辑、哪一版语料随时可以回溯。我承认这些事情在原型阶段做确实会拖慢速度完全不划算。但规模化之后如果还没有这些基础那每一次上线都是一场赌博。我的经验是定一条线当真实用户超过50人、或者documents达到一定数量级的时候就把工程规范补上不用等到出事再补那时候的代价会翻好几倍。5.2 可观测性建设日志、链路追踪和核心指标大盘怎么搭探索型项目早期我们调试问题基本靠看日志找异常效率低到令人发指。特别是检索质量类的问题日志里只能看到查了哪些chunk看不到为什么这些chunk被认为相关事后复盘基本靠猜。后来我们花了大概两周时间搭了一套轻量级的可观测性体系全链路trace记录从用户提问、查询改写、向量检索、重排、拼prompt到LLM响应的完整路径和每个环节的耗时指标大盘上放了三组核心指标——性能类检索延迟、生成延迟、成功率、质量类反馈点踩率、回答引用率、top-1命中率、成本类token消耗、嵌入调用量、GPU使用率。这套体系搭完之后效果是立竿见影的。最直接的受益是再排查检索质量问题时不用再来回猜打开trace就能看到卡在哪一个环节优化迭代也有明确的数据支撑比如重排模型到底有没有带来收益看top-1命中率的变化就知道了。我跟团队说的一个观点是探索型项目里的可观测性不是给人看的仪表盘而是你迭代决策时的眼睛没有它做的一切优化都是蒙着眼睛在走路。5.3 容量规划和成本控制算力账单带来的现实约束探索型项目还有一个创业公司心里都懂但不爱说的现实问题成本。我们的成本大头有三个嵌入计算的GPU资源、LLM的token消耗、向量库的存储和索引开销。规模化之后每个月看着账单往上涨领导开始问了这东西到底值不值。我的处理方式是把成本拆到业务价值上去谈。比如LLM的token消耗按问答次数和平均token数换算得出单次问答的成本再去对比人工检索一条信息的时间成本这个账算下来是划算的。但光算账不够还得控制成本本身。我们做了几件事第一小模型和大模型分级使用简单的问题走轻量模型复杂问题才调度大模型平均成本降了约40%第二嵌入和索引的增量更新策略彻底放弃了每天全量重建的粗暴方案改成文档变更时只重嵌入变更部分第三给向量库做了冷热分层不常访问的老文档索引迁移到低成本存储。这些操作都不复杂但组合起来把项目从烧钱实验变成了成本可控的业务工具这是它能持续做下去的重要前提。6. 演进过程中的两次关键重构为什么能跑不一定是该留着6.1 第一次重构从单库单表到数据湖加向量索引的数据架构演进项目做到大概半年的时候我们做了一次比较伤筋动骨的重构。起因是数据规模涨上来之后原始的存储方式扛不住了。一开始我们把所有文档解析后的纯文本、chunk、向量、元数据全都放在同一个PostgreSQL里靠一个简单的表结构撑。当chunk数量突破百万级检索延迟翻了接近4倍而且文档更新频繁导致全量索引重建的成本越来越高。这次我们做了两个决定。第一个决定是把原始文档和解析后的结构化数据落到对象存储加数据湖里作为唯一的可信数据源职责是存得住、查得到、能回溯第二个决定是引入专门的向量数据库来做向量索引和相似度检索之前用的Qdrant升级成了集群模式支持更大规模的分布式检索。原有的PostgreSQL只负责存业务元数据比如文档归属、权限、维护状态这些。这次重构本身不性感但它解决了两个致命问题一是解耦了存储和检索两个环节的扩缩容二是让数据回溯和全量重建变得可行。如果一直守着最初的单体架构数据量再翻一倍系统大概率就要重写了那时候代价更高。6.2 第二次重构从检索问答一体到智能体编排的架构跃迁范围失控的教训第二次重构其实有点超出原来的计划范围是一次典型的探索型项目自己长出新的需求。当我们把检索问答做成一个稳定服务之后业务方开始提新的要求能不能不只回答文档里的问题比如帮我写一个项目周报能不能根据几个文档自动生成一份技术方案。这些需求的本质是要系统具备多步骤任务编排能力而不是回答一个问题就结束。我们当时没忍住很快就上了智能体框架把工具调用、多轮对话、任务编排都加了进去。结果这成了整个项目里最失控的一次扩张——智能体框架的学习成本高、调试难度大而且由于底层检索质量还没有达到足够稳的程度智能体在调工具的时候经常调错参数或者调错文档生成的结果不仅没提高效率反而让用户失去了信任。这次被教训打醒之后我们把智能体的开放范围收窄了只保留了审核过的模板化场景比如根据模板生成周报从若干文档里汇总要点其余自由编排类需求全部挂起。这个取舍很疼但回过头来看是对的在底层能力还不稳的时候过早上层的智能化只会放大不稳定性导致用户对整个系统失去信任那种损伤不是功能迭代能弥补的。6.3 技术债清理的优先级什么值得还什么可以等一等重构意味着要承认之前的技术债。但技术债不是所有的都该立刻还得排优先级。我自己的排序原则是正在阻碍业务迭代的债最优先比如模块边界模糊导致每加一个功能都要改一圈代码引发线上事故概率最高的债次之比如缺少配置管理、缺少灰度发布剩下的纯粹代码风格、单元测试覆盖这类能缓则缓。探索型项目的演进本身就是一场持续还债的过程完全不欠债的理想状态根本不存在也不值得追求——追求一个漂亮的架构而忽略了真实业务验证那才是本末倒置。真正重要的判断是每笔债能不能支撑到它被还上的那一天如果不行就提前还如果行就把它放在更紧迫的问题后面。有时候不完美的架构反而是探索期最好的选择。7. 一段演进路径的回望那些如果重新来过会坚持更早做的事项目走到今天不敢说多成功但确实有不少经验可以分享。如果让我回到项目最开始的时候有几件事我会更早开始做。第一件事是评估集。那50个真实问题组成的评估集是整个项目最值得的早期投入我们后来所有关于切分、模型、重排的决策都是基于这个评估集做的回归对比。真实用户的问题永远是最好的测试集早做早受益。第二件事是埋点和反馈。就算原型阶段页面丑、功能少也要把反馈按钮和基本埋点做上。数据积累需要时间等你想分析的时候再开始埋点往回看历史数据全是空的。第三件事是日志和trace。我理解探索期大家都在赶进度日志怎么简单怎么来但哪怕是原型阶段把检索命中了哪些chunk这类的关键信息记录下来成本很低、价值极高因为检索质量问题是这个系统最难排查的一类问题没有日志你将无从下手。第四件事是敢于砍需求。探索型项目的需求永远源源不断但团队的时间和精力有限。我最后悔的几次投入基本都是为了满足看上去很合理的需求而做的比如那个过早开放的智能体编排。后来我养成了一个习惯每接一个新需求之前先问它到底在验证哪个核心假设如果答不上来那就先放放。探索型项目最吸引人的地方就在于不确定性每天面临的问题都是新的没有现成的答案可以抄。但恰恰因为这样它逼着你建立起一套低成本试错、快速验证、持续演进的工作方法这套方法的价值远远超出那个项目本身。回头看这个系统最终变成什么样其实已经不是最重要的了重要的是我们这一路踩出来的路径给后面做类似探索的人省下了大量的弯路这才是最有价值的东西。