2022 年，我为一个财税新产品整理过一份技术方案。当时讨论了 Query 理解、推荐架构和财税知识碎片化，也列出了分词、意图识别、召回、排序、知识抽取等大量算法。
几年后重新看这份方案，具体模型早已不是最重要的部分。真正经得起时间检验的，是当时做出的一个优先级判断：
财税知识结构化 > Query 理解 > 推荐排序。
这不是说排序不重要，而是说在强领域、强时效、强约束的财税场景里，系统上限首先由它能否正确表达知识决定，其次由它能否正确理解用户问题决定，最后才是如何把候选结果排得更好。
如果知识源不完整，Query 理解再准确也只能召回残缺答案；如果没有识别地区、主体类型和生效时间，模型越自信，风险反而越高；如果前两层没有做好，复杂的推荐模型只是在更精确地放大错误。
财税搜索真正困难的地方
通用搜索经常在“相关性”上竞争，而财税搜索必须同时满足五类约束。
第一，用户表达往往不完整。“小规模怎么开票”“重庆研发费用怎么扣”“个税还能退吗”都不是完整的业务问题。主体是谁、发生在什么时间、适用哪个地区、属于哪类业务，可能没有直接写在 Query 里。
第二，专业词汇具有强领域含义。一个词在日常语言、会计语言和法规语言中的含义可能完全不同，同一个概念还可能存在俗称、旧称、缩写和政策原文等多种表达。
第三，答案具有时效性。财税知识不是静态百科。政策有发布、生效、废止和过渡期，地方口径也可能不同。相关但已经失效的答案，不是低质量答案，而是错误答案。
第四，结果存在多目标权衡。用户既需要权威法规，也需要读得懂的解读和可执行的操作指引。系统必须在权威性、相关性、可读性、时效性与个性化之间做显式权衡。
第五，输出必须可追溯。用户可以接受系统说“我无法确定”，却不应该接受一段无法指出依据的确定性回答。
所以，财税搜索不是“把文档放进向量数据库，再让大模型回答”。它是一套从知识治理到查询理解、从多路召回到风险控制的决策系统。
Query 理解的输出不应该只是一组标签
传统 Query 理解常被拆成预处理、分词、纠错、扩展、实体识别和意图分类。这些能力仍然有用，但生产系统真正需要的是一个稳定、可审计的结构化查询对象。
例如，用户输入：
重庆小微企业今年增值税怎么交？
系统内部可以得到：
{
"rawQuery": "重庆小微企业今年增值税怎么交？",
"normalizedQuery": "重庆 小微企业 2026 增值税 申报缴纳",
"intent": "tax_policy_and_procedure",
"entities": {
"region": "重庆",
"taxType": "增值税",
"businessType": "小微企业"
},
"constraints": {
"effectiveAt": "2026-08-06",
"authorityLevel": ["国家", "重庆"]
},
"rewrites": [
"重庆小微企业增值税优惠政策",
"重庆小微企业增值税申报流程"
],
"confidence": 0.91,
"needsClarification": false
}
这个对象比“意图=政策查询”更有工程价值。它可以被召回、过滤、重排、回答生成、日志和评测共同消费，也能清楚说明系统在哪一步理解错了。
当置信度不足或缺少决定性条件时，正确动作不是强行猜测，而是请求补充信息。例如“公司买车怎么抵扣”至少需要确认主体、用途、发票类型和业务发生时间。
用可观测流水线代替算法堆叠
我在 2022 年方案里采用了 Pipe-Filter 思想：一个稳定基座承载数据流，每种算法作为可插拔 Filter 接入。这个思想仍然适用，但今天更重要的是为每个阶段定义输入输出契约、评测方法和降级策略。
一条生产级 Query 流水线可以这样组织：
- 输入规范化：字符、单位、日期、法规编号、地区别名和企业类型规范化。
- 安全与范围识别：识别敏感输入、越权请求和产品不能回答的问题。
- 意图与实体解析：提取任务目标、业务实体、时间与地域约束。
- Query 改写与拆解：纠错、同义表达、专业术语映射；复杂问题拆成多个可检索子问题。
- 多路召回：关键词、语义、规则、知识关系和行为数据并行召回。
- 融合与去重：合并不同召回通道，避免单一分数体系支配结果。
- 重排与业务约束：结合语义相关性、权威等级、时间有效性和用户上下文精排。
- 可信度校验：检查证据覆盖、政策状态、引用一致性与冲突来源。
- 结果呈现：返回答案、证据、适用范围、不确定性和下一步操作。
每个 Filter 都应记录版本、耗时、输入摘要、输出摘要与失败原因。出现超时或模型不可用时，系统可以退回关键词搜索和规则过滤，而不是让整条链路失效。
多路召回：不要在关键词和向量之间二选一
财税检索天然适合混合架构。
关键词召回擅长法规编号、税种、专业术语、精确短语和数值条件。BM25 仍然是重要基线，不能因为有了 Embedding 就被抛弃。
向量召回擅长口语表达、概念近义和没有共享关键词的语义匹配。例如“员工出差住酒店开的票能不能抵”与“住宿服务增值税进项税额抵扣”在字面上差异很大，但语义高度相关。
规则召回处理不能模糊化的硬约束，例如地区、生效日期、企业资格和政策状态。
知识关系召回适合沿着“政策—税种—主体—业务事项—材料—办理流程”等关系寻找上下游信息。
行为召回只有在拥有足够、合规且去偏的真实反馈后才值得引入。点击并不天然代表答案正确，停留时间也可能来自内容难懂，因此行为信号必须经过业务解释。
多个召回通道不应简单拼接。可以先用 Reciprocal Rank Fusion 等方法进行稳定融合，再用重排模型处理 Top-K 候选。融合阶段追求不漏，重排阶段追求次序，业务规则负责守住不能被相关性覆盖的边界。
推荐不是一个模型，而是一段决策过程
原方案中使用“推荐算法 + 召回 + Rank”概括工业级推荐架构。今天我会把它表达得更明确：
候选生成
→ 资格过滤
→ 去重与多样性控制
→ 粗排
→ 精排
→ 业务约束
→ 解释与展示
候选生成解决“可能有什么”；过滤解决“哪些绝对不适用”；排序解决“哪个更值得先看”；解释解决“为什么推荐给你”。
对于财税内容，精排分数至少应包含：
FinalScore =
SemanticRelevance
+ AuthorityWeight
+ FreshnessWeight
+ ContextMatch
+ EvidenceCoverage
- ExpirationPenalty
- ConflictPenalty
这不是固定公式，而是一种设计提醒：相关性只是信号之一。法规已废止、地域不适用或缺少原文依据时，再高的语义分也不能进入最终答案。
知识层决定系统的长期上限
“知识碎片化”是原方案里优先级最高的问题，这一点今天更加重要。一个可靠的知识层至少包含四项工作。
1. 知识获取
从法规原文、政策解读、办事指南、问答案例和企业内部资料中获取内容，同时保留来源、发布日期、发布机构和原始链接。
2. 知识结构化
抽取实体、属性与关系，但不必一开始就建设庞大的知识图谱。先从影响适用性的核心字段开始：
政策 → 发布机构
政策 → 生效/废止时间
政策 → 适用地区
政策 → 适用主体
政策 → 税种
政策 → 业务事项
政策 → 替代/引用政策
3. 知识融合与冲突处理
同一政策可能被多个来源转载、解释甚至错误概括。系统需要完成实体对齐、版本合并、权威层级判定和冲突标记，而不是把重复文本全部交给模型自行判断。
4. 质量评估与增量更新
知识必须有可计算的健康状态：来源是否权威、当前是否有效、字段是否完整、是否存在冲突、多久没有复核。政策变化应触发增量更新和受影响答案重评，而不是定期全量重建后等待用户发现错误。
大模型应该放在哪里
大模型显著提升了 Query 理解、语义改写、复杂问题拆解和自然语言回答能力，但它不应该成为没有边界的中心节点。
适合交给模型的工作包括：
- 从口语 Query 中提取结构化意图和实体；
- 生成多种检索表达；
- 将复杂问题拆成可验证的子问题；
- 对召回结果进行语义重排；
- 基于已确认的证据组织答案；
- 识别证据之间的冲突并请求人工判断。
不应只交给模型的工作包括：
- 判断法规是否仍然有效；
- 执行权限与数据隔离；
- 决定高风险业务动作；
- 在没有来源时补齐“看起来合理”的事实；
- 代替确定性的地区、日期和资格过滤。
原则很简单：让模型处理模糊性，让系统处理确定性；让模型提出判断，让证据和规则约束判断。
评测比模型选型更值得长期投入
没有评测集，架构优化最终会退化成对几个演示 Query 的主观调参。
建议从真实问题中建设分层评测集：
| 层级 | 主要指标 | 关注的问题 |
|---|---|---|
| Query 理解 | Intent Accuracy、Entity F1 | 有没有理解用户在问什么 |
| 召回 | Recall@K | 正确证据有没有进入候选集 |
| 排序 | NDCG@K、MRR | 正确结果是否足够靠前 |
| 回答 | 证据覆盖率、引用正确率 | 每个结论是否得到证据支持 |
| 业务 | 解决率、二次搜索率、人工接管率 | 用户是否真正解决问题 |
| 风险 | 过期引用率、越权率、无依据回答率 | 系统是否守住底线 |
评测数据不能只包含成功样本。含糊表达、错别字、跨地区政策、多意图、过期法规和互相冲突的来源，才真正决定系统是否能进入生产环境。
如果今天从零开始
我不会先训练一个大模型，也不会先画一张覆盖所有算法的全景图。我会按以下顺序推进：
- 选择一个边界清晰的财税任务，定义“正确答案”和不可接受错误。
- 建立最小知识模型，先解决来源、时效、地区、主体和政策关系。
- 用 BM25 + 向量召回建立混合检索基线。
- 把 Query 解析成稳定的结构化对象，并对低置信度问题主动澄清。
- 加入重排、引用和规则校验，确保答案可解释、可追溯。
- 用真实失败 Query 建立评测集和每周回归机制。
- 只有当基线暴露出明确瓶颈时，再增加知识图谱、个性化和多 Agent 编排。
回头看 2022 年的设计，我最大的感受不是“当年的算法已经过时”，而是工程判断必须比模型寿命更长。
一个可靠的财税智能系统，不是因为使用了多少先进模型，而是因为它知道知识从哪里来、适用于谁、何时有效；知道用户真正想解决什么；也知道在证据不足时停下来。
这三件事，至今仍然比模型名称更重要。