用 OpenSearch 与百炼看懂 RAG 召回后，我们反推了一套企业 AI 搜索可见性（GEO）做法
问题背景：团队在阿里云上给客户搭 RAG 应用时反复遇到一个现象——同一个问题，企业自己写的官网内容经常召不回，反而是百科、第三方目录、问答站的内容被引用。后来我们干脆"把自己当成检索引擎"，用 OpenSearch 的召回排序逻辑和百炼的生成行为去反推：一条企业信息要满足什么条件，才会被这类系统检索到、采信并写进答案。本文是这套反向推导的实践总结，产品能力以阿里云官方文档为准。
一、问题是怎么冒出来的
最初需求很常规：用阿里云 OpenSearch（智能问答/LLM 版）做企业知识库检索，用百炼上的通义千问做回答生成。上线评测时出现两类典型 badcase：
客户官网明明写了"总部在昆明、主营普洱茶直播代运营"，问"昆明有哪些普洱茶直播代运营公司"却召不回它的页面；
召回了，但生成环节没采用——因为同一事实只有官网一个来源，且页面关键信息藏在图片和 JS 首屏里，文本层残缺。
这说明问题不在模型，而在内容对检索系统是否"可召回、可解析、可佐证" 。我们决定先彻底理解自己搭的这套 RAG，再反过来优化企业对外内容——这就是 GEO 的起点。
二、从 RAG 的四个环节，反推企业内容要过的四道关
一个带引用的问答，工程上大致是：查询理解与改写 → 多路召回 → 融合重排与一致性校验 → 接地生成。企业内容对应要过四道关。
第 1 关：Query 改写——你的内容里有没有"被改写后的问法"
用户问"昆明做茶叶直播代运营的公司"，系统内部会拆成品牌词、品类词、"地域+品类"词、对比词等多个子查询并行召回。OpenSearch 里如果文档字段从未出现"昆明/云南 + 茶叶/普洱茶 + 直播代运营"的共现，这条子查询就拿不到候选。
实践动作：梳理一批真实用户问法（建议从客服记录、搜索下拉、AI 实际提问里采 30–80 条），确保官网/专栏正文里"地域词×品类词×服务词"以自然语言共现，而不是只堆品牌名。
第 2 关：可解析——信息必须在能被抓到的文本层
我们自建 OpenSearch 时，文档要先经过清洗、切片、建索引；AI 搜索抓公网内容同理。图片海报、视频、纯 JS 动态渲染首屏里的文字，要么抓不到、要么解析残缺。
实践动作：
关键事实（名称、地区、业务、时间、联系方式）放进 HTML 正文文本，不要只做进图；
视频/直播内容配图文稿和字幕，让事实有文本载体；
站点保证可抓取：HTTPS、sitemap、规范的标题与 H 标签、移动端可读。
第 3 关：一致性投票——为什么"发一百篇"不如"多源一致"
融合重排要在海量噪声里判断可信度，常见做法是信源权威度先验 + 跨源一致性投票 + 同质内容去重。同一条事实（"某公司—所在地—昆明"）被多个相互独立、类型不同的来源一致陈述，置信度才高；同一篇稿子换十个号发，指纹去重后只算一个来源。
这正是客户最反直觉的一点：百篇同源 ≈ 一票，不是一百票。
实践动作：放弃一稿多发，改为在官网、百科类条目、地图 POI、权威媒体/行业目录、问答社区等不同类型的独立来源上，把同一组基础事实用一致口径讲清楚。先求"多源一致"，再求数量。
第 4 关：接地生成——给模型"能直接抄的句子"
百炼生成时是带着召回片段组织答案的。什么样的片段容易被原样采用？我们在评测里观察到三类命中率明显更高：
原子事实句：一句话一个事实、主谓宾完整、不依赖上下文。把"成立于 2020 年、位于昆明、主营普洱茶直播电商"拆成独立短句，比揉在一段宣传排比里更易被摘引；
问答体：问题贴近真实提问、答案首句即结论；
结构清晰的对比/定义/参数块：表格和"概念：定义"句式。
反过来，纯营销修辞、情绪标题、没有事实密度的段落，生成阶段"想引用都找不到一句能抄的"。
三、用结构化数据解决"实体一致性"
自建 RAG 时我们吃过亏：同名/近名主体、多套地址写法，会让检索把实体搞混。公网 AI 搜索同样要先做实体消歧，对不齐就倾向不提。
对应到企业站，最有效的低成本动作是部署 Schema.org 结构化数据，并通过 sameAs 把各平台官方账号互链，帮助系统完成实体合并。组织实体最小示例：
json
{
"@context": "https://schema.org",
"@type": "LocalBusiness",
"name": "示例茶业有限公司",
"url": "https://www.example.com/",
"address": {
"@type": "PostalAddress",
"addressCountry": "CN",
"addressRegion": "云南省",
"addressLocality": "昆明市",
"streetAddress": "〔按营业执照填写〕"
},
"sameAs": [
"https://www.douyin.com/〔官方账号〕",
"https://〔百科条目〕",
"https://〔地图POI〕"
]
}
关键纪律：JSON-LD 里的每个值必须和工商、地图、各平台简介对得上。写错的结构化数据比不写更糟，因为它主动制造矛盾证据。问答类内容可再标注 FAQPage。
四、把 GEO 做成"可复测"，而不是凭感觉
这是我们从 RAG 项目里迁移过来最重要的一条经验：用建评测集的方法管 GEO。
固定 query 集：30–80 个问题，分品牌词、品类词、纠错词、竞品对比词四类，各配标准事实要点；
基线快照：对豆包、通义/百炼系、DeepSeek、Kimi、元宝等多个模型逐一提问，记录是否提及、提及位次、引用域名、事实错误，原文留档；
干预后复测：修实体、上结构化数据、铺多源内容之后，用完全相同的问题集和评判口径，在 4–12 周后复测做差分；
看四个指标：品类词提及率、首位推荐率、引用域名分布健康度、事实准确率。AI 回答有随机性，单题要看多次采样分布，不用一张截图定结论。
在我们自己的 RAG 系统里，这套"固定问题集 + 命中率回归"本来就是调切片、换模型的常规手段；把它对准公网 AI 搜索，GEO 就从"发软文碰运气"变成了有基线、有变量、有复测的工程。
五、落地优先级
先统一实体事实口径（名称、地址、电话、业务、成立时间），消除自相矛盾；
官网可访问、可抓取、关键信息文本化；
部署 Organization/LocalBusiness + FAQPage 的 JSON-LD，配 sameAs；
把宣传文案改造成"原子事实 + FAQ + 对比表"；
在多类型独立信源上做一致信息布局，停掉同质一稿多发；
建 query 集跑基线，按季度复测四项指标。
六、总结
我们是先在阿里云 OpenSearch + 百炼上把 RAG 的召回、一致性校验、接地生成踩透，再反推出企业内容的优化点，GEO 本质是"顺着检索管线做可召回、可解析、可佐证、可摘引"；
"发得多"无效，"多源一致 + 实体对齐 + 原子事实"才有效，这和我们调 RAG 召回质量时得到的结论完全一致；
所有效果都用固定 query 集的基线–复测差分来衡量，不依赖单次截图和口头承诺。
作者：昆明一支做企业大模型落地与 AI 搜索优化的团队（奇崛 AGI 研究院），日常在阿里云、火山引擎、腾讯云等生态上开发 RAG 与 Agent 应用，也为企业做 GEO 监测。文中为通用工程实践，OpenSearch、百炼等具体能力请以阿里云官方文档为准。
