← 返回概念解读

Concept Fable精修版

查询改写

Query Rewriting · Retrieval

先读故事。这里不急着给定义,先让问题自己长出来。

寓言故事

把抱怨改写成档案馆能听懂的问题

问路亭里,外乡人常把问题说得含糊:“去卖蓝布那家怎么走?”“找上回修伞的老头。”亭卒若照原话去查路册,十有八九查不到。路册只认街名、铺名和登记号,不认人的记忆碎片。

起初亭卒只会反问,队伍越排越长。后来他学会把客人的话改写成路册能认的线索:蓝布可能是染坊街的周记布庄,修伞老头可能是南桥胡师傅。查找速度立刻快了。

改写也会出错。有次客人说“白塔旁的药铺”,亭卒改成白塔街药铺,结果真正地点是白塔寺后门。客人越急,原话越短,亭卒越不能自作主张。

老亭长定规矩:能确定的,改成标准地名;有歧义的,先补问;重要差事,保留原话和改写后的线索一起查。第一次修补的问题在于只追求能查到,却没保留人原本想问什么。

后来亭卒会把一句抱怨拆成几种可能。客人说“上次那家坑人的驿站”,他先问是寄信、换马还是住宿;若可能指向两家店,就把两条线索都列出来,而不是只选听起来顺的一条。

问路亭找对路的次数多了,争吵也少了。客人仍用自己的说法,路册仍用自己的编号,中间需要一个能翻译、补问和保留歧义的人。

问得好,不一定是把原话原封不动丢进册子。把人的含糊说法整理成可查、可匹配的问法,常常决定能不能找到正确答案;但改写一旦过头,也会把人带去错误街口。

后来老亭长把错路案例挂在墙后。每次改写害人走错,就记录原话、改写、补问缺口和正确地点。亭卒们慢慢学会,好的改写要帮助查找,也要尊重不确定;听不懂时,先问清再下笔。后来问路亭因此少了许多冤枉路,路册也不再被含糊问法拖累。

揭示

这个故事讲的是:查询改写

Query Rewriting 是把用户原始问题改写成更适合检索、数据库查询或工具调用的形式。它能补全指代、标准化术语、拆分复杂问题、生成多路查询,并提升 RAG 召回质量。风险是改写改变意图或引入错误前提,因此需要保留原始 query、记录改写过程,并在高风险场景做评测。

它重要的地方在于:它不只是一个术语,而是在真实 AI / Agent 系统里会反复出现的结构性问题。理解它,才能判断什么时候该加模型,什么时候该改流程,什么时候该补治理。

隐喻映射

  • 含糊抱怨:原始用户问题
  • 抄录员后台改写:query rewriting 模块
  • 关键词型、语义型、结构化型:面向不同检索后端的改写策略
  • 保留原问题和改写版本:可观测与审计要求
  • 不改变用户意图:改写质量的核心边界

Soloharness 判断

这个概念的实战价值,是帮你把“看起来聪明的 AI 功能”拆成可交付、可验收、可治理的工作单元。

query expansionHyDE