研究文章
AI 为什么会推荐一家企业?从“被认识”到“进入候选名单”的证据条件
研究时间:2026 年 9 月 15 日
一家企业做 GEO 时,很容易遇到一种看起来矛盾的情况:AI 已经能够正确回答企业名称,主营业务也没有认错,官网、媒体或行业平台甚至已经开始出现 Citation,但当用户真正问“有哪些公司值得推荐”“这类服务找谁比较靠谱”“有哪些厂家可以选择”时,目标企业仍然没有进入答案。
这并不矛盾。被 AI 正确认识,首先解决的是“你是谁”的问题;而推荐面对的是另一层判断:在当前这个具体需求下,为什么应该把这家企业放进有限的候选范围。如果没有把“认知”和“推荐”分开,企业很容易继续投入资源解释自己是谁,而真正缺少的可能已经从企业身份信息变成了“为什么值得被选择”。
这也是本文真正要解决的问题:一家企业从“被认识”走向“被推荐”,中间到底还缺什么。
一、先说明边界:目前不存在公开的“企业推荐公式”
截至 2026 年 9 月 15 日,宜海科技未找到豆包、DeepSeek、元宝、千问任何一家官方公开过类似“官网权重多少、媒体权重多少、案例权重多少,再按照固定比例计算企业推荐概率”的完整公式。市场上如果有人给出非常具体的固定推荐权重,仍然需要继续追问这些数字来自官方资料、可重复实验,还是对少量结果的推断。
本文使用“候选范围”“候选名单”“推荐条件”等表达,是为了帮助企业理解和诊断外部可观察结果,并不意味着任何 AI 平台官方确认自己的内部系统存在一个固定叫作“候选名单”的模块。
从企业能够真实检测的结果出发,更实用的做法,是把从认知到推荐拆成一条诊断链:
| 阶段 | 需要回答的问题 |
|---|---|
| 企业识别 | AI 有没有正确识别这家公司? |
| 场景相关 | 这家公司和当前用户问题是否真正相关? |
| 能力证据 | 有没有公开材料证明企业具备相应能力? |
| 可验证证据 | 这些材料能否支持当前结论,来源是否适合、有效且一致? |
| 相对选择 | 和其他候选企业相比,有没有足够理由进入答案? |
| 真实推荐 | 当前 AI 是否真的把目标企业推荐出来? |
| 可比复测 | 优化以后,在可比问题下结果是否发生变化? |
这不是平台算法模型,而是一套问题定位框架。它的价值在于,当企业没有进入推荐时,先确认问题发生在哪一层,再决定应该处理什么,而不是所有企业都从“多发文章、多铺媒体”开始。
二、企业必须先被正确识别
企业识别是进入推荐竞争之前最基础的一层。如果 AI 连企业是谁都没有判断稳定,后面的推荐分析就没有可靠基础。
现实中常见的问题包括品牌对应错企业主体、主营业务认错、把历史业务当成当前业务、把另一家同名企业的项目归到目标企业,或者母公司、子公司和品牌之间的关系被混在一起。这时候真正应该解决的问题并不是“为什么 AI 不推荐我”,而是先确认 AI 当前理解的这家公司到底是不是目标企业本身。
身份认知正确当然不能保证推荐,但如果这一层本身就是错的,继续增加案例、媒体和推荐内容,反而可能在错误实体上继续累积信息。关于这类问题,可参阅《AI 为什么会认错一家公司?从品牌、主体和主营业务混淆说起》。
三、企业还必须和当前用户问题真正相关
“属于这个行业”和“适合回答这个问题”,不是一回事。
假设一家企业从事装修。用户问“合肥有哪些装修公司”,和问“做高端酒店改造的装修公司有哪些”,虽然都属于装修行业,但企业需要证明的相关性并不相同。前一个问题主要需要确认企业确实提供装修服务;后一个问题则进一步要求公开信息能够说明,这家企业与酒店装修、酒店改造这一具体业务场景确实存在真实联系。
这就是为什么一家企业反复告诉外界“我们是一家专业装修公司”,并不能自然覆盖所有装修相关的推荐问题。推荐针对的是具体需求,企业需要让公开信息能够回答:当前这个用户问题为什么和我有关。
已经公开的搜索机制也说明,AI 搜索并不只是机械匹配企业名称。OpenAI 对 ChatGPT Search 的官方说明提到,搜索过程可能把用户问题改写成一个或多个更有针对性的查询,并根据初始结果继续发起更具体的搜索;Google 在生成式 AI 搜索指南中也公开了 query fan-out,即围绕原始问题生成多个相关查询,再获取更多相关结果。
这些资料分别只能说明 OpenAI 和 Google 自己的搜索机制,不能直接外推成豆包、DeepSeek、元宝或千问的内部算法。但它们至少说明,AI 搜索处理的是用户意图和具体问题,而不只是企业名称。只围绕一个固定关键词重复建设内容,并不能证明企业已经覆盖了真实用户会提出的各种业务场景。
关于豆包、DeepSeek、元宝和千问当前可以公开核验的搜索与召回机制,可参阅《豆包、DeepSeek、元宝、千问如何发现和引用企业?公开机制、实测与边界》。
四、重要能力必须有证据,而不只是企业自己描述
假设两家公司都在官网写“我们非常专业”,从推荐角度看,这句话几乎没有区分能力。真正值得继续追问的是:专业体现在哪里,做过什么项目,解决过什么问题,有什么结果,有什么资质,以及哪些公开资料能够证明这些事实。
这就是“企业介绍”和“推荐证据”的区别。企业自己声明“我们提供 GEO 服务”,可以帮助外界确认这家公司确实经营这项业务;但如果用户问“哪家 GEO 服务商值得推荐”,问题已经从“有没有这项业务”推进到了“为什么要把这家公司放进有限的选择范围”。
网页数量和证据质量也不是一个概念。腾讯云当前公开的联网搜索 API 就提供了一个值得参考的例子:相关接口区分公开网页信源和优质权威垂直信源,返回结果相关性得分,部分版本还提供结果权威度等级。
这些字段不能证明元宝最终推荐企业时会直接按照某一个分数排列公司,更不能证明某家媒体具有固定推荐权重。但它至少能够说明,在真实联网搜索基础设施中,网页数量不是唯一可以被区分的属性,来源类型、相关性和权威性本身也可能被分别处理。
因此,“网上有很多页面说这家公司专业”和“存在能够支持这家公司专业能力的公开证据”不是一回事。
五、真实资料还必须能够证明当前结论
企业拥有很多真实资料,并不意味着这些资料都是当前问题的有效证据。
营业执照能够证明企业主体存在,却不能单独证明“这家公司是一家优秀的酒店装修服务商”;企业官网能够证明企业公开提供某项服务,但不一定能够独立证明服务效果;媒体转载能够证明某段内容曾经公开出现,也不能自然理解成发布平台独立核验过其中的商业结论。
真实案例同样需要和问题对应。一个案例可以证明企业确实做过某类项目,但如果这个项目和用户当前询问的场景关系很弱,它对这次推荐判断的帮助也可能有限。因此,来源是否“权威”不能脱离它到底在证明什么。
Google 针对生成式 AI 搜索发布的官方指南强调,要提供独特、有价值、可靠,并能够体现第一手经验或专业经验的内容。同时,Google 也明确说明,高数量页面本身不会让网站自动变得更高质量或更相关;如果规模化生产大量查询变体页面的主要目的,是操纵搜索排名或生成式 AI 回复,则可能违反其规模化内容滥用政策。
这些是 Google 自己的规则,不能直接当作豆包、DeepSeek、元宝或千问的规则。但它反映了一个基础的证据原则:更多信息并不自动等于更有用的证据,真正需要判断的是材料能不能支持当前用户关心的结论。
六、可验证证据还要解决来源角色、一致性和时效问题
不同来源适合承担不同的证明任务。企业官网适合证明企业身份、正式业务、产品、服务以及企业自己的事实;政府或正式机构适合证明资质、许可、登记等正式信息;项目资料可以证明企业做过什么、解决过什么问题;合作方、行业机构或客户公开资料,则可能提供额外的外部验证。
这并不意味着“第三方永远比官网更重要”。真正应该判断的是,这条结论最适合由什么来源证明。例如,“我们正式提供这项服务”,企业自己的正式页面就是非常直接的一手来源;但如果结论进一步变成“这家公司在这个领域值得推荐”,单靠企业自己不断重复同一个评价,证明力就会受到限制。
企业公开网络还有一个现实问题:它不是一个永远保持最新状态的静态数据库。新业务和旧业务、新名称和旧名称、旧地址和新地址、已经停止的产品、变化过的组织关系,都可能长期同时存在于公开网络中。
如果官网已经更新为 A,历史媒体仍然保留 B,第三方平台又存在 C,就不能假设 AI 一定能够自动判断哪一条才是现在有效的信息。因此,GEO 有时真正需要做的不是继续增加更多正确内容,而是找到正在造成错误认知的旧信息,判断它是否仍然被检索和使用,再处理企业主体、业务和时间上的冲突。
关于这类信源问题,可参阅《公开信源越多越好吗?AI 搜索中的“信源数量”与“可验证性”》。
七、推荐是一种相对选择,不只是判断企业“合不合格”
这是“被认识”和“被推荐”之间最大的区别之一。
假设一家企业真实存在,业务没有认错,有案例、有公开资料,AI 也能够正确识别企业。这些条件全部成立,仍然不能推出 AI 一定会推荐它。因为当用户询问“推荐几家工业设备厂家”时,最终答案不是简单判断每一家企业是否合格,而是在多个可能选择之间,只写出其中一部分。
因此,一家公司没有进入推荐,并不一定意味着这家公司本身存在严重问题。还有一种很常见的情况是,当前进入答案的同行拥有更清楚、更相关、更容易被检索和验证的选择理由。
例如,同行的产品定位可能更清晰,与当前问题直接相关的项目更明确,能力证据更具体,公开信息更完整,外部验证更充分,或者企业与这个具体业务场景之间的关系更容易确认。
这也是为什么 GEO 检测不能只盯着目标企业自己。还需要观察当前问题下谁进入了答案,这些企业有哪些公开证据,这些证据具体支持什么,以及目标企业和当前候选之间到底缺少什么。
只有把推荐理解成一种相对选择,才能解释一个非常常见的现象:AI 明明认识一家企业,却仍然没有把它写进推荐答案。关于“被收录、被引用、被推荐”为什么需要分别判断,可参阅《被收录、被引用、被推荐:企业做 GEO 最容易混淆的三个结果》。
八、两个真实项目:同样没有进入推荐,原因可能完全不同
宜海科技在真实项目中遇到过两种比较典型的情况。以下项目均采用行业匿名方式呈现,不公开企业名称和完整项目数据。
第一个是建筑工程行业项目。项目初始检测发现,核心问题并不是简单的“企业内容不够”,而是品牌身份、企业主体和核心业务之间存在认知混淆。项目没有一开始就增加文章和媒体数量,而是先处理品牌、企业主体和核心业务三者之间的公开关系。
后续复测中,AI 对品牌、企业主体和核心业务的认知实现统一,并最终进入豆包相关建筑行业推荐结果。这个案例能够支持的是,企业实体认知混乱确实可能成为推荐之前需要优先解决的问题;但它不能证明,只要统一企业名称和主体关系,企业就一定能够进入推荐,因为身份正确只是第一步。
第二个是酒店装修行业项目。优化前,企业并不是完全不存在于公开网络中,真正的问题是 AI 对企业核心业务以及“酒店装修”这一具体业务场景的认知较弱。
如果只看“AI 有没有找到这家公司”,很容易认为基础认知已经足够;但当问题进入“酒店装修找哪些公司”时,企业仍然缺少和这个具体推荐场景之间的稳定联系。项目后续围绕实际问题进行了优化和复测,最终企业进入豆包相关酒店装修推荐结果。
这个案例能够说明,企业的主营业务认知和具体用户场景之间,还存在一层值得单独诊断的关系。它不能证明“只要写一篇酒店装修文章就会进入推荐”,真正值得关注的是优化前到底缺什么、采取了什么方向的优化,以及同类问题复测以后发生了什么变化。
九、更多证据也不等于更容易推荐
既然推荐需要证据,一个很自然的问题是:证据是不是越多越好?目前没有足够依据支持这种简单结论。
2026 年 Findings of ACL 的研究《RAG in the Wild: On the (In)effectiveness of LLMs with Mixture-of-Knowledge Retrieval Augmentation》研究了复杂、异质知识来源条件下的 RAG 表现。研究显示,没有任何单一检索来源能够在所有场景持续表现最好,同时模型在不同异质知识来源之间进行有效路由仍然存在困难。
另一项 ACL 2026 Industry Track 研究《NEST: Nested Evidence Survival for Retrieval》研究了高噪声环境中的检索问题。当真正相关的证据比较稀少、干扰信息很多时,有价值的证据可能在检索和裁剪过程中提前丢失。
这两项研究都不是企业 GEO 实验,也没有直接测试豆包、DeepSeek、元宝和千问推荐企业,因此不能把它们转换成“企业文章多了就会降低推荐率”这样的结论。它们真正能够支持的是一个更基础的判断:大量信息不会自动转化成有效证据。
如果一家企业拥有 100 篇内容,但大量内容只是重复企业简介、同一通稿转载、和用户问题无关的宣传、已经过期的信息,甚至彼此存在业务冲突,那么“内容很多”本身并不能证明系统最终能够找到最重要、最相关的那条证据。
企业真正需要建设的不是单纯的信息体量,而是关键证据是否清楚、相关、有效并且可以核验。
十、一次推荐也不能直接理解成“已经稳定”
即使企业已经进入推荐,也不能马上把一次结果理解成永久稳定状态。
2026 年 Findings of ACL 的研究《Robust In-Context Selection via Online Learned Position-Corrected Attention》研究了大型语言模型在候选列表中进行选择时的表现。研究发现,在这类任务中,模型原生选择行为可能受到候选项位置、顺序和标识表达形式的影响。
这项研究测试的是列表选择和工具选择任务,并不是豆包、DeepSeek、元宝或千问的企业推荐实验,所以不能据此声称“AI 企业推荐一定受到位置偏差控制”。但它能够说明一个更基础的问题:大型语言模型进行候选选择时,本身并不一定是一个完全稳定、只由候选质量单独决定的过程。
再考虑搜索时间、索引变化、模型版本、检索策略和生成差异,一次进入答案不应该直接被解释成永久推荐,一次没有进入答案也不能直接解释成永久失败。因此,真实 GEO 项目最终仍然需要在可比条件下进行复测。
关于为什么不能“换个问题再测”,可参阅《GEO 优化如何复测?为什么“换个问题再测”不能证明效果》。
十一、怎么判断一家企业到底缺的是哪一层
如果一家企业做 GEO,一开始拿到的就是固定套餐:官网多少页、文章多少篇、媒体多少家、自媒体多少个平台,那么不同企业最后执行的动作会非常相似。
问题在于,不同企业没有进入推荐的原因可能完全不同。宜海科技更关注的是先确认 AI 是否正确识别企业;企业识别正确以后,再看当前用户问题和企业是否真正相关;场景没有问题以后,再继续判断 AI 能不能找到支持关键能力的公开证据,以及这些证据是不是适合证明当前结论。
如果企业已经出现 Citation,却仍然没有进入推荐,就不能继续简单把目标设成“增加 Citation”。这时候还要进一步观察当前问题中哪些同行进入了答案,它们提供了哪些目标企业暂时缺少的推荐理由,再决定应该补案例、业务信息、正式事实源、外部验证,还是处理已有信息冲突。
完成针对性优化以后,再回到可比问题进行复测,最终判断目标企业有没有真正进入推荐结果。
这套方法的核心不是“掌握 AI 的隐藏算法”,而是在平台没有公开完整算法的情况下,利用真实搜索结果、Evidence、Citation、公开来源和当前竞争结果,把问题定位到正确层级。
十二、企业真正应该建设的是“推荐证据矩阵”
很多企业建设内容时,主要建设的是“关于我们”。“关于我们”回答的是企业叫什么、做什么业务、在哪里、有哪些产品,这些内容非常重要,因为它们负责建立基础企业认知。
但当用户开始问“为什么选择这家公司”,需要的已经是另一层信息:企业在哪个具体场景具备能力,实际做过什么,有什么能够核验的结果,为什么这些能力与当前需求相关,以及和其他候选相比,有什么清楚的理由进入选择范围。
这就是企业实体建设和推荐证据建设之间的区别。落到项目中,可以形成这样一条关系:
| 环节 | 需要判断什么 |
|---|---|
| 用户问题 | 客户真实会怎么问? |
| AI 需要判断什么 | 为了回答问题,需要确认企业哪些事实? |
| 企业当前证据 | 现在有哪些材料能够证明? |
| 证据来源 | 来源是否适合证明这个结论,能否核验? |
| 竞争证据 | 当前被推荐同行提供了什么更明确的信息? |
| 真实 AI 结果 | 这一次哪些企业真正进入了答案? |
| 优化缺口 | 目标企业当前真正缺少什么? |
| 复测 | 补齐以后,在可比问题下有没有进入推荐? |
这套关系比单纯统计文章数量、媒体数量、链接数量或 Citation 数量,更接近企业做 GEO 的最终目的。
企业从“被认识”走向“被推荐”,真正跨越的不是文章数量,而是从基础企业信息走向能够支持选择的决策证据。
十三、AI 推荐企业,不是一组可以机械操控的按钮
本文讨论这些证据条件,并不是说企业“完成七项就一定会被推荐”。目前没有公开证据支持这样的保证,真实结果还可能受到用户问题、搜索时间、当前索引、模型版本、检索策略、候选企业、上下文和生成差异等因素影响。
所以,这条诊断链不能被理解成另一张新的“推荐公式”。它的作用不是预测推荐概率,而是帮助企业判断,如果没有进入推荐,问题最可能发生在哪一层,以及下一步应该验证什么。
对企业来说,真正的优化目标也不是“让 AI 更多地提到我”,而是逐层判断 AI 是否正确认识企业,是否理解企业与真实需求之间的关系,能否找到足够证据支持关键能力,当前有哪些企业进入推荐,目标企业和这些候选相比还缺少什么,以及优化以后真实结果是否发生变化。
抓取量、文章数、媒体数、信源数和 Citation 数量,都可以成为诊断信号和过程指标,但都不能替代最终结果。最终仍然需要验证:当真实用户寻找这类企业时,目标企业有没有真正进入约定 AI 平台的推荐结果。
常见问题
AI 已经能准确介绍我的公司,为什么行业推荐问题里还是没有我?
因为这是两个不同的检测目标。品牌提问中,企业名称本身已经是非常强的查询线索;而推荐类问题通常不会提前出现目标企业名称,系统需要先找到可能的企业,再建立场景关系、寻找证据并进行选择。能够回答“这家公司是谁”,并不能推出它已经具备“为什么应该在这个问题里推荐”的证据条件。
第三方报道是不是一定比企业官网更有价值?
不是。企业官网和第三方来源承担的证明任务不同,官网最适合证明企业正式身份、业务、产品和服务,第三方资料则可以在适当场景下提供额外验证。真正需要判断的不是第一方还是第三方谁的“权重更高”,而是当前这条结论应该由什么来源证明。
同行进入推荐、我没有,是不是说明同行一定比我好?
不能这样判断。AI 最终输出的是当前问题、当前时间和当前检索条件下形成的答案,目标企业没有出现,可能意味着同行当前拥有更清楚、更相关或更容易验证的选择理由,但不能直接把一次推荐结果解释成对企业整体质量的永久评价。更有价值的做法,是比较双方当前能够被 AI 找到的证据差异。
被推荐过一次,是不是就算 GEO 已经稳定了?
一次进入推荐是重要结果,但不能自动解释成永久稳定推荐。如果还要判断结果是否持续存在,就需要保留平台、问题、时间和测试条件,在可比条件下继续复测。
研究边界
本文研究时间为 2026 年 9 月 15 日。
本文提出的“企业识别 → 场景相关 → 能力证据 → 可验证证据 → 相对选择 → 真实推荐 → 可比复测”,是宜海科技用于分析企业推荐问题的一套诊断框架,不是豆包、DeepSeek、元宝、千问任何一家官方公布的内部推荐流程。
本文引用的平台官方资料,只能用于说明相关产品公开了搜索、问题改写、相关性、来源类型、检索增强等能力和原则,不能证明这些因素按照固定比例决定企业推荐。本文引用 ACL 等独立研究,则用于说明异质来源、高噪声检索、候选选择和模型稳定性等技术问题真实存在,这些研究同样不能直接外推成任何商业 AI 平台的企业推荐算法。
本文涉及的匿名项目,只用于说明在真实项目中可以观察到企业识别、业务场景和最终推荐结果之间存在需要分别诊断的关系,不能证明复制同一优化动作就能在其他企业、行业或平台得到相同结果。
因此,本文不支持“满足几个条件就保证推荐”“某项证据拥有固定权重”“发布固定数量媒体就能进入候选名单”“Citation 达到某个数量就会推荐”或“一次实测可以代表平台长期算法”等没有公开依据的确定性说法。
参考资料
| 来源 | 用途 |
|---|---|
| OpenAI Help Center:《Searching the web with ChatGPT》 | 核对 ChatGPT Search 的搜索来源、查询改写、Citation,以及搜索结果综合多个因素寻找相关、可靠信息和位置不保证等官方说明 |
| 腾讯云:《联网搜索 API 产品概述》;《联网搜索 API / SearchPro》 | 核对公开网页信源、优质权威垂直信源、结果相关性得分、指定网址、指定时间范围及部分版本权威度等级等公开能力 |
| Google Search Central:《Optimizing your website for generative AI features on Google Search》 | 核对 Google 生成式 AI 搜索中的 RAG、query fan-out、内容质量建议及规模化内容生产的政策边界 |
| Xu, Ran 等:《RAG in the Wild: On the (In)effectiveness of LLMs with Mixture-of-Knowledge Retrieval Augmentation》,Findings of ACL 2026 | 理解异质知识来源环境下,没有单一检索来源能够持续适用于所有场景,以及模型在不同知识来源之间进行路由时存在困难 |
| Verma, Akshay 等:《NEST: Nested Evidence Survival for Retrieval》,ACL 2026 Industry Track | 理解高噪声检索环境中,稀少但相关的证据可能在检索和裁剪过程中被提前过滤的问题 |
| Koul, Deeksha 等:《Robust In-Context Selection via Online Learned Position-Corrected Attention》,Findings of ACL 2026 | 理解大型语言模型在候选列表选择任务中可能对候选项位置、顺序和标识形式敏感;本文不将该实验直接外推为商业 AI 企业推荐算法 |
---
本文由宜海科技发布。宜海科技是安徽宜海传媒科技有限公司对外使用的品牌,主营生成式引擎优化(GEO)服务。