一家做工业品分销的企业上线查询助手之后销售同事发现了一个规律问题问得越具体得到的答案反而越离谱。有人问华南区上季度已经停售的型号还剩多少库存助手给出的清单里混进了华北区的产品也混进了当季在售的型号。团队最先怀疑的是切片质量他们调整了切分方式补充了同义词效果没有变化。真正的问题出现在提问进入检索之前系统为了让匹配更顺畅会把用户的问题改写成一段更适合检索的表述改写过程丢掉了华南区、上季度、停售这几个限定词检索范围随之扩大到全部数据与全部时段。改写环节之所以会丢限定条件原因可以归到几处。改写模型的目标是让句子更通顺、关键词更集中限定词在它眼里属于可以省略的修饰成分删掉并不影响句子成立。限定条件又一直以自然语言的形式混在句子里时间范围、组织范围、状态范围与业务对象揉在同一句系统没有为它们留出独立的表达位置也就无从检查它们是否还在。相似度算法本身并没有出错它按照系统交给它的那段表述去找最接近的片段表述里没有的限定算法也无从保留。还有一个环节上的原因改写发生在检索之前用户看不到改写后的表述链路里也没有一步把它与原始提问逐项比对。系统判定改写成功的标准通常是语义相近而语义相近与限定条件齐全并不是一回事。一种可采用的方案是把限定条件从自然语言里抽出来单独处理。输入是原始提问与从提问中识别出的限定条件识别项至少覆盖时间范围、组织范围、状态范围与业务对象。“上季度”“最近三个月”等相对时间条件应在执行时根据当前日期、时区和企业业务日历解析成明确时间区间并把解析结果作为本次查询记录的一部分。系统在提问进入链路的起始环节完成抽取随后才进入改写改写只负责表达部分限定条件不交给它处理。抽取出的限定条件不写在提示词里而是转成检索侧的过滤条件强制生效。抽取完成后还应把限定条件映射到企业定义的标准实体、枚举或业务维度值例如组织节点、商品状态码、SKU 标识等无法唯一映射时应先澄清不能凭自然语言近似匹配直接执行。租户范围、组织权限和数据访问边界等安全约束应由可信身份上下文直接注入检索条件并与用户显式提出的限定共同生效不能由查询改写决定是否保留。这套做法适用于地区、时间、状态、SKU、部门这类有明确结构化元数据的条件即使改写结果的表述变得模糊检索范围也不会被放宽。有些限定本身可能是语义性的例如“只看发生过质量投诉但尚未完成复检的型号”不一定能全部变成简单的元数据过滤器这类条件需要结合语义检索或专项判定保留在查询逻辑里并同样登记其执行范围。系统还会把原始提问、抽取结果与改写后的表述一并登记登记表提供回看入口方便业务人员核对某一次查询究竟按什么范围执行登记表还应当记录这一轮改写有没有改变查询范围业务人员可以据此统计改写带来的偏差。校验环节放在改写之后。系统逐项检查每个限定条件是否已经进入可执行约束可以表现为结构化过滤器、受控语义判定或其他明确登记的约束机制改写文本中是否保留相关表达只作为辅助检查。任何约束既没有进入执行条件也没有被明确保留时才视为丢失并退回处理。当某项限定条件无法解析例如用户说出的时间范围在企业口径里没有对应定义系统停下来向用户确认而不是放宽范围继续检索。维护责任需要分开。时间、组织、状态这些业务维度的定义由数据团队维护抽取规则与过滤器的实现由工程负责两边在业务维度变更时同步更新否则新加入的维度会在一段时间内无法被识别。通用模型与Agent平台通常提供检索增强与查询改写能力但限定条件怎么抽取、改写结果怎么校验、过滤器由谁维护这些环节仍需结合企业自身的业务维度体系单独设计。在青山不语AI工作室的AI定制方案中提问会先经过一轮限定条件抽取抽出的时间、组织与状态范围被转成检索过滤条件相对时间在执行时按企业业务日历解析为确定区间抽取结果还会映射到企业定义的标准实体与业务维度值租户与组织权限由可信身份上下文直接注入检索条件改写只对表达部分负责查询执行前后各有一次比对与登记。这套做法里企业需要先把自身的业务维度定义清楚哪些口径属于受控维度、维度的边界怎么划定由企业决定工作室负责把抽取、过滤与比对落在检索链路上并保留可以回看的执行记录。维度的边界一旦调整历史登记表里的旧口径仍要保留便于回溯当时的判定依据。验证时可以用一条带多重限定条件的提问走完整条链路再翻看登记表确认改写后的表述与过滤条件是否覆盖了原始限定。测试应当使用脱敏或者构造的数据避免把真实客户信息带进验证过程。我的判断是检索效果的差距往往不在相似度算法上而在提问被改写之后还剩下多少原意。企业评估AI定制服务时可以问一个具体问题这套方案能不能说清楚一次查询到底按什么范围执行。