# AIVA Query 集生成方案与 Query-Agent 设计实践：从 GEO 研究到法律垂类落地-育师

一、引言：GEO 检测，首先要解决测什么的问题

在开发 AIVA（AI Visibility Intelligence Platform，AI 可见度智能检测平台）的过程中，我越来越明确一个判断：

GEO 检测的核心，不只是调用多个大模型、统计品牌有没有出现，而是建立一套合理、可复现、能够持续演进的 Query 测量体系。

假设我们要评估一家沈阳的律师事务所，在 ChatGPT、DeepSeek、Kimi 等 AI 产品中的可见度。

如果只问一句：

沈阳有哪些比较好的律师事务所？

然后根据 AI 是否提及目标律所判断可见度，显然是不够的。

因为用户可能咨询劳动争议、合同纠纷、婚姻家事、交通事故，也可能寻找企业常年法律顾问。不同问题对应不同的服务需求，AI 的回答也可能完全不同。

如果每次检测都临时让大模型生成一批问题，还会出现新的问题：

不同轮次的 Query 不一致，检测结果难以直接比较。
某些业务场景被大量重复提问，其他场景却没有覆盖。
模型生成的问题看似合理，却不一定符合真实用户的查询习惯。
品牌相关问题和行业通用问题混在一起，容易高估品牌可见度。
Query 数量、目标模型和重复运行次数相乘，带来调用成本与统计偏差。

因此，AIVA 需要解决的不只是 Query 生成，而是三个相互关联的问题：

如何设计有代表性的 Query 集？
如何通过 Query-Agent 自动生成、校验和管理这些 Query？
如何利用稳定的 Query 集，对不同 AI 模型的品牌可见度进行可复现测量？

本文结合国内外 GEO 研究、法律领域评测基准的公开实践，以及 AIVA 前期的架构设计，讨论一套可以逐步实施的 Query 集生成方案。

需要说明：本文介绍的是 AIVA 的工程设计方案。除引用的公开研究外，文中的 Query 数量、模块设计和验收目标属于工程建议，并不代表 AIVA 已完成相应规模的生产验证。

二、从国内外研究中，我们能学到什么？

在设计 Query-Agent 之前，先看几个值得参考的研究方向。

2.1 GEO 研究：查询集合需要覆盖多种用户表达

2024 年，Aggarwal 等人在论文《GEO: Generative Engine Optimization》中提出生成式引擎优化的研究框架，并通过 GEO-bench 对多个领域的查询和相关来源进行系统实验。研究指出，GEO 策略的效果会因领域而异。

论文链接：GEO: Generative Engine Optimization

这项研究对 AIVA 的启示，不是直接复制某个 Query 列表，而是建立一套能够覆盖不同查询场景的测试集合。

同一个需求，用户可能使用不同表达方式：

沈阳有哪些律师事务所？
沈阳有哪些擅长劳动争议的律师？
公司拖欠工资，应该找什么类型的律师？
沈阳有哪些可以提供企业常年法律顾问服务的律所？

这些问题的意图、具体程度和地域限定都不同。如果只测量少数固定问题，很容易遗漏品牌在其他场景中的表现。

2025 年的《Generative Engine Optimization: How to Dominate AI Search》进一步通过跨领域、跨语言和不同 Query 表达方式的实验，分析生成式搜索与传统搜索的差异。研究报告指出，不同 AI 搜索服务在信息来源、内容新鲜度、跨语言稳定性和措辞敏感性方面存在差异。

论文链接：Generative Engine Optimization: How to Dominate AI Search

对 AIVA 来说，这意味着：

Query 集不能只围绕单一措辞设计。
不能假定不同模型对同一问题的处理方式完全一致。
应当区分问题本身的变化与目标模型回答的变化。
不同垂类需要经过独立验证，不能直接套用同一套 Query 分布。

AIVA 的设计选择：先定义测量意图和主题，再生成具体问题，而不是让模型自由发挥。

2.2 法律 RAG 基准：高质量样本需要结构化标注

法律领域有一个很重要的特点：问题看似相似，实际考察的法律关系可能完全不同。

例如：

公司没有签订劳动合同，员工可以怎么办？
员工主动离职，是否可以要求经济补偿？
公司违法解除劳动合同，赔偿如何计算？

这些问题都属于劳动争议，但不能简单视为同一个 Query。

2024 年提出的 LegalBench-RAG 专门关注法律 RAG 的检索环节。该基准包含 6,858 个 Query-Answer 对，并强调从法律语料中定位精确、相关的文本片段，而不是仅返回宽泛的文档标识。

论文链接：LegalBench-RAG

2025 年发表的 LexRAG 则面向多轮法律咨询场景，构建了包含 1,013 组多轮对话样本和 17,228 条候选法律条文的评测基准，并结合专家标注和评测工具考察法律知识检索与答案生成。

论文链接：LexRAG

这些研究的直接任务是法律 RAG 或法律问答，并非 GEO 品牌可见度测量。因此，不能直接把其中的法律问答样本当作 AIVA 的品牌 Query 集。

但它们提供了重要的方法论参考：

Query 应当有清晰的任务定义。
复杂场景需要细粒度分类，而不是仅使用一个宽泛标签。
评测样本需要有可追溯的来源与标注信息。
专家审核和自动化评估可以结合使用。
需要区分检索、回答生成等不同环节的质量。

2.3 国内法律大模型研究：真实问题与分层分类很重要

国内的法律问答研究也提供了类似启示。

例如，《基于法条检索的生成式法律问答研究》提出了细粒度刑法问答数据集 FCL-QA，以及法条检索增强问答框架 SaRAF。其方法包括多级主题分类、缩小相关法条范围、再利用大模型生成答案。

论文链接：基于法条检索的生成式法律问答研究

另一个值得关注的工作是 LegalAgentBench。该研究发表于 ACL 2025，面向中文法律领域的 LLM Agent 评测，整合了 17 个真实法律场景语料库和 37 个用于外部知识交互的工具，并且不仅评估最终任务成功率，还关注中间过程中的表现。

论文链接：LegalAgentBench

对 AIVA 的启示是：法律垂类不能只按照“法律咨询”一个大类生成问题，而应当把法律主题、服务需求、地区约束和用户决策意图分开管理。

不过需要明确，法律能力 Benchmark 与 GEO 可见度 Benchmark 的目标不同。前者主要评估模型能否完成法律任务；后者关注品牌在相关用户问题下如何被提及、描述、推荐，以及回答是否有可追溯的来源。

AIVA 应借鉴它们的数据构建与评测方法，而不是直接复用它们的评分标准。

三、先把 AIVA 的 Query 集分成两类

这是整个方案最重要的设计决策之一。

AIVA 既需要行业层面的稳定测量基准，也需要针对某个品牌的个性化 Query 集。

这两者解决的是不同问题，必须分开。

3.1 第一类：行业基准 Query 集

行业基准 Query 集由平台维护。

以法律服务为例，它应该覆盖全国范围内有代表性的法律服务需求，包括：

劳动争议
婚姻家事
合同纠纷
交通事故
企业法律顾问
法律服务机构选择与比较
法律信息核验

这类 Query 不应该围绕某一家具体律所设计，而应该尽量保持行业中立。

例如：

企业遇到合同纠纷时，应该如何选择律师事务所？

在沈阳发生劳动争议，可以通过哪些渠道寻找法律帮助？

选择企业常年法律顾问时，应该比较哪些服务内容？

通过固定的行业基准集，AIVA 可以观察不同模型在相对稳定的问题集合下，如何呈现法律服务机构及其相关信息。

需要注意：行业基准集不等于全国真实用户搜索频次的统计样本。若没有真实查询日志、可靠的调查数据或其他可验证的频次来源，就不能声称它代表了全国用户的实际搜索分布。

3.2 第二类：品牌专属 Query 集

品牌专属 Query 集根据某一家律所的实际情况生成。

假设一家律所提供以下信息：

品牌名称：明衡律师事务所
行业：法律服务
核心业务：劳动争议、合同纠纷、企业法律顾问
服务地区：沈阳
目标客户：中小企业及劳动者
品牌官网：已提供并经用户确认

那么 AIVA 可以围绕这些信息生成品牌相关 Query。

例如：

沈阳有哪些提供劳动争议法律服务的律师事务所？
沈阳有哪些可以为中小企业提供常年法律顾问服务的律所？
明衡律师事务所主要提供哪些法律服务？
选择沈阳的企业法律顾问时，应该比较哪些方面？

这里有一个边界：品牌 Profile 中没有提供律师资历、获奖记录或案件胜诉率，Query-Agent 就不能将这些信息当作已知事实。

同时，品牌专属 Query 集也不应全部直接点名该品牌。否则，检测结果只能说明模型在被直接询问该品牌时如何回答，不能充分反映品牌在非品牌行业问题中的可见度。

3.3 两类 Query 集的区别

维度	行业基准 Query 集	品牌专属 Query 集
所有者	AIVA 平台	品牌项目
主要目标	观察行业层面的回答表现	观察特定品牌的可见度
是否点名品牌	原则上不依赖某一品牌	可以包含，也应包含非品牌问题
是否使用品牌资料	通常不需要	必须使用已确认的 Brand Profile
更新方式	按基准集版本治理	按品牌信息和用户确认生成新版本
主要用途	横向基准、长期观察	品牌诊断、竞品比较、复测

两类数据可以共享通用意图体系和行业配置，但不能混成一个没有明确用途的 Query 池。

四、法律垂类基准集：如何从零开始构建？

前面讨论 AIVA 法律垂类时，我们提出过一套初始工程规划：

全国核心 Query：120 条。
区域 Query：31 个省级行政区，每个地区暂定 2 条，共 62 条。
候选诊断池：200～500 条，供筛选、补充和后续迭代。

这是一套建议的初始工程规模，不是经过统计学验证的全国代表性样本规模。最终规模应根据测试成本、专家审核能力和覆盖效果调整。

4.1 全国核心 Query：120 条

建议把 120 条作为初期建设目标，分为两类。

第一类：法律信息与问题理解。

例如：

劳动争议的常见处理路径有哪些？
企业签订合同时需要重点审查哪些事项？
婚姻家事纠纷通常涉及哪些法律问题？
交通事故发生后，处理赔偿争议需要注意什么？

第二类：法律服务发现与选择。

例如：

选择劳动争议律师时，应该比较哪些因素？
企业寻找常年法律顾问时，应重点考察哪些服务内容？
发生合同纠纷时，如何选择适合的法律服务机构？
寻找律师时，应该通过哪些渠道核实执业信息？

这两类 Query 的测量目标不同。

法律信息类主要观察回答内容、法律依据和信息来源；法律服务发现类则更适合观察品牌是否进入相关候选集合、是否被推荐，以及回答中如何描述品牌。

如果把两类问题混在一起计算一个分数，报告的解释力就会下降。

4.2 区域 Query：62 条

法律服务具有地域特征，部分问题与地方司法管辖、办事渠道或本地服务机构有关。

初期可以按照 31 个省级行政区，每个地区配置 2 条区域问题，形成 62 条的起始集合。

例如：

北京地区有哪些渠道可以寻找劳动争议法律服务？
广东地区的企业选择常年法律顾问时，应重点关注哪些因素？

这里的地区数量是工程规划，不意味着每个地区的两条问题足以代表当地法律需求。

后续应该结合当地业务结构、真实咨询数据、公开信息和专业人员反馈，判断是否需要增加地区样本。

同时，法律问题涉及具体管辖地时，应避免将不同地区的规则混为一谈。区域 Query 的设计需要与法律知识正确性审核区分开来。

4.3 候选诊断池：200～500 条

候选池的作用不是直接扩大正式测量规模，而是为正式基准集提供备选样本。

来源可以包括：

来源	用途	需要注意的问题
真实咨询问题	贴近用户实际需求	必须获得合法授权，并处理隐私信息
公开法律问答	发现真实表达方式	注意来源许可、重复内容与时效性
专业人员访谈	补充高价值场景	需要记录采集方法和适用范围
经授权的查询数据	了解真实搜索表达	需明确时间范围和数据口径
LLM 生成候选	补充场景与表达变体	不能将合成数据直接当作真实频次证据

候选池生成之后，还需要经过分类、去重、质量审核和筛选，才能进入正式基准集。

五、Query-Agent：从一次 LLM 调用变成可控工作流

明确 Query 集的目标之后，再设计 Agent。

AIVA 当前的产品流程保持不变：

用户输入品牌信息 ↓ Brand-Agent 提取 11 字段 Profile ↓ 用户确认 Brand Profile ↓ Query-Agent 生成候选 Query ↓ 用户审查、修改、确认 Query 集 ↓ 选择目标 LLM ↓ 启动检测 ↓ 生成可追溯的检测报告

其中，Brand-Agent 和 Query-Agent 应当职责分离。

Brand-Agent 负责提取品牌事实；Query-Agent 负责把已经确认的品牌信息转换成适合测量的查询问题。

对于没有专用行业配置的品牌，Query-Agent 使用default配置继续运行，而不是因为没有行业插件就无法生成 Query。

5.1 推荐架构

Brand Profile │ ▼ Domain Resolver │ ▼ Query Planner │ ▼ Query Generator │ ▼ Schema Validation │ ▼ Semantic Deduplication │ ▼ Query QA │ ▼ Quota & Budget Check │ ▼ Query Preview │ ▼ 用户确认与冻结 │ ▼ Detection Run

这里不需要急于拆分多个独立 Agent。

一个 Query-Agent 编排器，加上职责明确的模块，就可以支撑第一阶段的工程实现。

5.2 Domain Resolver：通用配置与行业配置

Domain Resolver 根据已经确认的 Brand Profile 选择适用配置。

建议采用如下配置关系：

Query-Agent Core │ ├── default ├── legal ├── medical_aesthetics ├── education └── saas

其中default是通用兜底配置，其他配置可以继承通用规则，再增加行业专用主题、意图和质量约束。

例如，法律垂类可以配置劳动争议、婚姻家事、合同纠纷等主题；医美垂类可以配置服务项目、区域发现、机构选择等主题。

如果行业判断不确定，系统可以使用default，并在预览页提示用户确认分类，不必强制增加独立的行业选择步骤。

5.3 Query Planner：先确定覆盖计划

Planner 的职责是决定生成什么，而不是直接生成所有问题。

输入包括：

已确认的 Brand Profile。
Domain Config。
Query 集数量与调用预算。
已有 Query 集版本（如果存在）。
本次测量目标。

输出包括：

需要覆盖的意图。
需要覆盖的业务主题。
需要覆盖的地区。
各类 Query 的建议数量。
因信息不足而暂不生成的维度。

例如，某律所明确提供劳动争议、合同纠纷和企业法律顾问三类服务，且服务地区为沈阳。

Planner 可以优先覆盖这三类业务，并安排行业发现、服务发现、比较决策、品牌认知等测量意图。

但如果 Brand Profile 没有明确提供某项服务，就不应该仅因为法律行业常见该服务而自动加入品牌专属 Query。

5.4 Query Generator：分批生成候选问题

不建议让 LLM 一次性生成大量没有约束的 Query。

可以按照“意图 × 主题 × 地区”分批生成。

例如：

任务 A：法律服务行业发现 任务 B：劳动争议服务发现 任务 C：合同纠纷服务发现 任务 D：企业法律顾问比较 任务 E：品牌认知与信息核验

每批生成少量候选，使用固定 Schema 输出。

示例：

{"query_text":"沈阳有哪些提供劳动争议法律服务的律师事务所？","intent":"service_discovery","topic":"labor_dispute","region":"沈阳","source_type":"llm_generated"}

这只是参考数据结构，具体字段和枚举需要在 AIVA 中统一定义。

建议保留source_type，区分人工录入、真实问题改编、基准集引用和 LLM 生成等来源，便于后续评估样本质量。

5.5 Query QA：不让模型自说自话

候选 Query 生成之后，需要经过程序校验和质量审核。

至少检查：

JSON Schema 是否合法。
问题是否为空或存在明显语病。
是否与品牌业务、地区或测量目标相关。
是否包含未经确认的品牌事实。
意图标签是否合理。
是否与已有 Query 高度重复。
是否遗漏关键测量维度。
是否超出调用预算。

这里建议区分两个质量维度：

Query 质量是问题本身是否适合用于测量。

回答质量是目标模型的回答是否准确、是否提及品牌、是否给出可靠来源。

前者属于 Query-Agent；后者属于 AIVA 的检测与评估模块。

六、去重与覆盖：避免“生成很多，测量很少”

Query 集质量不取决于数量本身。

例如，以下三个问题可能高度相似：

沈阳有哪些值得了解的律师事务所？
沈阳有哪些值得推荐的律所？
在沈阳选择律师事务所时，有哪些机构可以考虑？

如果它们被全部纳入正式 Query 集，可能会使某类场景在最终统计中获得过高权重。

建议采用三层处理。

第一层：精确去重

清理首尾空白、规范常见标点、处理明显的格式差异，再比较文本。

第二层：语义去重

利用 Embedding 相似度或其他语义比较方式，发现措辞不同但含义相近的问题。

相似度阈值需要根据人工标注样本校准。不能直接认定某个固定阈值适用于所有行业。

第三层：测量目标检查

即使两个问题语义相近，也不一定应该删除。

例如：

沈阳有哪些提供法律服务的律师事务所？
沈阳有哪些提供劳动争议法律服务的律师事务所？

第二个问题增加了具体业务约束，可能具有独立测量价值。

因此，去重不能只看相似度，还要结合意图、主题和地区标签判断。

覆盖率怎么计算？

可以先定义一个简单的意图覆盖率：

[
Coverage =
\frac{\text{已覆盖的目标意图数}}
{\text{计划覆盖的目标意图总数}}
]

但它只是基础指标。

如果某个意图虽然有 Query，却全部未通过质量审核，不能认为它已经有效覆盖。

因此，AIVA 应统计通过质量检查的有效覆盖，并同时查看各意图的有效 Query 数量。

七、预算和测量成本：生成阶段就要控制

假设：

Query 数量为 (Q)。
目标模型数量为 (M)。
每条 Query 在每个模型上的运行次数为 (R)。

那么，在最简单的执行设计下：

[
N = Q \times M \times R
]

例如，50 条 Query、4 个目标模型、每个组合运行 5 次：

[
50 \times 4 \times 5 = 1000
]

即基础测量量为 1000 次模型运行，不包括重试、额外诊断等调用。

这也是为什么 Query-Agent 不能只负责生成问题，还需要与预算管理联动。

建议：

限制单个 Query 集的最大数量。
为候选生成和质量修复分别设置调用上限。
检测前计算预计执行规模。
超出预算时明确提示，而不是静默截断。
用户确认正式 Query 集后，再执行最终预算校验。

候选 Query 数量与正式测量 Query 数量应当分别管理。候选池可以更大，但进入正式测量的集合必须经过筛选和确认。

八、版本管理：让 GEO 检测结果可复现

如果每次检测都重新生成 Query，就很难解释两次分数变化的原因。

例如，第一次检测使用 50 条问题，第二次使用另一批问题。此时可见度分数发生变化，可能是模型回答变了，也可能是 Query 集变了。

因此，正式检测必须绑定冻结的 Query Set 版本。

建议至少记录：

{"brand_profile_version":"bp_v1","domain_code":"legal","domain_config_version":"1.0","query_set_version":"qs_v1","prompt_version":"query_generator_v1","measurement_protocol_version":"mp_v1"}

此外，还应记录实际目标模型及其版本标识、搜索能力配置、运行参数、检测时间和必要的调用信息。

推荐状态流转：

generating ↓ reviewing ↓ confirmed ↓ frozen

用户后续修改 Query 时，创建新版本，不覆盖已用于正式检测的版本。

这样才能支持历史复测、差异分析和审计。

九、法律垂类 Query 示例：从品牌输入到正式测量

假设某家律所已经确认以下 Brand Profile：

{"brand_name":"明衡律师事务所","brand_aliases":[],"industry":"法律服务","category":"律师事务所","core_services":["劳动争议","合同纠纷","企业法律顾问"],"service_regions":["沈阳"],"target_customers":["中小企业","劳动者"],"positioning":null,"key_advantages":[],"desired_ai_positioning":"希望沈阳企业寻找法律顾问时获得 AI 推荐","website":null}

以上是假设示例，不代表真实律所资料。

9.1 生成候选 Query

Query	意图	类型
沈阳有哪些提供劳动争议法律服务的律师事务所？	`service_discovery`	非品牌问题
沈阳有哪些可以为中小企业提供常年法律顾问服务的律所？	`service_discovery`	非品牌问题
企业选择常年法律顾问时应该比较哪些服务内容？	`decision_support`	行业通用问题
明衡律师事务所主要提供哪些法律服务？	`brand_awareness`	品牌问题
选择沈阳的合同纠纷律师事务所时，应该关注哪些因素？	`decision_support`	非品牌问题
如何核实一家律师事务所的执业信息？	`trust_verification`	行业通用问题

这些问题分别测量不同的场景。

品牌问题用于观察 AI 如何描述目标品牌；非品牌问题用于观察品牌能否自然进入相关回答；行业通用问题则可以帮助分析模型的推荐和信息来源行为。

9.2 检查不应生成的 Query

以下问题不应该仅凭上述 Profile 生成：

明衡律师事务所的胜诉率是多少？
明衡律师事务所最擅长哪些高难度案件？
明衡律师事务所是否拥有全国知名律师？
明衡律师事务所的官网是什么？

原因很简单：这些信息没有在 Brand Profile 中得到确认。

对于最后一个问题，虽然可以在后续检测阶段通过合适的联网能力核验公开信息，但不能在品牌资料提取阶段自行编造官网，也不能把未核实的信息直接写入正式品牌档案。

9.3 用户确认与版本冻结

候选 Query 经过去重和质量审核后，展示给用户。

用户可以：

修改问题表达。
删除不相关的问题。
补充遗漏的业务场景。
确认最终用于检测的 Query 集。

确认后生成正式版本，例如qs_v1。

如果之后律所增加了新的业务或服务地区，应更新 Brand Profile，并重新生成或调整 Query 集，形成新的版本，而不是修改旧版本后重新解释历史报告。

十、检测指标：提及、推荐与引用不能混为一谈

Query 集设计完成后，AIVA 才进入实际检测阶段。

对于法律垂类，至少需要区分以下现象：

品牌提及：回答中是否出现目标律所。
品牌推荐：模型是否明确建议用户考虑该律所。
候选集合出现：律所是否进入模型列举的可选机构集合。
品牌描述准确性：模型是否正确描述其业务、地区和其他已确认信息。
引用来源：回答是否提供可追溯来源，以及来源是否支持相关陈述。

这些指标不能简单合并为一个“提及率”。

例如，某个模型可能在被直接询问“明衡律师事务所提供哪些服务”时正确提及品牌，但在一般性的沈阳法律服务推荐问题中从未提及该品牌。

这两种结果说明的是不同的可见度现象。

同样，模型提及某家律所，不代表它已经核实该律所的资质；模型给出引用，也不代表引用一定支持回答中的每一项主张。

对于法律等专业领域，报告还应明确记录检测模型、搜索能力、运行参数和引用信息，避免将未经核验的回答当作客观事实。

十一、Query-Agent 的评测与迭代

Query-Agent 不能仅凭“生成成功”判断质量。

建议从以下维度建立离线评测。

指标	评估方式
Schema 合法率	程序校验
有效 Query 率	规则审核与人工抽样
语义重复率	相似度筛选加人工复核
意图覆盖率	对照 Planner 计划
事实边界违规率	检查是否引入未确认的品牌事实
用户修改率	对比候选版本与确认版本
生成失败率	统计异常、超时和校验失败
版本稳定性	固定输入与配置，比较重复运行的差异

建议构建一套黄金测试集，覆盖信息完整的品牌、缺少行业的品牌、业务较多的品牌、无专用行业配置的品牌，以及描述存在歧义的品牌。

然后对比几种方案：

一次性 LLM 生成。
分批生成加 Schema 校验。
增加精确与语义去重。
增加 Planner 与覆盖检查。
增加行业配置和专业审核。

通过同一套评估规则比较这些方案，才能知道复杂度的增加是否真正带来了收益。

对法律垂类而言，还可以借鉴法律问答和 Agent Benchmark 的实践，建立专家审核流程。但需要牢记：法律问答正确率不能直接替代 GEO 可见度指标，两个任务的评价目标不同。

十二、实施路线：先把测量链路做扎实

结合 AIVA 当前的设计，我建议按以下顺序推进。

第一阶段：可靠生成

固定 Query Schema。
实现分批生成与基础质量校验。
明确default与行业配置的关系。
加入数量限制和调用预算。
保留用户确认流程。

第二阶段：Query 质量治理

实现精确去重与语义去重。
建立意图、主题和地区覆盖检查。
输出候选质量报告。
建立人工抽样和黄金测试集。

第三阶段：版本与复测

固定 Brand Profile 和 Query Set 版本。
冻结正式测量输入。
记录 Prompt、行业配置与测量协议版本。
保证历史报告能追溯到实际使用的 Query。

第四阶段：法律基准集建设

建设全国核心法律 Query 集。
建设区域 Query 集。
建立 200～500 条候选诊断池作为初期规划。
区分真实样本、公开问答、专业访谈与模型生成候选。
通过专家审核和真实运行结果持续迭代。

第五阶段：扩展其他行业

在通用 Query-Agent 稳定后，再逐步扩展医疗美容、教育、SaaS 等行业配置。

行业扩展应主要通过新增配置、基准集和质量规则实现，而不是为每个行业重写一套 Agent。

十三、总结

AIVA 的 Query 集生成，不应该被理解为“让大模型一次生成几十个问题”。

它实际上涉及测量设计、数据治理、自动化生成、质量控制、预算管理和版本管理等多个环节。

从国内外研究和法律领域评测实践中，可以得到三个重要启示：

第一，Query 集需要覆盖不同的用户意图和表达方式。不能只依赖少数固定问题，也不能将所有行业压缩成同一种问题结构。

第二，行业基准与品牌专属 Query 集必须分开。前者提供相对稳定的行业测量参照，后者围绕具体品牌的业务、地区和目标进行诊断。

第三，Agent 的工程价值在于可控、可复现和可审计。Planner、Generator、QA、去重、预算管理与版本控制应当形成完整工作流，而不是全部依赖一个 Prompt。

对于 AIVA，真正值得长期积累的资产，不只是一个能生成 Query 的 Agent，而是一套有明确来源、清晰分类、质量标准和版本记录的 Query 测量体系。

当 Query 集能够稳定复用，品牌档案能够准确追溯，检测结果能够解释其适用范围时，AIVA 才有基础从简单的 AI 回答检测工具，逐步发展为可持续演进的 GEO 可见度测量平台。