RAG 与大模型推荐机制解析：为什么 AI 检索增强生成更偏爱竞品数据？

RAG 系统没有主观意义上的“竞品偏好”。某个品牌、产品或站点频繁出现在生成答案中，通常说明它的数据更容易被检索层召回、更适合被重排模型识别，也更容易在有限的上下文窗口中形成可验证的答案证据。

LLM 只是生成链路的末端。真正决定候选内容能否进入答案的环节，往往发生在查询改写、向量召回、关键词召回、元数据过滤、Rerank、上下文裁剪和事实校验阶段。

一份内容即使写得完整，只要没有进入候选集合，生成模型就不会看到它。反过来，竞品页面如果具有清晰的实体名称、明确的产品属性、稳定的页面结构和较高的事实密度，就更容易在多个处理阶段持续获得较高分数。

RAG 检索层：向量语义匹配与 Chunk 粒度

RAG 召回不是一次简单搜索

典型 RAG 检索链路通常包含以下步骤：

1. 对用户问题执行意图识别、关键词提取或查询改写。

2. 将查询转换为向量表示，在向量数据库中执行近似最近邻检索。

3. 使用 BM25、倒排索引或其他关键词检索补充专有名词、型号和精确参数。

4. 根据时间、语言、文档类型、权限或实体类别过滤候选结果。

5. 对多个召回通道的结果进行融合、去重和分数归一化。

6. 将候选 Chunk 交给 Rerank 模型重新排序。

7. 从高分结果中选择有限数量的内容注入 LLM 上下文。

向量数据库解决的是语义邻近问题，不直接判断事实真伪。向量余弦相似度较高，只能说明查询与文档在嵌入空间中距离较近，不能证明文档内容正确、完整或来自可靠来源。

例如，用户查询“支持私有化部署的日志分析平台”，模型可能同时召回以下内容：

• 产品功能说明。

• 私有化部署教程。

• 日志系统选型文章。

• 竞品对比页面。

• 包含相关术语但没有实际部署能力的营销文本。

这些内容在语义上都可能接近查询。系统必须依靠元数据、关键词信号、实体信息和重排模型进一步区分。

Chunking 决定可检索单元的边界

网页进入向量数据库前，通常会被切分为多个文本块。Chunk 粒度会直接影响 RAG 召回率和上下文可用性。

Chunk 过小会产生以下问题：

• 产品名称与功能描述被切到不同文本块。

• 条件、结论和适用范围相互分离。

• 代词失去指代对象。

• 参数缺少单位、版本或上下文。

• 单个文本块无法独立回答问题。

Chunk 过大也会降低检索质量：

• 一个向量同时承载多个主题，语义中心被稀释。

• 无关导航、推荐内容和页脚进入同一文本块。

• Rerank 模型需要处理大量噪声。

• 有限的上下文窗口被低价值文本占用。

• 高相关句子可能受到长文本位置偏差影响。

固定字符数切分实现简单，但容易破坏语义边界。工程上更适合综合使用以下切分依据：

• 标题层级。

• 段落和列表边界。

• 产品、功能或步骤模块。

• 句子语义变化。

• 页面 DOM 区块。

• 表格、参数组和问答单元。

• 文档版本与章节元数据。

每个 Chunk 应尽量具备局部自解释能力。产品名称、功能结论、适用条件和关键参数最好能够在同一文本块内形成完整语义。

重叠窗口不是万能修复方案

Chunk 之间保留一定重叠，可以减少边界切分造成的信息丢失，但重叠比例过高会形成大量近重复内容。

重复 Chunk 会带来几个副作用：

• 向量数据库容量增加。

• Top-K 结果被同一页面的相似段落占满。

• 来源多样性下降。

• Rerank 计算量增加。

• LLM 上下文中出现重复事实。

• 多个重复片段可能形成虚假的证据数量优势。

更稳定的处理方式是结合语义切分、父子文档检索和结果去重。检索阶段使用较小的子 Chunk 提高匹配精度，进入生成阶段时再回溯到包含完整上下文的父级段落。

为什么竞品内容更容易进入召回集合

竞品页面更容易被召回，常见原因并不是内容数量更多，而是其表达更接近用户查询。

例如，用户查询包含“适用场景、部署方式、接口能力、价格边界、性能指标”等采购语义，而某个页面只描述品牌理念，另一个页面则明确列出产品类别、部署模式、协议、技术参数和限制条件。后者与查询向量之间通常会形成更清晰的语义对应。

影响召回概率的因素包括：

• 页面是否明确出现实体名称和产品类别。

• 功能描述是否使用具体技术术语。

• 关键结论是否集中在独立段落。

• 参数是否包含对象、数值、单位和条件。

• 内容是否覆盖用户实际提问方式。

• 页面是否存在大量模板噪声和重复文案。

• 文档是否携带准确的标题、时间和类别元数据。

• 重要信息是否依赖脚本执行后才能出现。

内容无法被稳定切分，或者切分后缺少实体主体，即使整篇页面主题相关，也可能在 Chunk 级检索中失去竞争力。

知识关联层：Entity Trust 与结构化数据锚定

实体解析发生在字符串匹配之后

Web 数据进入搜索或 RAG 系统后，通常需要进行命名实体识别和实体消歧。

命名实体识别负责从文本中提取企业、产品、人物、地点、技术和组织等对象。实体消歧负责判断多个相似名称是否指向同一个现实对象。

例如，一个产品可能同时存在以下表达：

• 正式产品名称。

• 简称。

• 英文名称。

• 历史名称。

• 型号名称。

• 用户常用别称。

系统需要结合页面标题、所属组织、域名、上下文属性和外部标识判断这些名称之间的关系。如果同一站点在不同页面使用多个名称，却没有提供稳定的主体信息，实体关联就容易发生断裂。

实体关系常被表示为知识图谱三元组：

• 某企业，开发，某产品。

• 某产品，支持，某协议。

• 某产品，适用于，某业务场景。

• 某版本，发布时间，某日期。

• 某产品，从属于，某产品类别。

RAG 系统不一定直接构建完整知识图谱，但实体抽取、关系识别和元数据关联可以用于过滤、扩展查询、结果聚合与事实校验。

Entity Trust 不是统一公开的固定分数

“实体信任度”更适合作为一组工程信号的统称，而不是所有搜索引擎和大模型共同使用的标准字段。

不同系统可能综合评估：

• 实体名称是否稳定。

• 页面主体是否明确。

• 产品与组织关系是否一致。

• 属性是否具有来源和时间信息。

• 同一事实能否被多个独立页面验证。

• 页面是否存在明显冲突或过期数据。

• 域名、文档和段落的历史质量。

• 内容是否能够被准确抽取。

• 页面状态码、规范地址和语言信息是否正确。

• 当前文本是否真正支持待回答的问题。

因此，域名可信不代表其中每个段落都适合作为答案依据。RAG 系统通常需要区分域名级、文档级和段落级信号。

一个具有历史权威性的站点，如果当前页面没有直接回答问题，Rerank 分数仍可能低于一个主题明确、证据完整的普通页面。

Schema.org 如何降低实体解析歧义

Schema.org 结构化数据可以显式描述页面中的实体类型、属性和关系。例如：

• Organization 表示组织主体。

• Product 表示具体产品。

• SoftwareApplication 表示软件应用。

• Article 表示文章及其作者、发布日期和修改日期。

• BreadcrumbList 表示页面在站点信息架构中的位置。

• FAQPage 表示页面中真实可见的问答内容。

结构化数据的核心价值不是直接提高向量相似度，而是降低机器解析网页时的歧义。它能够帮助系统判断“谁拥有什么属性”“产品属于哪个组织”“当前页面描述的是文章还是产品”。

结构化数据应与页面可见内容保持一致。页面正文没有价格、版本或评价信息，却在结构化数据中单独声明这些属性，会降低数据一致性。

常见的实体断裂问题包括：

• Organization 使用简称，Product 的品牌字段使用另一个名称。

• 多个页面为同一产品生成不同标识。

• 产品页没有声明所属品牌或组织。

• 文章发布者与站点主体没有明确关系。

• 页面改版后保留了旧版本结构化数据。

• 规范地址与结构化数据中的页面地址不一致。

• 同一个属性在正文、Open Graph 和 Schema.org 中取值不同。

Open Graph 的作用边界

Open Graph 主要用于描述页面分享时的标题、摘要、图片和类型。它可以帮助抓取系统快速获得页面级概要，但通常不足以表达复杂的产品属性和实体关系。

较稳妥的分工方式是：

• HTML 标题与正文承担主要内容。

• Open Graph 描述页面级展示信息。

• Schema.org 描述实体类型、属性和关系。

• 站点内部链接表达栏目和主题关联。

• 规范地址解决重复页面归一化问题。

结构化数据不能替代正文。很多 RAG 管线仍然以可见文本作为主要检索对象，Schema.org 和 Open Graph 更可能作为补充元数据参与实体对齐、过滤或结果展示。

高置信度上下文具有哪些特征

RAG 管线中的高置信度上下文，通常具备以下特征：

• 片段与查询具有直接语义关系。

• 片段内部包含明确的实体主体。

• 结论能够在文本中找到直接证据。

• 数值包含单位、时间和适用条件。

• 文档来源与内容类型可以识别。

• 页面发布时间和修改时间明确。

• 内容与同一实体的其他页面没有明显冲突。

• 页面结构稳定，正文能够被正确抽取。

• 信息密度较高，模板噪声较少。

• 内容不是对其他来源的模糊转述。

• 当前版本仍然有效。

• 引用片段能够独立支持答案中的具体表述。

所谓“优先生成”，本质上是上下文更适合回答问题。生成模型在有限窗口中倾向于使用直接、完整且互相一致的证据，而不是从多段含糊文本中推断事实。

排序与生成层：Rerank 与 Context Injection

Rerank 解决向量召回的粗排问题

向量召回通常需要从大规模索引中快速返回候选结果。为保证速度，近似最近邻检索会牺牲部分精度，而且单个向量难以完整表达查询与长文本之间的细粒度关系。

Rerank 模型会对查询和候选文本进行更深入的联合编码。交叉编码器能够同时看到查询与段落中的词语交互，因此比单独生成向量更适合判断：

• 段落是否直接回答问题。

• 限定条件是否一致。

• 实体是否匹配。

• 数值和属性是否属于正确对象。

• 内容是否只是主题相关，却没有实际答案。

• 文本中是否包含否定或例外条件。

一个常见管线是先从向量和关键词索引召回数十到数百个候选，再由 Rerank 模型压缩到少量高相关片段。

如果目标站点没有进入初始召回集合，Rerank 无法补救。如果站点被召回但片段缺少完整事实，交叉编码器仍可能把它排在竞品之后。

排序分数通常由多种信号组成

生产环境中的排序很少只依赖单一模型分数。候选结果可能同时考虑：

• 向量语义相似度。

• BM25 或关键词匹配分数。

• Rerank 相关性分数。

• 实体匹配程度。

• 文档时效性。

• 来源与文档类型。

• 页面质量和历史反馈。

• 内容重复度。

• 结果多样性。

• 语言和区域一致性。

• 权限与安全过滤结果。

• 当前问题的可回答性。

不同分数的量纲并不相同，需要进行归一化或学习排序。若融合策略设计不当，关键词通道的高分结果可能压制语义结果，或者向量结果过度集中在同一来源。

Context Injection 受到窗口预算约束

Rerank 完成后，系统还需要把候选片段组装成提示上下文。这个阶段并不是把全部高分内容直接拼接起来。

上下文构建通常需要处理：

• 总 Token 预算。

• 单个来源允许占用的长度。

• 重复内容去除。

• 文档顺序。

• 实体聚合。

• 来源多样性。

• 时间冲突。

• 证据与问题子任务的对应关系。

• 系统指令和用户历史所占空间。

如果一个站点的多个 Chunk 内容高度重复，它们可能在去重阶段只保留一条。另一站点虽然单条分数略低，但提供了不同维度的补充事实，仍可能获得更多上下文位置。

长上下文还存在位置敏感问题。关键证据处于上下文中部时，生成模型不一定能够稳定利用。工程上通常会把最直接的证据放在靠前位置，或按问题子任务组织上下文。

生成阶段并不会平均使用所有来源

LLM 接收到上下文后，会根据问题、系统提示和证据内容生成答案。它不会保证每个来源获得相同权重。

以下内容更容易被模型采用：

• 与问题句式直接对应的陈述。

• 带有明确主体的事实。

• 多个片段相互支持的结论。

• 包含具体参数和边界条件的说明。

• 在上下文中位置较突出且没有冲突的信息。

• 能够直接转换为答案句子的文本。

如果多个来源发生冲突，系统可能选择排序分数较高或时间较新的来源，也可能降低回答置信度。缺少冲突处理机制时，模型还可能把不同来源的属性错误合并到同一实体。

因此，生成结果中竞品出现得更多，可能由多个阶段共同造成：

1. 用户问题与竞品页面的语义表达更接近。

2. 竞品页面被切分后仍保留完整实体和属性。

3. 关键词召回能够匹配其产品名、型号或技术参数。

4. 结构化数据帮助系统完成实体对齐。

5. Rerank 判断其片段具有更强的直接回答能力。

6. 上下文去重后，竞品仍然保留了多个互补证据。

7. 生成模型能够从这些证据中提取确定性较高的陈述。

这不是模型对特定品牌形成了主观偏好，而是数据结构与检索管线之间的匹配程度不同。

Web 站点内容结构化改造建议

让页面具备稳定的实体主体

一个页面应明确说明当前内容描述的是哪个组织、产品、版本或技术对象。

建议保持以下信息一致：

• 正式名称。

• 常用简称。

• 产品与组织的从属关系。

• 产品类别。

• 页面规范地址。

• 版本号。

• 发布日期和修改日期。

• 作者或发布主体。

• 适用地区与语言。

需要使用别名时，应在正文中建立明确映射，不要在不同页面无规则切换名称。

按可检索单元组织内容

页面结构应考虑后续 Chunking，而不只是浏览器视觉效果。

适合独立成段的信息包括：

• 产品定义。

• 适用场景。

• 技术能力。

• 部署方式。

• 协议与接口。

• 性能参数。

• 数据边界。

• 版本差异。

• 限制条件。

• 常见问题。

每个段落应尽量保留实体名称和必要限定条件。避免连续使用“该方案”“本产品”“它”等代词，否则文本被独立切分后可能失去指代对象。

参数说明应同时包含对象、属性、数值、单位和测试条件。仅给出孤立数字，对实体检索和事实校验帮助有限。

控制模板噪声与重复内容

导航、页脚、相关推荐、弹窗和重复说明可能进入正文抽取结果。模板文本占比过高，会降低 Chunk 的主题纯度。

需要重点处理：

• 多个页面重复的大段企业介绍。

• 与页面主题无关的推荐内容。

• 隐藏但仍存在于 DOM 中的旧文案。

• 移动端和桌面端重复输出的正文。

• 参数表与正文完全重复。

• 标签页中预加载但不可见的其他内容。

• JavaScript 生成的重复节点。

页面去重还应处理不同参数地址、打印版本和历史路由，避免同一内容形成多个互相竞争的索引对象。

结构化数据必须与可见正文一致

结构化数据应描述页面真实存在的内容，并使用稳定的实体标识。

改造时可以检查：

• Organization 与 Product 是否建立品牌或所有者关系。

• Article 是否包含准确的发布者和时间。

• Product 属性是否与正文参数一致。

• 页面地址与规范地址是否一致。

• 同一实体在不同页面中是否复用统一标识。

• Open Graph 标题是否与页面主题一致。

• FAQPage 是否对应用户实际可见的问答。

• 修改内容后是否同步更新结构化数据。

结构化数据的作用是减少歧义，不是堆叠更多关键词。大量无关属性可能增加解析冲突。

保证内容可以稳定抓取

RAG 系统的数据来源可能是搜索索引、专用爬虫、内容接口或离线数据集。无论采用哪种入口，网页都应提供稳定的可访问性。

需要检查：

• 核心正文是否存在于初始 HTML。

• 页面是否返回正确的 HTTP 状态码。

• robots 规则是否误拦截正文或渲染资源。

• 规范地址是否指向有效页面。

• 页面是否依赖登录、Cookie 或交互才能显示内容。

• JavaScript 失败时是否完全无法识别页面主题。

• 页面响应时间是否超过抓取系统预算。

• 站点地图是否包含有效的公开页面。

• 删除或迁移页面是否提供正确状态与重定向。

• 页面更新后缓存是否能够及时失效。

用检索指标验证改造效果

内容结构改造不能只根据页面是否美观进行验收。应建立一组与真实问题对应的测试查询，并测量检索管线表现。

可以使用以下指标：

• Recall@K：相关文档是否进入前 K 个候选结果。

• Hit Rate：测试查询是否至少召回一个有效片段。

• MRR：首个相关结果在排序中的平均位置。

• nDCG：多个相关结果的排序质量。

• Rerank Top-N 命中率：重排后有效证据是否得到保留。

• Context Precision：注入上下文中有效证据所占比例。

• Context Recall：回答所需证据是否被完整覆盖。

• Answer Faithfulness：生成内容是否得到上下文支持。

• Citation Precision：引用来源是否真正支持对应结论。

• Entity Accuracy：实体、属性和关系是否正确绑定。

测试集应覆盖品牌词、产品词、技术属性、场景问题、比较问题和长尾表达。只用页面标题作为查询，无法反映真实用户问题下的召回能力。

还可以进行消融测试，分别关闭向量召回、关键词召回、结构化元数据和 Rerank，观察各组件对结果的实际贡献。这样能够判断问题出在数据覆盖、Chunking、召回通道还是重排阶段。

工程判断与结论

RAG 生成答案时“偏爱竞品数据”，本质上是检索可见性、实体清晰度、段落可回答性和证据完整度共同作用的结果。

向量数据库负责从语义空间中发现候选内容，但向量余弦相似度不等于事实置信度。Chunking 决定内容以什么粒度参与召回，结构化数据帮助系统稳定识别实体和关系，Rerank 交叉编码器负责判断候选片段是否真正回答问题。

Web 内容要进入高置信度上下文，需要同时满足几个条件：

• 页面可以被稳定抓取。

• 实体名称和关系不存在明显歧义。

• 关键事实能够形成独立、完整的文本块。

• 结构化数据与正文保持一致。

• 内容具有明确的时间、版本和适用范围。

• 召回结果能够通过重排模型的相关性判断。

• 注入上下文后仍具有足够高的信息密度。

• 生成结论能够被原始片段直接支持。

排查此类问题不能只查看最终答案。需要沿着查询改写、初始召回、元数据过滤、Rerank、上下文组装和生成输出逐层检查，找到目标内容真正退出候选集合的位置。

---

 

技术参考与实践来源：
本文技术排查与 RAG 检索架构分析案例参考自 为什么 AI 总是推荐竞品而不是你？揭秘大模型背后的品牌推荐机制，特此记录与分享。