自然语言理解、条件抽取、在明确 schema 上组合推理、承接 follow-up。
数据结构
实体定义、稳定 id、字段字典、可追溯来源。
自然语言理解、条件抽取、在明确 schema 上组合推理、承接 follow-up。
猜黑盒接口能力、记忆零散隐式规则、在单 query 字符串上稳定检索。
不要让模型猜能力,应显式给出实体、字段、过滤、排序、limit、detail by id。
当查询语义被显式建模,系统可稳定回答“这些结果的 id”“第 2 条展开”“只给我链接”等追问;否则只能依赖 prompt 补丁,成本和风险持续上升。
业务方关心:用户提问千变万化,但目标很朴素,就是想快速拿到准确结果,并且能继续追问“给我链接”“展开第2条”“把这些结果的 id 给我”。如果每次追问都答不稳,用户会直接判断系统不可靠。
工程上落地:不要把能力藏在接口内部规则里,要把实体、字段、筛选条件、排序、limit、详情查询入口写成明确契约。模型并不需要“聪明猜测”,它需要的是可被执行的结构化边界。
上线后:一旦查询语义明确定义,后续新增问题类型时只需要扩展字段和样例,不必持续在 prompt 上打补丁,维护成本和回归风险都会明显下降。
detail by id,follow-up 会在“这条/第2条/这些结果的 id”场景失稳。query 字符串,无法稳定表达范围过滤、排序、聚合,属于兼容层而非主查询底座。推荐查询样例: - 给我湖南 2020 年后的资料 - 把刚才结果的 id 列出来 - 只要链接 - 第 2 条展开详情
detail by id。| 优先级 | 实现形态 | 适配度 | 说明 |
|---|---|---|---|
| 1 | 只读视图/宽表 + text2sql | 高 | 查询表达力最强,follow-up 稳定性最佳 |
| 2 | 结构化 Query API | 中高 | 安全边界更强,但灵活性低于 SQL |
| 3 | 固定参数 REST | 中 | 可做过渡,需补齐字段语义与契约 |
| 4 | 单字符串检索 | 低 | 仅可兼容接入,不应作为主查询底座 |
业务方关心:同一个对话里既会出现“查资料”,也会出现“下载、导出、提交”这类动作。如果底层把两类能力混在一起,渠道体验会出现时好时坏,用户会感觉系统“忽然像搜索,忽然像按钮”。
工程上落地:把 Read Model、Query Surface、Operation Surface 明确拆层。查询层只负责事实检索与结构化返回,动作层只负责执行行为与状态回执,两边通过清晰契约衔接而不是靠隐式约定。
上线后:架构分层稳定后,新增一个业务域通常只需要接入新的读模型与能力配置,不必改动核心 runtime 逻辑,扩展速度和故障定位效率都会提升。
推荐统一字段:id/title/type/category/region/year/status/summary/content/source/created_at/updated_at;URL 类字段统一为 url/pdf_url/h5_url/download_url/preview_url。
{
"name": "search_kaoqing_documents",
"kind": "query",
"input_schema": {
"region": {"type": "string"},
"year_gte": {"type": "integer"},
"limit": {"type": "integer", "default": 20}
},
"result_schema": {
"entity": "document",
"list_fields": ["id", "title", "year", "region", "pdf_url", "h5_url"]
}
}
反模式:只有字符串 query、零散接口爆炸、页面导向返回、没有 detail by id。
业务方关心:业务希望尽快上线,但更担心上线后频繁返工。真正影响体验的不是“接口今天通没通”,而是核心场景、异常场景、追问场景能不能稳定复现并被团队共同验收。
工程上落地:十阶段流程不是形式化流程,而是把风险前置。需求澄清阶段解决语义歧义,底层评审阶段解决能力边界,联调阶段解决真实链路问题,灰度阶段解决真实用户分布问题。
上线后:每个阶段都留下可追溯产物(样例、日志、结论),后续发生故障时能快速判断是上游数据、适配映射、working set 还是渠道展示问题,避免盲改 prompt。
| 阶段 | 关键产出 | 退出标准 |
|---|---|---|
| 需求澄清 | 10+ 典型问题、主实体、默认返回策略 | 能明确“用户查什么、详情落哪” |
| 底层评审 | 能力类型判定、方案优先级结论 | 无稳定 id / 无 detail by id 则退回 |
| 本地联调 | 基础查询+follow-up+异常样例 | 不泄露中间态、话术与数据一致 |
| 灰度上线 | 成功/失败样本库与监控面板 | 跟踪成功率、空结果率、超时率 |
核心要求:每一阶段都应有可验证的“退出标准”,而不是凭主观感受推进。
实体定义、稳定 id、字段字典、可追溯来源。
过滤、排序、limit、聚合、detail by id、投影查询。
capability 注册、schema 契约、working set 与 follow-up 连续性。
若以上任一无法稳定承接,应判为“有条件接入”或“不建议接入”。
业务方关心:用户不会看系统内部架构,只会问“结果对不对、追问顺不顺、失败时是不是体面”。因此上线门槛必须围绕真实问法来定义,而不是围绕内部模块是否开发完成。
工程上落地:把检查清单做成硬约束:稳定主键、detail by id、字段字典、结构化错误、限流超时、日志链路都要可验证。尤其是“第2条”“只给链接”这类追问,是最能暴露系统短板的试金石。
上线后:验收标准可复用后,新业务域接入不会每次都从头争论“什么叫完成”,团队协作成本下降,质量基线也会更稳定。
验收口令: 1) 这些结果的 id 给我 2) 第 2 条展开 3) 把链接发我 4) 刚才那批里湖南的有哪些
兼容式 REST 接入可以快速上线,但当查询进入“范围过滤 + 追问 + 统计”阶段,单字符串检索会迅速暴露语义瓶颈。
| 维度 | 兼容接入现状 | 目标能力 |
|---|---|---|
| 查询表达 | 模糊 query 字符串 | 结构化过滤与排序 |
| 详情承接 | 弱,依赖临时上下文 | 稳定 detail by id |
| 统计分析 | 基本不可用 | 支持 group by / count / topN |
| 可扩展性 | 靠新增接口补洞 | 沿同一 schema 平滑演进 |
kaoqing_document_read_model,补字段字典与索引。业务方关心:历史系统通常已经在线,不能为了“理想架构”一次性推翻。业务可接受的路径是先保住可用,再逐步增强查询质量,让用户感知持续变好而不是频繁波动。
工程上落地:先兼容存量 REST 保证接入速度,再补读模型和结构化查询能力,最后把主查询路径迁移到 text2sql 或 Query API。迁移过程要始终保持双轨可回退,避免单点切换带来服务风险。
上线后:能力从“模糊检索”进化到“结构化查询”后,统计分析、范围过滤、投影输出会自然解锁,后续新需求不再被单一 query 字符串卡住。
兼容态请求:
POST /sac/kq/pdf
{
"query": "福建"
}
目标态(结构化):
{
"entity": "kaoqing_document",
"filters": {"region": "浙江", "year >= 2021": true, "confirmed": true},
"sort": ["year:desc", "updated_at:desc"],
"limit": 20,
"fields": ["id", "title", "year", "region", "pdf_url"]
}
目标 SQL: SELECT id, title, year, region, pdf_url FROM kaoqing_document_read_model WHERE region = '浙江' AND year >= 2021 ORDER BY year DESC, updated_at DESC LIMIT 20;
业务方关心:同类需求会反复出现,大家最怕“同一个坑反复踩”。如果每次接入都只留下代码不留下方法论,下一次还是要重新摸索,交付周期和风险都会反弹。
工程上落地:把业务说明、字段字典、接口契约、联调用例、灰度结论打包成标准交付物。这样后续团队拿到模板就能快速复用,不会因为人员变化导致认知断层。
上线后:模板化资产会形成组织记忆,接入效率会随着项目推进持续提高,文档不再是“补材料”,而是直接影响研发速度和稳定性的生产资料。
| 结论等级 | 判定条件 |
|---|---|
| 可接入 | 语义、性能、安全、可观测均达标 |
| 有条件接入 | 需补稳定 id / detail by id / 字段字典 / 日志链路 |
| 不建议接入 | 仅模糊 query,无法承接 follow-up,结构不可验收 |