投研 RAG 里，问题理解比向量检索更容易被低估

很多 RAG 项目一开始都会把注意力放在向量检索上：embedding 选哪个、chunk 多大、Top-K 取多少、要不要 rerank。

这些当然重要。但在真实投研问答里，我见到更多问题不是“相似度模型不够强”，而是系统从一开始就没理解用户到底在问什么。

投研用户不会总是问一个完整、规范、上下文独立的问题。他们更常问：

• “它最近怎么看？”
• “跟上个月相比呢？”
• “只看海外机构观点。”
• “把刚才那家公司换成同业龙头。”
• “有没有研报支持这个判断？”

如果系统把这些问题直接丢进向量库，召回质量很容易看起来还行，答案却偏掉。因为检索阶段接收到的查询已经错了。

RAG 不是从向量检索开始

在投研场景里，RAG 链路更像是两段式系统。

第一段是问题理解：把用户的自然语言问题改写成可检索、可约束、可验证的查询意图。

第二段才是检索和生成：根据查询意图去找材料，再在证据范围内组织回答。

如果第一段没有做好，后面的向量召回、BM25、混合检索和 rerank 都是在补救一个已经变形的问题。工程上可以调很多参数，但效果经常不稳定：这个问题变好了，另一个问题又坏了。

我更倾向于把“问题理解”单独当成一个模块，而不是把它藏在最终回答 prompt 里。它至少要输出几个结构化结果：改写后的查询、时间范围、实体、主题标签、资料类型、过滤条件和无法确定的部分。

指代消解决定追问能不能成立

投研问答很少是一次性问完。用户先问某家公司、某个行业或某个宏观主题，后面继续追问“它”“这个逻辑”“刚才那个风险”。

对人来说，这很自然。对系统来说，如果不做指代消解，第二轮问题就会退化成一个缺主语的短句。

例如第一轮问“某消费公司的利润率为什么下滑”，第二轮问“那它今年还有修复空间吗”。第二轮里的“它”到底指公司、利润率、行业需求，还是某个成本项？系统必须结合对话历史改写成明确问题，否则检索会召回大量泛化材料。

这里不能只把最近几轮聊天记录塞给模型生成答案。更稳的做法是先做查询重写：把追问改成一个可以独立检索的问题，并保留它来自哪一轮上下文。这样后续检索、日志和错误复盘都能看清楚系统当时理解成了什么。

时间范围不是一个装饰字段

投研问题里的时间词非常危险。

“最近”在不同问题里不是同一个范围。问新闻影响时，最近可能是几天；问行业景气度，可能是一到三个月；问宏观周期，可能要看更长的连续数据和研究观点。

如果系统不显式抽取时间范围，就会出现两类常见错误。

一类是拿过期材料回答当前问题。答案有出处，但出处已经不适合支撑当前判断。

另一类是只看最新材料，忽略用户其实在问趋势变化。系统会给出“今天有什么”的回答，却没有解释“和之前相比变在哪里”。

所以时间范围应该在问题理解阶段被显式化：起止时间、是否需要比较基准、是否允许使用历史背景材料、哪些资料必须是近期证据。这个字段会直接影响检索过滤，也会影响最终回答的证据边界。

实体识别比关键词匹配更难

金融文本里的实体不只是公司名。

一个问题可能同时包含上市公司、行业、产品、指数、地区、政策主体、宏观指标和资产类别。不同资料源里，同一个实体还可能有简称、别名、英文名、代码和上下游关系。

如果只按用户原句做向量检索，系统经常会召回语义相似但实体不对的材料。尤其在同一行业里，多家公司共享大量词汇，“毛利率承压”“库存去化”“需求修复”这些表达非常相似，但答案不能混着写。

实体识别的作用不是为了显得结构化，而是为了让系统知道哪些内容必须精确命中，哪些内容可以语义扩展。

公司、基金、指数、宏观指标这类实体通常需要更强的精确约束；主题、风险点、投资逻辑则可以交给语义召回。把两者混在一起，检索会显得覆盖很广，但回答不可靠。

标签过滤常常比纯向量更可解释

很多金融机构内部本来就有成熟的资料标签：行业、资产类别、地区、报告类型、研究主题、发布时间、来源等级。

这些标签不应该只作为展示字段，而应该进入检索策略。

例如用户问“只看海外机构观点”，这不是一个语义相似问题，而是一个过滤条件。问“近一个季度关于新能源车需求的研究观点”，里面同时有时间、行业、主题和资料类型。纯向量检索可能召回一些看起来相关的内容，但它无法稳定保证这些条件都被满足。

标签过滤的另一个好处是可解释。系统可以告诉用户：本次回答主要检索了哪些主题、哪些时间段、哪些资料类型。对投研用户来说，这比“相似度最高的片段”更容易被信任。

我的经验是，投研 RAG 不能只在向量库里找相似文本。更常见的稳定方案是混合检索：实体和标签先收窄范围，关键词和向量再补充召回，必要时再 rerank。

证据边界要在回答前确定

投研问答最麻烦的不是模型不会回答，而是它太会回答。

当检索结果很弱时，模型仍然能写出一段顺滑的行业判断；当证据只覆盖 A 公司时，它可能顺手推广到整个行业；当材料只有新闻，没有研报支持时，它也可能写成“研究观点显示”。

这类问题不能只靠 prompt 里的“不要编造”解决。系统需要在回答前确定证据边界：

• 当前证据能不能支撑这个问题
• 证据覆盖的是公司、行业，还是宏观主题
• 来源是研报、新闻、公告，还是内部摘要
• 是否存在足够近期的材料
• 哪些结论只能作为背景，不能作为当前判断

如果边界不够，回答就应该收缩，甚至直接说明没有找到足够材料。RAG 的价值不是让模型永远有话说，而是让用户知道哪些话有依据。

一个更可用的投研 RAG 查询链路

我在真实企业项目里更愿意把投研问答拆成这样的链路：

1. 读取当前问题和必要的对话历史。
2. 做指代消解，把追问改写成独立问题。
3. 抽取时间范围、实体、主题、资料类型和过滤条件。
4. 判断哪些条件必须精确匹配，哪些可以语义扩展。
5. 按标签、关键词、向量等策略并发检索。
6. 对证据做去重、排序和边界检查。
7. 只基于合格证据生成回答，并附上来源。

这条链路看起来比“用户问题 -> 向量检索 -> LLM 回答”麻烦很多，但它更接近投研用户真实使用系统的方式。

我的判断

投研 RAG 的核心不是把资料放进向量库，而是把一个含糊的自然语言问题变成一组可以执行的检索约束。

向量检索解决的是“哪些文本语义相近”。真实投研问答还要解决“用户说的它是谁”“最近是多久”“该看哪类资料”“哪些实体必须命中”“证据能支持到什么程度”。

这些问题如果不在系统里显式处理，RAG 很容易在 Demo 里表现不错，在真实对话里变得飘。用户问得越像真人，系统越容易暴露查询理解的短板。

所以我现在看投研 RAG，会先问一个问题：系统有没有认真理解问题，还是只是把问题拿去做相似度搜索？

如果你正在做企业 RAG、知识库、AI 客服或 Agent 工作流，可以通过页面下方微信二维码或邮件沟通，邮箱：contact@aildnc.com。