1. 从“内容能被搜到”说起GEO 工程化到底在解决什么问题做内容的人这两年应该都有一个明显感受以前写完一篇文章发到平台上多少能靠平台推荐拿点自然流量现在推荐越来越卷流量越来越贵反而“搜索”这条老路又被重新重视起来了。但今天的搜索已经不是当年那个“堆关键词就能排上去”的搜索了——用户可能在搜索引擎里搜也可能在 AI 助手里直接问还可能在企业内部的知识库里检索。内容能不能被这些入口“看见”已经变成一套需要工程化设计的活儿。这就是 GEOGenerative Engine Optimization生成式引擎优化被反复提起的背景。它和传统 SEO 最大的区别在于SEO 面对的是“爬虫 排序算法”你优化的是页面权重和外链GEO 面对的是“检索 生成”你优化的是内容能不能被检索链路召回、能不能被大模型正确理解和引用。换句话说SEO 是让页面排上去GEO 是让内容被“读懂并说出来”。而 RAGRetrieval-Augmented Generation检索增强生成就是这条链路里最核心的工程载体。它把内容切块、向量化、存进知识库用户提问时先检索相关片段再交给大模型组织答案。问题在于很多人把 RAG 当成一个“搭起来就能用”的玩具结果上线之后发现该被召回的内容召不回召回了答非所问答对了又引用错来源。这些问题的根子往往不在模型而在内容可见性架构没设计好。这篇东西我想聊的就是这件事在 RAG 链路下怎么把 GEO 从“玄学优化”做成“工程化实践”。我会围绕内容可见性架构设计、Schema 结构化、平台实现对比这几条主线展开把踩过的坑、验证过的参数、能直接抄的配置都摊开讲。适合正在做企业知识库、内容中台、AI 搜索产品的同学也适合内容运营想搞明白“为什么我的内容 AI 看不见”的人。不管你是刚接触 RAG 的新手还是已经上线过一版想优化的老手应该都能从里面找到能直接用的东西。2. 内容可见性架构的整体设计思路2.1 为什么“可见性”要当成架构问题而不是运营问题很多人第一次做 GEO思路是运营式的多写关键词、多发平台、多铺外链。这套打法在传统搜索时代有效但在 RAG 链路下基本失效。原因很简单RAG 的召回不是靠关键词匹配而是靠语义向量相似度。你堆了一堆关键词向量空间里可能反而稀释了核心语义导致真正相关的查询召不回你的内容。我举个实际例子。之前帮一个做企业服务的朋友看他们的知识库他们把所有产品文档都加了一段“XX系统、XX平台、XX解决方案”的关键词堆砌。结果用户问“你们系统支持哪些部署方式”召回的全是那些关键词堆砌段落真正的部署说明反而排在后面。后来把关键词堆砌删掉改成结构化的“部署方式”小节召回准确率立刻上来了。所以内容可见性必须当成架构问题来解。它涉及三个层面内容怎么切、元数据怎么标、检索怎么配。这三层任何一层没设计好后面模型再强也救不回来。架构设计的核心目标就一个让“对的内容”在“对的查询”下以“对的优先级”被召回。2.2 RAG 链路下内容可见性的三层结构我把这套架构拆成三层来看这样设计的时候不容易漏。第一层是内容层也就是原始素材本身。这一层要解决的是“内容颗粒度”问题。一篇 5000 字的文章直接扔进向量库检索出来的是一大坨模型拿到之后要么截断要么抓不住重点。所以内容层要做的是合理切块chunking并且保证每个块语义自洽。第二层是结构层也就是 Schema 和元数据。这一层是很多人忽略的但恰恰是 GEO 工程化的关键。Schema 决定了你的内容在检索时能带多少“筛选维度”比如来源、时间、类型、权限、业务域。没有 Schema检索就只能靠纯语义精度上不去。第三层是检索层包括向量检索、关键词检索、混合检索、重排序。这一层要解决的是“怎么把候选集排好序”。纯向量检索在长尾查询上表现不稳定混合检索加 rerank 是目前比较稳的方案。这三层是递进关系内容层决定召回上限结构层决定筛选精度检索层决定最终排序。任何一层偷懒整体效果都会打折。2.3 方案选型为什么是 RAG Schema 而不是纯微调或纯关键词这里要解释一个关键取舍。做内容可见性常见有三条路纯关键词检索、纯向量 RAG、模型微调。纯关键词检索的问题是语义泛化差。用户问“怎么退款”你的文档写的是“申请售后返还流程”关键词对不上就召不回。纯向量 RAG 的问题是精确匹配弱用户搜一个具体订单号或者产品型号向量可能召回一堆语义相近但型号不对的内容。模型微调的问题是成本高、更新慢内容一变就得重新训不适合内容频繁迭代的场景。所以目前比较务实的方案是RAG Schema 结构化。RAG 负责语义召回Schema 负责精确筛选和元数据过滤两者互补。Schema 在这里的作用有点像数据库的索引它不直接参与语义计算但它能在检索前把候选集缩小到正确的范围让向量检索在更小的空间里工作精度和速度都更好。这个选型的另一个好处是可解释。纯向量检索召回错了你很难说清为什么加上 Schema 之后你可以看到是哪个字段过滤掉了、哪个字段没匹配上排查起来有抓手。3. 核心细节解析Schema 设计与内容切块实操3.1 Schema 到底该怎么设计从业务查询反推字段Schema 设计最容易犯的错是“照着数据库表抄”。很多人直接把 MySQL 的 database schema table 搬过来字段一大堆结果检索时根本用不上。正确的做法是从业务查询反推先列出用户最常问的 20 个问题看这些问题需要哪些筛选维度再定 Schema 字段。我一般会分三类字段来设计身份类字段来源、作者、业务域、内容类型。这类字段用于权限过滤和范围限定。时间类字段创建时间、更新时间、生效时间。RAG 场景下时间很重要用户问“最新政策”时没有时间字段就只能靠语义猜。语义辅助类字段标签、实体名、产品型号。这类字段用于精确匹配补充。举个实际 Schema 的例子用 JSON Schema 描述大概是这样{ doc_id: string, source: string, biz_domain: string, content_type: enum[faq, doc, policy, manual], created_at: datetime, updated_at: datetime, tags: array[string], entities: array[string], chunk_text: string, chunk_index: integer }这里要特别说一句Schema 不是越全越好。字段太多会导致元数据存储膨胀检索时过滤条件组合爆炸。我的经验是核心字段控制在 8 到 12 个其余的都塞进 tags 或 entities 数组里。3.2 内容切块为什么固定长度切块是个坑切块chunking是 RAG 里最容易被低估的环节。很多 rag 教程上来就是chunk_size500, overlap50然后就不管了。实测下来固定长度切块在结构化内容上表现很差因为它会把一个完整的语义单元从中间切断。我踩过的一个典型坑一份产品配置文档每个配置项是一个小节。固定 500 字切块正好把一个配置项的说明切成两半前半段在 chunk 3后半段在 chunk 4。用户问这个配置项怎么设检索召回 chunk 3模型只看到一半说明答出来的东西缺了关键参数。后来我改成语义切块优先按标题层级切H2 切大块H3 切小块段落作为最小单元。如果单个段落超过 800 字再按句子边界二次切分。这样每个 chunk 都是语义自洽的。实测召回准确率比固定切块高了大概 20 个百分点。具体参数上我的经验值是这样的内容类型切块策略目标 chunk 大小overlapFAQ一问一答为一块100-300 字0产品文档按 H3 小节切300-600 字50政策法规按条款切200-500 字30长篇文章按段落 句子边界400-800 字80overlap 的作用是防止边界信息丢失但不要设太大否则检索结果里会有大量重复内容浪费上下文窗口。3.3 元数据注入让每个 chunk 都“自带说明书”切完块之后每个 chunk 不能光有文本还要带上元数据。这一步很多人偷懒结果检索时没法过滤。我的做法是给每个 chunk 注入一段“上下文前缀”把关键元信息拼在文本前面。比如一个产品文档的 chunk注入后大概是这样[产品: XX系统] [模块: 部署配置] [版本: v3.2] [更新: 2024-06] 支持三种部署方式单机部署、集群部署、容器化部署。单机部署适合测试环境...这段前缀在向量化时会一起参与计算相当于给 chunk 增加了语义锚点。用户问“XX系统 v3.2 怎么部署”前缀里的信息能显著提升召回率。实测这个小技巧能让召回准确率再提升 10% 到 15%。注意前缀不要写太长控制在 50 字以内。太长会稀释正文语义反而降低效果。3.4 结构化知识库和 RAG 知识库的边界热词里有个问题问得很好kg 知识库、rag 知识库和结构知识库怎么区分各自用在哪。我的理解是这样结构化知识库比如 MySQL、图数据库适合精确查询比如“订单号 12345 的状态”。它强在准确弱在语义泛化。RAG 知识库向量库适合语义查询比如“怎么处理退款”。它强在泛化弱在精确。KG 知识库知识图谱适合关系推理比如“A 产品的配件有哪些兼容 B 产品”。它强在关系弱在覆盖广度。实际工程里这三者往往是组合使用的。我的做法是用 RAG 做第一层召回用结构化字段做过滤用 KG 做关系补全。比如用户问“XX系统支持哪些数据库”RAG 召回相关文档Schema 过滤出“数据库兼容性”类型KG 补全具体版本对应关系。单靠任何一个都做不好。4. 实操过程从零搭一条可用的 GEO 检索链路4.1 环境准备与工具选型这一节讲具体怎么落地。工具选型上我不追求最新最炫追求的是稳定和可维护。下面是我目前比较常用的一套组合向量库Milvus 或 Qdrant。Milvus 生态成熟Qdrant 部署轻量。小规模用 Qdrant 就够。Embedding 模型中文场景用 bge-large-zh 或 m3e-base。bge 系列在中文检索上表现稳定。Rerank 模型bge-reranker-base。召回之后加一层重排精度提升明显。编排框架LangChain 或 LlamaIndex。LangChain 灵活LlamaIndex 开箱即用。我一般用 LangChain因为要自定义 Schema 过滤逻辑。本地部署如果数据敏感可以用 Ollama 跑本地模型配合本地向量库整套离线。这里要提醒一句Embedding 模型和 Rerank 模型最好用同一系列的比如都用 bge因为它们的语义空间更一致配合效果更好。混用不同系列的模型有时候反而会互相拖累。4.2 完整链路搭建步骤下面是我实际搭一条链路的步骤按顺序来。第一步内容预处理。把原始内容HTML、PDF、Markdown统一转成纯文本保留标题层级。这一步用unstructured或markdown库都行。关键是保留结构信息别一上来就拍平成纯文本。第二步语义切块。按前面说的策略切块每个 chunk 记录chunk_index和所属标题路径。标题路径很重要它能在检索时提供上下文。第三步元数据注入。给每个 chunk 拼上上下文前缀同时把 Schema 字段填好。这一步建议写个脚本批量处理别手工搞。第四步向量化入库。用 Embedding 模型把 chunk 转成向量连同元数据一起写入向量库。写入时注意把 Schema 字段建成 payload 索引方便后续过滤。第五步检索链路配置。检索分两步先做混合检索向量 关键词再做 rerank。混合检索的权重我一般设向量 0.7、关键词 0.3具体看内容类型。FAQ 类可以调高关键词权重长文档类调高向量权重。第六步Schema 过滤。在检索前根据用户查询解析出过滤条件比如业务域、时间范围、内容类型。这一步能大幅缩小候选集。第七步结果组装。把 rerank 后的 top-k 结果按 chunk_index 排序拼成上下文交给大模型。注意控制总长度别超过模型上下文窗口。4.3 关键参数计算与选择过程参数这块我展开说几个关键的。chunk_size 怎么定我的算法是先看内容平均段落长度chunk_size 设为平均段落长度的 1.5 到 2 倍。比如平均段落 300 字chunk_size 设 500 到 600。这样既能保证语义完整又不会太大。top_k 怎么定召回阶段 top_k 设大一点比如 20 到 30给 rerank 留足候选。rerank 之后取 top 3 到 5 交给模型。实测 top_k 太小会漏召回太大 rerank 压力大且容易引入噪声。相似度阈值怎么定这个没有固定值要看你的 Embedding 模型。我的做法是拿一批标注好的查询-文档对跑一遍看相似度分布取能覆盖 90% 正样本的阈值。一般余弦相似度在 0.6 到 0.75 之间。rerank 阈值怎么定rerank 分数一般比向量相似度更可靠。我通常取 rerank 分数 top 3如果第 3 名分数低于 0.3就只取前 2 名甚至前 1 名。宁可少给别给错。4.4 平台实现对比自建 vs 云服务 vs 开源框架这块我做个对比表方便选型。维度自建LangChain 向量库云服务托管 RAG开源框架LlamaIndex 等可控性高全链路可改低受平台限制中框架内可改成本中主要是运维高按量计费低主要是开发上手速度慢要搭环境快开箱即用中有模板数据安全高数据自持低数据上云高可本地部署适合场景数据敏感、需求定制快速验证、小团队中等规模、要平衡我的建议是验证阶段用云服务快速跑通确认有价值之后迁到自建或开源框架。别一上来就自建容易在环境上耗掉太多时间。5. 常见问题与排查技巧实录5.1 召回不准的排查思路召回不准是最常见的问题排查要按链路顺序来。先看切块。把召回的 chunk 打出来看是不是语义不完整。如果是调整切块策略。再看元数据。检查 Schema 字段有没有填对过滤条件是不是把正确内容过滤掉了。然后看Embedding。拿几个典型查询手动算一下和正确文档的相似度如果相似度很低可能是模型不适合你的领域考虑换模型或加领域微调。最后看rerank。如果召回里有正确内容但排序靠后是 rerank 的问题检查 rerank 模型和阈值。我整理了一个速查表现象可能原因排查方法解决完全召不回切块切断语义打印 chunk 看完整性改语义切块召回了但答非所问元数据缺失检查 Schema 字段补元数据正确内容排后面rerank 弱看 rerank 分数换 rerank 模型召回大量重复overlap 太大看 chunk 重叠率调小 overlap长尾查询差纯向量泛化不足加关键词检索改混合检索5.2 大模型请求失败的常见原因热词里有个报错很典型llm request failed: provider rejected the request schema or tool payload。这个报错一般是请求体不符合模型 API 的 Schema 要求。常见原因有几个一是字段类型不对比如该传数组传了字符串二是必填字段缺失三是 payload 太大超过限制。排查方法很简单把请求体打出来对照 API 文档逐字段检查。我遇到过最常见的是messages字段格式不对或者tools定义里parameters不是合法的 JSON Schema。用 zod schema 做校验能提前发现这类问题建议在请求前加一层校验。5.3 RAG 知识库能不能存图片这个问题问的人很多。答案是能但方式有讲究。纯向量库一般存文本向量图片要先用多模态模型转成文本描述或图文向量。我的做法是图片单独存对象存储向量库里存图片的文本描述和 URL。检索时召回描述需要展示图片时再按 URL 取。这样既省向量库空间又能支持图文混合检索。如果要做图文联合检索可以用 CLIP 这类多模态模型把图片和文本映射到同一向量空间。但这条路成本高一般场景用文本描述就够了。5.4 实操避坑心得最后分享几个我踩过的坑。第一个坑是过度依赖向量检索。刚开始做的时候觉得向量万能结果精确查询一塌糊涂。后来加了关键词检索和 Schema 过滤才稳。记住向量检索是泛化工具不是精确工具。第二个坑是忽略内容更新。内容更新了但向量库没更新检索出来的还是旧内容。我的做法是给每个 chunk 加updated_at内容变更时触发重新向量化。增量更新比全量重建省太多资源。第三个坑是rerank 模型和 Embedding 模型不匹配。有次混用了不同系列的模型召回精度反而下降。后来统一用 bge 系列效果立刻回来。模型选型上一致性比单点性能更重要。第四个坑是上下文拼太长。为了给模型更多信息把 top 10 全拼进去结果模型被噪声干扰答非所问。后来改成 top 3 加 rerank 阈值过滤答案质量反而更好。给模型的信息要精不要多。这套东西我前后调了大半年从最开始召回率不到 50%到现在稳定在 85% 以上。核心体会就一句GEO 工程化不是调模型是调内容和结构。模型是现成的内容和 Schema 才是你的护城河。后续如果要做多模态或者跨语言检索这套架构也能扩展无非是在内容层加多模态处理在 Schema 层加语言字段。先把文本这条链路跑通其他的都是增量。