吴思扬先交代一下背景。我们团队一直做企业级应用研发，需求管理的模式从最早的共享文件夹、到在线文档、再到Jira和内部Wiki，前后换了三套工具，但一个最原始的问题始终没解决：当需求数量超过某个量级之后，人和人之间对“需求上下文”的沟通成本就指数级上升。新同学问“这个功能当初为什么要做成这样”，没人答得清；产品经理评审新需求时，经常不知道某个模块已经有三个历史方案；测试同学写用例时，也总漏掉那些“散落在会议纪要里”的决定。后来我把RAG（检索增强生成）和需求管理场景结合起来，做了一个内部的需求知识库问答与辅助分析系统。这篇文章是这个系列的完整落地记录，从动机、架构、技术选型，到踩坑和实测效果，一次讲清楚。它适合正在做AI应用的人、做研发管理和需求管理的团队负责人，也适合想了解RAG到底能在真实业务里做什么的开发者。
1. 为什么需求管理需要一场“检索革命”
1.1 越做越大的需求池，正在变成团队的“黑洞”
很多团队的现状是：需求池里躺着几千条记录，但真正能被有效利用的，可能不到三分之一。一个典型场景是这样的——产品经理接到一个新需求，需要判断和某个旧需求是否重叠。他先搜Jira，关键词一换就换了三轮，搜出来的结果要么太宽泛，要么根本对不上；再去翻Wiki，发现Wiki里的文档版本早就过期了；最后只能去问负责这个模块的老同事。同事回忆了十分钟，说“好像有个类似的，但当时没做，原因我记不清了，你去翻一下2022年X月的会议纪要”。
这不是个例，而是需求管理在“存储”和“使用”之间出现断层后的必然结果。工具能帮我们存下需求，但存下来之后能不能被准确、高效地“取出来”，决定了这些需求资产到底是团队的知识积累，还是一堆数字垃圾。
1.2 传统知识库的瓶颈：不是存不下，是取不出
Jira、Wiki、共享文档，本质上都是“人工检索+人工判断”的体系。它们有几个天生的痛点：
- 关键词搜索只能做字面匹配。需求在描述里写成“登录页面改版”，但相关需求用的是“用户身份认证流程优化”，两者在语义上高度相关，在字面上却毫无交集。
- 跨文档的信息孤岛。一个需求从提出、评估、立项到验收，信息散落在Jira工单、产品PRD、邮件讨论、会议纪要里。传统检索做不到把这些分散的信息片段按“同一个需求”重新组织起来。
- 历史决策的过程信息最容易丢。Wiki里通常会留下结论，但“为什么这么定”、中间考虑过哪些方案、因为什么原因否掉了某个思路，这些过程信息很少被记录下来。即便偶尔写在会议纪要里，也几乎没人会去翻。
也就是说，需求管理的本质问题从来不是“存储能力不足”，而是“取回能力太弱”。你存得再完整，取不出来，等于白存。
1.3 RAG能补上的关键一环：让历史需求“开口说话”
RAG的原理，用一句话概括：在让大模型回答之前，先从知识库里检索出一批和问题最相关的资料片段，把它们作为上下文塞给模型，模型基于这些事实来生成回答。这就意味着，答案不是模型凭空“编”的，而是有知识库作为事实依据的。
把这个机制搬到需求管理场景里，我们得到的是这样几种过去很难实现的能力：
- 自然语言查需求。不需要精心设计搜索关键词，直接用“之前有没有评估过把权限粒度细化到数据行的方案”这种口语化问题去问，系统能理解意图并召回相关文档。
- 跨文档的语义关联。一个需求涉及PRD、会议纪要、测试方案等多个文档时，RAG能把这些分散的片段按语义相关性同时召回到答案里。
- 答案带溯源。这是我认为RAG在需求管理场景里最有价值的一点。大模型给出的每条结论，都可以关联到具体来源文档，打开就能看原文。团队用起来更放心，也方便从“AI给的答案”跳转到“人自己核实”。
所以，RAG解决的不是“需求管理没地方存”的问题，而是“需求存了等于没存”的问题。这是这个项目的价值起点。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 系统整体设计：先把混沌的需求资产变成结构化知识
2.1 需求知识库的分层：原文档层、结构化条目层、语义索引层
我一开始的想法很简单：把所有需求文档灌进去，接个大模型，直接开问。但真正做起来发现，需求管理场景的文档形态太复杂了，简单粗暴地把PDF丢给RAG，效果会非常差。
原因是需求文档大多是半结构化甚至非结构化的：有标题层级、有表格、有流程图、有“需求描述”“验收标准”“影响范围”这样的固定段落。直接按固定长度切片，很容易把一个完整需求切成碎块，检索时召回的片段残缺不全。
我的方案是把知识库拆成三个层级：
- 原文档层：保留Jira导出的工单、PRD的原始文件，PDF和Word都有。这一层是“原始凭证”，用于追溯和核对。
- 结构化条目层：从原始文档中抽取出来的、颗粒度到“单条需求”的结构化内容。每条记录包括需求ID、标题、状态、关联模块、描述、验收标准、历史变迁记录。这一层是RAG检索的真正主体。
- 语义索引层：把结构化条目和文档片段做向量化，建好索引，供检索使用。
一句话总结这个设计：原文档管“存”，结构化条目管“理解”，语义索引管“取”。
2.2 技术选型：为什么选择RAG而不是微调
在动手之前，我认真对比过微调（Fine-tuning）和RAG两条技术路线。这里分享一下当时的关键考量。
微调适合的是“让模型学会某种固定的输出模式或业务规则”，比如让模型学会按固定格式生成需求文档、学会你团队的写作风格。但它不适合“回答一个需要依赖于大量事实性知识的问题”，原因有三点：
- 需求更新是持续的。把新需求“记”进模型参数里，相当于要反复微调，每次微调都要准备数据集和算力，周期长、成本高。
- 微调无法解决“引用来源”问题。你无法让模型在回答时告诉你“这个结论来自哪篇文档”。这在企业内部场景是不可接受的，一旦信息出错，追责和纠错的成本极高。
- 需求变化的时效性要求远高于模型训练的时效性。今天刚定的一个决策，明天就要被检索到，微调根本跟不上这个速度。RAG则天然适配——新的需求文档入库后，做完解析和向量化，立刻就能被检索到。
所以最终技术路线锚定为RAG。但我要强调一点：RAG不是“完全不用微调”，而是在当前这个阶段，RAG解决的是“让AI理解并引用团队自己的知识”这个更核心的问题。
2.3 系统架构与数据流
整个系统的数据流，可以拆成两条链路：一条是离线的“知识入库”链路，一条是在线的“检索问答”链路。
离线路链要做的事，是把所有历史需求文档（Jira导出、PRD、会议纪要）做标准化处理。具体流程是：文档解析 -> 内容清洗 -> 结构化抽取 -> 切片 -> 向量化 -> 写入向量数据库。这条链路跑一次全量，之后每天增量跑一次，保证新产生的需求能及时进库。
在线链路就是用户提问之后发生的事：用户输入问题 -> 对问题做改写和意图识别 -> 从向量库做混合检索 -> 对召回结果做重排 -> 组装Prompt -> 大模型生成回答 -> 返回答案附带引用来源。
3. 落地的核心链路：解析、切片、索引、检索、生成
3.1 文档解析与清洗：最难的不是PDF，是画了图的Word
文档解析是RAG系统里最不性感、但最决定上限的环节。我们遇到的问题比预想的多得多。
先看PDF。从Jira导出的PDF还好，结构相对规整，但很多PRD是PPT转成的PDF，文本被拆成一页页，页眉页脚、页码混在正文里，解析出来噪音很大。我们的处理方案是：先做版面分析，识别出标题区域、正文区域、表格区域，然后只保留正文和表格内容；页眉页脚用正则直接剔除。
真正的坑在Word文档。很多产品经理习惯在PRD里用文本框、形状来画功能区域划分图，这些内容在PDF导出稿里是一张图片，在Word解析时则是嵌在绘图画布里的文本。早期我们的解析流程会把这部分内容丢掉，导致检索时丢失了大量关键信息。后来换了能识别Word内嵌文本框的解析方案，才把这块内容完整捞回来。
表格解析是另一个重灾区。需求文档里的表格往往信息密度极高，比如权限列表、字段对照表，但PDF解析出来的表格经常行列错乱。我们为此做了专门的表格重建逻辑：先用解析工具拿到表格的坐标信息和单元格文本，再按坐标位置重建行列关系。这个环节花的时间比整个向量化链路都多，但非常值得。
3.2 切片策略：按需求条目切，而不是按固定长度切
切片策略是我在这个项目里反复调整最多的地方。早期图省事，直接按固定长度切片，比如512个字符一片，结果发现两个问题：
- 一个完整的“需求描述+验收标准”被腰斩，检索到的片段缺少关键信息。
- 跨切片的语义割裂，导致回答质量不稳定。
后来我把切片逻辑改为“按结构化字段切”。每条需求在结构化条目层本身就是一个天然的切片单位。在具体实现上，切片是按“标题+描述”“验收标准”“关联背景”“历史决策记录”这样分块处理的。大模型回答时，可以同时拿到需求的基本信息、验收标准和历史决策过程。
但这里也有一个平衡问题：切片切得太大，单次的上下文占用变高，成本上升；切片切得太小，上下文信息不完整，回答容易答非所问。我实测下来，单条需求切片的合理范围在400到800字之间。对于特别长的需求，我会在结构化抽取阶段就把“需求描述”“验收标准”“技术方案”拆成独立字段，每个字段单独切片，检索时再通过需求ID聚合。
3.3 向量化与索引：中文场景下的模型选择
向量化决定了检索的上限。我们在中文场景下对比了几个方案，这里直接给经验值。
- 早期用通用型英文embedding模型，对中文长文本的支持一般，查询词稍微口语化就召回不准。
- 后来切到BGE系列的中文向量模型，效果有明显提升。
- 再后来，考虑到需求管理场景里有大量专业术语和特定上下文，我们用历史需求数据做了无监督的领域适配训练，让向量模型更懂“权限”“审批流”“数据字典”这些词的语义边界。
有一个容易被忽略的点：向量维度。我们早期选了768维的向量模型，检索精度可以但存储开销和检索延迟都偏高。后来根据数据量级做了评估，压缩到384维，精度损失在可接受范围内，但索引体积直接小了一半，检索速度也快了不少。
向量数据库的选型，我们想的是要支持混合检索（稠密向量+稀疏关键词），同时要能按元数据过滤（比如按需求ID、模块、时间范围过滤）。对比了几个主流方案之后，最终选了支持这两种能力都比较好的一款开源向量数据库。这里提醒一句：不要只盯着向量检索的性能指标，要看它能否和业务元数据过滤做联合查询。否则你检索出来的结果里，可能有一堆“其他模块的需求”混进来。
3.4 检索策略：混合检索+元数据过滤+重排
如果只做向量召回，效果会偏“软”。比如问“2023年12月权限模块的需求”，向量召回的结果很可能把“2022年5月权限模块的需求”也带出来了，因为语义确实近。但这对用户来说是明显错误的。
我们的检索链路分三步：
- 混合检索：同时做向量检索和BM25关键词检索，再把结果合并。向量检索负责捕获同义改写、口语化表达；BM25负责保证精确词汇不丢失。合并的时候需要一个打分归一化的步骤，否则两种检索的打分口径不一致，没法直接混合排序。
- 元数据过滤：在检索阶段就根据提问中识别出的模块、需求状态、时间范围等条件，在向量数据库层面做条件过滤，把明显不相关的文档直接挡在召回之外。
- 重排：对混合检索出来的Top50结果，用重排模型做一次精细排序，取Top10作为最终上下文。实测下来，重排对答案质量的提升非常明显，尤其是当Top10窗口里混入不相关文档时，重排能有效把它们压下去。
在这里要特别强调元数据过滤和重排这两个环节。很多RAG教程只讲“向量化+检索+生成”，但这三件套在真实业务场景是不够的。没有元数据过滤，检索结果就像“大海捞针”，先是捞上来大量的针，再去判断哪根是你要的；有了元数据过滤，是先把水域缩小到一个小池塘，再捞针，准确率完全不在一个量级。
3.5 生成策略：让大模型当“需求分析师”，而不是“搜索引擎”
生成策略上我踩过几个坑。一开始我设计的Prompt是“请根据以下资料回答问题”，结果模型的回答特别“干”：把检索到的几个需求列出来就完了，缺少归纳和对比。后来我把Prompt重构了，给模型的角色定义是“需求分析师”，并在Prompt里明确了以下要求：
- 如果检索到的资料能支持结论，必须给出明确的结论。
- 如果资料之间存在冲突或矛盾，要明确指出冲突点，而不是回避矛盾。
- 如果检索到的资料不足以回答问题，要明确说“知识库中没有检索到相关信息”，并建议用户联系哪个角色确认，而不是强行编一个答案。
- 每一条回答都要标记引用的来源编号，对应到检索结果中的具体文档。
这里有一个非常关键的经验：要让大模型敢说“不知道”。RAG系统的价值不仅在于“能回答”，还在于“能意识到自己不知道什么”。一旦模型开始强行编造，它的可信度就会迅速归零，团队就再也不会用它了。
另外一个细节是历史会话的处理。我加了“上一轮问题+本轮问题”的合并改写逻辑。比如用户先问“A模块有哪几个需求”，再问“它们的责任人是谁”，系统需要先判断出“它们”指的是上一轮提到的A模块需求，才能正确执行检索。这个改写逻辑我用的是LLM来做，把最近两轮对话丢给模型，让它生成一个独立完整的问题用于检索。
4. 实测中的坑：检索不准、版本冲突、上下文断裂
4.1 旧版本需求“盖过”新版本：时间戳如何参与检索
这是我在实测中遇到的最典型的问题。我们有一个功能，历史上改过三次：2022年第一版是“仅管理员可导出”，2023年改成了“普通用户可导出自己创建的报表”，2024年又调整了审批链路。用户问“报表导出的权限是什么”，检索系统把三份历史文档全部召回了，结果三个版本的定义互相打架，模型给出的回答自然也是错乱的、前言不搭后语。
这个问题的根因是：文档解析阶段只处理了内容，没有把“版本时间”这个关键元数据结构化。解决办法是在切片入库时，把需求的不同版本打上版本号和时间戳，并且在上层增加一个“版本过滤”逻辑。具体来说是：同一模块的问题，优先取时间戳最新的版本；如果用户明确提到“2023年的时候”，再按指定时间范围过滤。这样处理之后，版本冲突的问题大幅减少，同时也保留了“历史版本也能追溯”的能力。
4.2 相似需求的语义覆盖问题
需求管理场景里有一种很特殊的情况：两个需求在语义上高度相似，但它们是完全不同的东西。比如“加一个用户搜索功能”和“把用户搜索功能加上模糊匹配”，听起来都是“用户搜索”，但前者是一个新需求，后者是一个现有功能的增强。如果向量模型语义粒度不够细，这两条需求容易被同时召回，导致AI给出“需求已存在”的错误结论。
这个问题的解决思路，不只是优化向量模型，更重要的是在Prompt阶段就要求模型区分“需求主体”和“需求变更”。我让模型在回答前先做一个判断：用户问的是一个新需求是否已经存在，还是对一个现有功能的调研？这两种问题类型，回答的路径完全不同。这已经不仅是RAG的问题，而是业务逻辑设计的问题。
4.3 专有名词、缩写、内部黑话，embedding模型根本不认识
这是我们项目里最棘手的问题之一。需求文档里充满了“退票”“OA审批”“统一门户”“BPM流程”这样的内部黑话，以及各种系统缩写。通用embedding模型虽然中文理解能力不错，但面对这些专有名词时，语义向量几乎找不到合适的映射空间。
我们做了两件事来解决。第一，维护了一份领域词表和别名表，在检索前对查询词做扩展。比如用户问“审批流”，系统会自动把问题改写成“审批流 OR BPM流程 OR 审批流程”，然后在检索时同时执行这些扩展词。第二，积累了一批“高频问题-标准需求”的标注数据，用这些数据对检索链路做过一轮评测，针对评测中暴露出的准确率问题，用负样本（也就是“看起来相关、实际不相关”的样本）对向量模型做进一步训练。
4.4 检索阈值和TopK怎么调才靠谱
很多RAG项目都会卡在这个问题上：相似度分数低于多少算“不相关”？TopK到底取多少？
先说相似度阈值。我一开始设的阈值是0.7，结果发现很多明明相关的需求被过滤掉了。后来查看具体向量分数，发现需求文档这种密集术语的文本，相似度分数天然比通用文本低一些。经过多轮测试，我们把阈值降到了0.55左右，并配合重排模型来兜底。结论是：阈值不是一个通用值，必须基于你自己的数据分布来做测试调优。
再说TopK。TopK太小，回答可能缺关键信息；TopK太大，无关信息会稀释答案质量。我实测下来的经验是：先取Top50做重排，再从重排结果里取Top10作为大模型的上下文。在做一些“统计盘点类”的问题时，TopK需要放宽到Top20，否则会漏掉部分需求。这个参数也应该是动态的，根据问题类型来做调整。
5. 效果怎么样、下一步怎么走
5.1 我们怎么评估：示例问题集+专家打分
评估RAG系统是个全员参与的事，不能只看“AI自己觉得答得不错”。我搭了一套相对轻量的评测方法：
- 准备了一个约100道题的评估集，覆盖四类典型问题：历史决策查询（“当初为什么这么设计”）、需求重叠判断（“有没有人提过类似的需求”）、功能归属查询（“XX功能在哪个模块”）、变更记录查询（“这个需求改过几次”）。
- 让产品经理和研发负责人分别给AI的回答打分，维度有三个：准确性（信息是否真实来源可溯）、完整性（是否漏了关键信息）、表达质量（是否容易理解）。
- 设置了基线对比：同一个问题，分别用“纯关键词搜索”“无RAG的大模型直接回答”“RAG系统回答”做对比，看差异在哪。
5.2 真实效果与收益
从评测结果看，RAG系统在四类问题上的准确率都明显高于纯关键词搜索，尤其在历史决策查询和需求重叠判断这两类问题上，效果最显著。
- 历史决策查询：这类问题过去基本无解，因为信息散落在会议纪要里，关键词搜索根本搜不到。RAG系统能把“当初讨论过什么方案、为什么选了这一个”的信息做跨文档聚合，这个问题的回答质量从“基本答不出”变成了“能给出带来源的完整答案”。
- 需求重叠判断：关键词搜索命中率惨不忍睹，因为“用户身份认证流程优化”和“登录页面改版”字面上毫无重合。RAG的语义召回能力结合历史版本的过滤逻辑，准确率提升非常明显。
- 功能归属查询：这类问题本身不复杂，但过去也需要人问人。RAG系统能直接给出答案，减少了很多低效沟通。
从团队使用情况看，已经有一批产品经理和研发人员把它当成日常工具来用了。“新功能评审前先问一下AI”已经变成了部分同事的习惯。一些高频问题（“这个模块有哪些历史需求”“当前正在开发的需求有哪些”）更是变成了团队的日常参考。
5.3 后续迭代方向
第一版跑通之后，下一步的规划主要有这么几个方向：
- 从“问答”走向“分析”。不只是回答问题，而是让AI主动做需求质量分析。比如输入一个新需求，AI能自动检索历史需求，识别出可能的冲突点、缺失项，甚至给出“建议重新评估”的提示。
- 融入需求变更流程。当有人提交一个需求变更时，系统自动检索所有关联的历史需求和当前实现方案，生成一份“变更影响范围”的初稿，帮助评估影响。
- 多模态支持。需求文档里有大量架构图、流程图、界面原型图。目前这些图片还只能以截图形式存起来，无法参与语义检索。后面想引入视觉模型，把图片内容也变成可检索的知识。
最后的一点体会
这个项目做下来，我最大的感触是：RAG在需求管理场景的价值，远不止“给AI接个知识库”这么简单。它本质上是在重塑团队的知识使用方式——以前是“人找知识”，现在是“知识找人”。当历史决策能被随时唤醒、需求之间的隐性关联能被自动发现，团队协作的底层逻辑就已经变了。不过也要提醒大家，RAG不是一个拿来即用的插件，需要针对业务场景做大量的适配、调优和评测。这个系列的后续文章，我会拆开讲文档解析、检索链路调优和Prompt设计的更多细节，欢迎关注。