← 返回概念解读

Concept Fable精修版

查询引擎

Query Engine · Retrieval/application abstraction

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

寓言故事

总问台把找资料和组织答案合成一套手艺

研究院有许多资料室:契约室、图纸室、旧案室和账册室。年轻助手会查书,也会写报告,但每次接到问题都临时决定去哪找、拿多少、怎么拼。简单问题还能应付。

若院长问“东桥修缮为何超支”,助手不是只拿到账册,漏了图纸变更;就是搬来十几卷原文,让院长自己翻。资料越多,回答反而越像碰运气。

院长先规定每问必查旧案室前五卷。遇到账目问题,这条路常错;遇到图纸层级和多次变更,又完全不够。各项目组后来各写查找小抄,同一问题在不同入口得到不同证据。

老馆长设立总问台。它先拆问题:要事实、比较、原因还是汇总;再选择资料室,必要时先找总卷,再追子卷;取回材料后剔除重复,按重要性重排,最后交给写报告的人整合。

第一版总问台也拿太多材料,报告人仍被淹没。老馆长加了取回上限和证据排序:最能回答问题的在前,背景材料放后,冲突证据要标出来。找得到不够,还要把材料组织到可用。

总问台不是自己知道所有答案。它知道如何把问题变成检索路线,如何在多种资料之间取证,如何控制拿回来的材料既够用又不淹没答案。

研究院后来发现,真正让问答稳定的,不是某个助手临场聪明,而是一座会组织查询、选择来源、重排证据和交付材料的问台。没有它,资料越多,回答越容易迷路。

后来总问台也学会拒绝。若问题太宽,它会先请院长缩小范围;若资料冲突,它会把冲突交出来,而不是硬拼成顺滑报告。研究院因此少了许多漂亮废话,多了能追到来源的答案。后来助手们也轻松了,因为他们不用每次从零猜该去哪间资料室。

揭示

这个故事讲的是:查询引擎

Query Engine 是 LlamaIndex 等框架中的应用抽象:接收用户查询,调用检索器或索引取回相关数据,并通过 LLM 或其他策略合成最终答案。它通常封装 retrieval、reranking、response synthesis、citation、query decomposition、metadata filtering 等逻辑。企业使用时要关注策略可调、答案可追溯、拒答、延迟成本和评测。

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

隐喻映射

  • 年轻助手临时决定:手写查询逻辑
  • 固定路线:单一 top-k RAG 模板
  • 各项目脚本:重复且不一致的应用层查询代码
  • 总问台:Query Engine
  • 选择检索、重排、分解、合成:查询引擎内部策略
  • 答案格式和引用:response synthesis 与 citations
  • 换索引和策略:可替换的查询抽象
  • 最后洞察:Query Engine 把检索和答案合成封装成面向应用的查询接口

Soloharness 判断

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

retrieverresponse synthesizerRAGindexagent