企业官网建设流程全解析

1. 从“内容被看见”说起：GEO 工程化到底在解决什么问题

做内容的人这两年都有一个共同的体感：以前是“酒香不怕巷子深”，现在是“酒香也怕巷子深，更怕巷子口被 AI 堵死”。传统 SEO 那套关键词堆砌、外链轰炸的玩法，在生成式引擎逐渐接管信息分发入口之后，效果肉眼可见地在下滑。用户不再只盯着十条蓝色链接，而是直接问 AI 要答案，AI 给什么，用户就信什么。这就引出了一个新命题——GEO（Generative Engine Optimization，生成式引擎优化），核心目标只有一个：让你的内容成为生成式引擎在组织答案时优先引用、优先呈现的那一份。

我所在的团队（微三云）在过去大半年里，把 GEO 从一个概念词拆成了一条可落地的工程链路，核心抓手就是RAG（Retrieval-Augmented Generation，检索增强生成）。为什么是 RAG？因为生成式引擎回答问题时，底层逻辑无非两条路：一条是纯靠模型参数里的“记忆”硬答，另一条是先检索外部知识再组织答案。前者不可控、易幻觉、更新慢；后者才是内容方能够施加影响的入口。RAG 链路里的每一个环节——文档切分、向量化、索引构建、召回排序、上下文拼装——都直接决定了你的内容能不能被“看见”、被“看见”多少、被“看见”之后以什么姿态呈现。

这篇文章面向的是三类人：一是做内容运营、SEO 转型 GEO 的从业者，想知道技术底层到底发生了什么；二是做 RAG 应用开发的工程师，想搞清楚内容可见性这件事在工程上怎么量化、怎么优化；三是产品和技术负责人，需要一套可对比、可复现的架构方案来做选型决策。我会把微三云这套 GEO 工程化实践拆开揉碎，从架构设计讲到平台实现对比，中间穿插大量实操细节和踩坑记录，尽量做到你看完就能照着搭一套自己的验证环境。

需要先对齐一个认知：GEO 不是 SEO 的替代品，而是 SEO 在生成式场景下的延伸和升级。SEO 优化的是“排名”，GEO 优化的是“被引用概率”和“引用质量”。排名是离散的、位置固定的；引用是连续的、上下文相关的。你的内容可能排在检索结果第十位，但如果它的语义片段恰好精准匹配了用户问题的某个子意图，它完全有可能被 RAG 链路捞出来塞进上下文，最终出现在 AI 的答案里。这就是 GEO 工程化的价值空间——在检索和生成的夹缝里，为内容争取最大可见性。

2. RAG 链路拆解：内容可见性到底在哪几个环节被决定

2.1 文档切分策略：切得好是召回的前提，切不好是灾难的开始

RAG 链路的第一步是把原始内容变成可检索的片段，这一步的切分策略直接决定了后续所有环节的天花板。我见过太多团队在这一步偷懒，直接按固定字符数硬切，结果就是一句话被拦腰截断，语义完整性荡然无存。生成式引擎召回这种片段，要么答非所问，要么拼凑出错误信息，反而损害内容方的可信度。

微三云的做法是语义切分优先，结构切分兜底。具体来说，对于结构化程度高的内容（比如产品文档、技术手册），优先按标题层级切分，H2 作为一个父块，H3 作为子块，保留父子关系；对于非结构化内容（比如博客、问答），用基于嵌入相似度的语义切分，相邻句子向量余弦相似度低于阈值就断开。阈值我们实测下来设在 0.72 到 0.78 之间比较稳，太低会导致片段过碎，太高会导致片段过长、噪声过多。

这里有一个容易被忽略的细节：切分粒度要和检索粒度对齐。如果你用 512 token 的片段建索引，但检索时只取 top-3，那实际进入上下文的可能只有 1500 token 左右，对于复杂问题根本不够。我们的经验是，索引片段控制在 256 到 384 token，检索时取 top-5 到 top-8，再经过重排序精选 3 到 4 条，这样既保证了召回率，又控制了上下文长度。下面这张表是我们实测不同切分策略对召回率的影响：

注意：语义切分不是银弹，它计算开销大，对于超长文档（比如十万字以上的白皮书）需要先做层次化预处理，否则切分阶段就能把内存吃满。

2.2 向量化与索引：模型选型不是越贵越好，而是要匹配内容语言分布

向量化环节的核心决策是嵌入模型选型。市面上从开源到商用有几十种选择，价格从免费到每百万 token 几十块不等。很多团队一上来就选最贵的，觉得贵就是好，结果发现效果提升有限，成本却翻了好几倍。我们的选型逻辑是先看内容语言分布，再看检索任务类型，最后看成本约束。

微三云的内容以中文技术文档和产品说明为主，夹杂少量英文术语。我们对比了四款模型在自建测试集上的表现：

最终我们选了模型 B 作为主力，模型 D 作为降级备选。原因很简单：模型 C 虽然指标最高，但延迟和成本在规模化场景下不可接受；模型 A 免费但中文语义匹配明显偏弱，会导致大量相关片段被漏掉。选型的本质是在效果、成本、延迟三角里找平衡点，而不是追求单项最优。

索引构建方面，我们用的是 HNSW（Hierarchical Navigable Small World）图索引，而不是 IVF 或 PQ。HNSW 的召回率和查询速度在千万级向量规模下表现最均衡，代价是内存占用较高。我们的参数配置是 M=32，efConstruction=200，efSearch=128。M 控制每个节点的连接数，越大召回越高但内存越大；efConstruction 影响索引构建质量；efSearch 影响查询时的搜索范围。这套参数在 500 万向量规模下，单次查询延迟稳定在 15ms 以内，召回率 95% 以上。

2.3 召回与重排序：两阶段漏斗是控制上下文质量的关键

召回阶段的目标是“宁可多捞，不可漏掉”，重排序阶段的目标是“精挑细选，优中选优”。很多团队只做单阶段召回，直接取 top-k 塞进上下文，结果就是噪声太多，生成质量不稳定。我们采用的是双塔召回 + 交叉重排序的两阶段架构。

第一阶段用双塔模型（就是上面选的嵌入模型）做向量召回，取 top-50。第二阶段用一个轻量级的交叉编码器（Cross-Encoder）对这 50 条做精排，取 top-5。交叉编码器会把查询和片段拼在一起过一遍模型，计算相关性分数，精度远高于向量内积，但计算量大，所以只适合做小规模精排。实测下来，两阶段架构比单阶段向量召回的答案准确率提升了 23 个百分点，而延迟只增加了 8ms 左右。

这里有一个实操心得：重排序模型的训练数据最好来自你自己的业务场景。我们用通用重排序模型时，发现它对技术文档里的代码片段和参数说明区分度不够，经常把包含关键词但不解决问题的片段排到前面。后来我们用线上真实查询日志构造了 5000 条标注数据做微调，重排序准确率从 71% 提升到了 86%。这个投入产出比非常高，建议有条件的团队都做。

2.4 上下文拼装：顺序、去重、截断都有讲究

召回和重排序之后，进入上下文拼装环节。这一步看似简单，实则暗坑无数。首先是顺序问题：把最相关的片段放在最前面还是最后面？我们的实测结论是放在最前面和最后面效果最好，中间位置容易被模型忽略，这就是所谓的“迷失中间”现象。所以我们的策略是：最相关的两条放开头，次相关的两条放结尾，中间放补充信息。

其次是去重问题：不同片段可能包含重复信息，直接拼进去会浪费上下文窗口，还可能让模型产生“这件事很重要”的误判。我们用基于 n-gram 的相似度做去重，相似度超过 0.85 的片段只保留信息量最大的那条。

最后是截断问题：上下文窗口是有限的，超出部分必须截断。我们的做法是优先保留完整句子，宁可少放一条片段，也不放半句话。因为半句话可能导致模型理解偏差，生成错误答案，反而得不偿失。

3. 内容可见性架构设计：从 Schema 到知识图谱的工程化落地

3.1 Schema 标注：让机器读懂你的内容结构

Schema 这个词在 GEO 语境下有两层含义：一层是传统 SEO 里的结构化数据标记（比如 Schema.org 的 JSON-LD），另一层是 RAG 链路里的数据模式定义。微三云的做法是把两者打通，用统一的 Schema 描述内容的结构、关系和语义属性，既服务于传统搜索引擎，也服务于生成式引擎的检索链路。

具体来说，我们为每篇内容定义了一个 Schema 模板，包含以下字段：内容类型（技术文档/产品说明/案例研究）、核心主题、关键实体、实体关系、适用场景、更新日期、可信度评分。这些字段一部分通过人工标注，一部分通过自动化抽取。自动化抽取用的是基于规则和模型结合的方式：先用正则和词典匹配识别实体，再用轻量级分类模型判断关系类型。

这样做的好处是，当 RAG 链路检索到某个片段时，可以同时拿到它的 Schema 元数据，从而在上下文拼装时做出更智能的决策。比如，如果用户问的是“某个功能怎么配置”，系统会优先召回内容类型为“技术文档”、适用场景包含“配置”的片段，而不是泛泛的产品介绍。实测下来，引入 Schema 元数据后，答案的相关性评分提升了 18%。

3.2 知识图谱构建：把碎片化内容连成网

Schema 解决的是单篇内容的结构化问题，知识图谱解决的是跨内容的关系问题。微三云的知识图谱构建流程分四步：实体识别、关系抽取、实体消歧、图谱存储。

实体识别用的是基于 BERT 的序列标注模型，在我们自己的技术语料上微调过，F1 值达到 0.89。关系抽取用的是远程监督加人工校验的方式，先从现有文档里自动抽取候选关系，再人工审核确认。实体消歧是个难点，比如“微三云”和“微三云公司”指的是同一个实体，“RAG”和“检索增强生成”也是同一个概念。我们用向量相似度加规则匹配的方式做消歧，准确率在 92% 左右。

图谱存储用的是图数据库，节点是实体，边是关系，边上带属性（比如关系的置信度、来源文档）。当 RAG 链路检索到某个实体时，可以顺着图谱边扩展召回相关实体和关系，从而把碎片化的内容连成网。举个例子，用户问“RAG 的召回率怎么优化”，系统不仅会召回直接提到“召回率”的片段，还会通过图谱找到“向量化”“重排序”“切分策略”等相关实体，把这些片段也纳入候选集。这样一来，答案的完整性和深度都上了一个台阶。

3.3 Agent 编排：让检索和生成形成闭环

Agent 在 GEO 工程化里的角色是编排者，它负责协调检索、重排序、图谱扩展、上下文拼装、生成这几个环节，并根据中间结果动态调整策略。微三云的 Agent 架构是基于状态机的，每个状态对应一个处理环节，状态之间的跳转条件由规则和模型共同决定。

比如，当 Agent 发现第一次检索的 top-5 片段相关性分数都低于阈值时，它会触发查询改写，用同义词扩展或问题分解的方式重新检索。如果第二次检索仍然不理想，它会触发图谱扩展，从相关实体入手捞更多片段。如果三次尝试都失败，它会返回一个兜底答案，并记录这次失败案例用于后续优化。

这套 Agent 编排机制让整个 RAG 链路从“一次性管道”变成了“自适应闭环”，内容可见性的上限被显著拉高。我们对比了有无 Agent 编排两种情况下的答案质量：

延迟增加了 90ms，但准确率和完整度都提升了 15 个百分点以上，这个 trade-off 在大多数场景下是值得的。

4. 平台实现对比：自建、开源方案与云服务的选型逻辑

4.1 自建方案：可控性最高，但隐性成本不容忽视

自建 RAG 平台意味着从嵌入模型、向量数据库、重排序模型到 Agent 编排全部自己搞定。微三云早期就是走的这条路，用开源模型加自研编排层，部署在自己的服务器上。优势很明显：数据不出域、参数可调、链路可观测、成本可控（不考虑人力）。但隐性成本也很高：模型更新要自己跟、向量数据库调优要自己啃、故障排查要自己扛。

我们自建方案的技术栈是：嵌入模型用开源模型微调，向量数据库用 Milvus，重排序模型用轻量级交叉编码器，Agent 编排用自研状态机，监控用 Prometheus + Grafana。这套栈跑通了全链路，但在规模化过程中遇到了几个硬骨头：一是 Milvus 的集群运维复杂度高，节点扩缩容经常出问题；二是自研 Agent 编排的状态机在复杂查询场景下容易死循环，需要大量人工干预；三是模型更新周期长，从新模型发布到上线平均要两周。

4.2 开源方案：生态丰富，但集成成本高

开源 RAG 方案这两年井喷，从 LangChain 到 LlamaIndex，从 Haystack 到 RAGFlow，选择非常多。我们评估了其中三个主流方案，结论是：开源方案适合快速验证和中小规模场景，但大规模生产环境需要大量二次开发。

LangChain 的优势是生态最全，几乎什么组件都有，但抽象层太多，调试困难，一个简单的检索问题可能要翻五六层源码才能定位。LlamaIndex 在索引和检索方面做得更专注，API 设计更清晰，但 Agent 编排能力相对弱。RAGFlow 是较新的方案，主打端到端 RAG 流程，开箱即用程度高，但定制化空间有限。

我们最终在开源方案的基础上做了大量二次开发，主要是三块：一是替换了默认的切分策略，换成我们自研的语义切分；二是接入了自建的知识图谱做扩展召回；三是重写了 Agent 编排层，用状态机替代了默认的链式调用。这套混合方案在效果上接近自建，但开发效率高了不少。

4.3 云服务方案：开箱即用，但数据主权和成本是隐忧

云服务方案（比如各大云厂商的 RAG 服务）最大的优势是开箱即用，控制台点几下就能跑通全链路，适合没有技术团队的内容运营方。但问题也很明显：一是数据要上传到第三方，对于有数据主权要求的企业不可接受；二是成本随规模线性增长，量大之后比自建贵得多；三是定制化空间有限，切分策略、重排序模型、Agent 编排逻辑基本不可改。

我们的建议是：如果内容量在十万级以下、团队没有 RAG 工程能力、对数据主权不敏感，云服务是性价比最高的选择；如果内容量在百万级以上、有技术团队、对数据主权有要求，自建或开源二次开发更合适。微三云最终选择的是开源二次开发加部分自建组件的混合方案，兼顾了灵活性和开发效率。

5. 实操过程与核心环节实现：从零搭一套可验证的 GEO 链路

5.1 环境准备与依赖安装

先说明一下，这套环境是为了验证 GEO 链路的核心环节，不是生产级部署。生产级部署需要考虑高可用、监控、安全等更多因素。我们用的基础环境是 Ubuntu 22.04，Python 3.10，Docker 24.0。

第一步是安装向量数据库。我们选 Milvus 的 standalone 模式，用 Docker Compose 启动：

wget https://github.com/milvus-io/milvus/releases/download/v2.3.0/milvus-standalone-docker-compose.yml -O docker-compose.yml docker-compose up -d

启动后检查服务状态：

docker-compose ps

应该看到三个容器：milvus-standalone、milvus-etcd、milvus-minio。如果 etcd 或 minio 启动失败，大概率是端口冲突，检查 2379 和 9000 端口是否被占用。

第二步是安装 Python 依赖：

pip install pymilvus sentence-transformers rank-bm25 jieba fastapi uvicorn

这里解释一下每个依赖的作用：pymilvus 是 Milvus 的 Python 客户端；sentence-transformers 提供嵌入模型；rank-bm25 用于关键词召回；jieba 用于中文分词；fastapi 和 uvicorn 用于搭建检索服务接口。

5.2 文档切分与向量化实操

假设我们有一批 Markdown 格式的技术文档，放在./docs目录下。切分逻辑如下：

import os import re from sentence_transformers import SentenceTransformer def semantic_split(text, model, threshold=0.75, max_len=384): sentences = re.split(r'(?<=[。！？.!?])\s*', text) sentences = [s.strip() for s in sentences if s.strip()] if len(sentences) <= 1: return [text] embeddings = model.encode(sentences) chunks = [] current_chunk = [sentences[0]] for i in range(1, len(sentences)): sim = cosine_similarity(embeddings[i-1], embeddings[i]) current_len = sum(len(s) for s in current_chunk) if sim < threshold or current_len + len(sentences[i]) > max_len: chunks.append(''.join(current_chunk)) current_chunk = [sentences[i]] else: current_chunk.append(sentences[i]) if current_chunk: chunks.append(''.join(current_chunk)) return chunks

这段代码的核心逻辑是：先按句子切分，再计算相邻句子的向量相似度，相似度低于阈值或当前块长度超限就断开。阈值 0.75 是我们在技术文档场景下实测比较稳的值，你可以根据自己内容的语言风格微调。

向量化用的是paraphrase-multilingual-MiniLM-L12-v2模型，这个模型对中文支持不错，推理速度快，适合做验证。生产环境建议换成更大的模型或商用 API。

model = SentenceTransformer('paraphrase-multilingual-MiniLM-L12-v2') chunks = [] for filename in os.listdir('./docs'): with open(f'./docs/{filename}', 'r', encoding='utf-8') as f: text = f.read() chunks.extend(semantic_split(text, model)) embeddings = model.encode(chunks, batch_size=32, show_progress_bar=True)

5.3 索引构建与检索服务搭建

把向量和原文一起写入 Milvus：

from pymilvus import Collection, CollectionSchema, FieldSchema, DataType, connections, utility connections.connect(host='localhost', port='19530') fields = [ FieldSchema(name='id', dtype=DataType.INT64, is_primary=True, auto_id=True), FieldSchema(name='embedding', dtype=DataType.FLOAT_VECTOR, dim=384), FieldSchema(name='text', dtype=DataType.VARCHAR, max_length=2000), FieldSchema(name='source', dtype=DataType.VARCHAR, max_length=200) ] schema = CollectionSchema(fields=fields) collection = Collection(name='geo_demo', schema=schema) index_params = { 'metric_type': 'COSINE', 'index_type': 'HNSW', 'params': {'M': 32, 'efConstruction': 200} } collection.create_index(field_name='embedding', index_params=index_params) collection.insert([embeddings.tolist(), chunks, [f'doc_{i}' for i in range(len(chunks))]]) collection.load()

检索服务用 FastAPI 封装：

from fastapi import FastAPI from pydantic import BaseModel app = FastAPI() class QueryRequest(BaseModel): query: str top_k: int = 5 @app.post('/search') def search(req: QueryRequest): query_vec = model.encode([req.query])[0] results = collection.search( data=[query_vec.tolist()], anns_field='embedding', param={'metric_type': 'COSINE', 'params': {'efSearch': 128}}, limit=req.top_k, output_fields=['text', 'source'] ) return [{'text': hit.entity.get('text'), 'source': hit.entity.get('source'), 'score': hit.score} for hit in results[0]]

启动服务：

uvicorn main:app --host 0.0.0.0 --port 8000

测试一下：

curl -X POST http://localhost:8000/search -H 'Content-Type: application/json' -d '{"query": "RAG 召回率怎么优化", "top_k": 3}'

如果返回结果里包含切分策略、重排序、向量化相关的片段，说明链路跑通了。

5.4 重排序与上下文拼装实现

重排序用交叉编码器，这里用cross-encoder/ms-marco-MiniLM-L-6-v2做演示：

from sentence_transformers import CrossEncoder reranker = CrossEncoder('cross-encoder/ms-marco-MiniLM-L-6-v2') def rerank(query, candidates, top_k=3): pairs = [[query, c['text']] for c in candidates] scores = reranker.predict(pairs) ranked = sorted(zip(candidates, scores), key=lambda x: x[1], reverse=True) return [item[0] for item in ranked[:top_k]]

上下文拼装逻辑：

def build_context(reranked_chunks, max_tokens=2000): seen = set() context_parts = [] total_len = 0 for chunk in reranked_chunks: text = chunk['text'] fingerprint = text[:50] if fingerprint in seen: continue seen.add(fingerprint) if total_len + len(text) > max_tokens: break context_parts.append(text) total_len += len(text) if len(context_parts) >= 2: context_parts = [context_parts[0]] + context_parts[2:] + [context_parts[1]] return '\n\n'.join(context_parts)

注意最后那个顺序调整：把最相关的放开头，次相关的放结尾，中间的往后挪。这是基于“迷失中间”现象的优化，实测能提升生成质量。

6. 常见问题与排查技巧实录

6.1 检索结果不相关：从切分、模型、查询三方面排查

检索结果不相关是最常见的问题，排查顺序建议从切分开始。先看切分后的片段是否语义完整，如果片段本身是半句话，那检索再准也没用。检查方法是随机抽 20 个片段人工阅读，如果超过 3 个语义不完整，就要调整切分策略。

切分没问题的话，看嵌入模型是否匹配内容语言。中文内容用英文模型，效果肯定打折扣。可以拿几个典型查询做人工评估，看 top-5 里有没有相关片段。如果完全没有，说明模型不行，要换。

模型没问题的话，看查询本身是否有歧义。用户问“怎么优化”，优化什么？这时候需要查询改写，把模糊查询扩展成具体查询。我们的 Agent 编排里有一个查询改写环节，用 LLM 把用户问题改写成 2 到 3 个具体子问题，分别检索后再合并结果。

6.2 生成答案不准确：上下文质量和模型能力都要查

生成答案不准确，先查上下文质量。把进入上下文的片段打印出来，人工判断是否包含回答问题所需的信息。如果不包含，说明检索环节有问题，回到上一条排查。如果包含但答案还是错，说明生成模型能力不足或提示词有问题。

提示词方面，我们的经验是明确要求模型基于上下文回答，上下文没有的信息不要编。同时给出回答格式要求，比如“先给结论，再给依据，依据要引用上下文原文”。这样能显著降低幻觉率。

模型方面，如果用的是小模型，复杂推理场景下确实力不从心。我们的做法是分级处理：简单事实性问题用小模型，复杂推理问题用大模型。分级策略由 Agent 根据查询复杂度自动判断。

6.3 延迟过高：从索引、重排序、Agent 三处找瓶颈

延迟过高先看索引查询延迟。Milvus 的 efSearch 参数越大延迟越高，可以适当调低，比如从 128 降到 64，召回率可能降 2 到 3 个百分点，但延迟能降一半。如果索引规模很大，考虑用 PQ 量化压缩向量，牺牲一点精度换速度。

重排序是第二大延迟来源。交叉编码器计算量大，如果 top-50 全量重排序，延迟可能上百毫秒。优化方法是先用向量分数粗筛，只对 top-20 做重排序，这样延迟能降 60% 左右。

Agent 编排的延迟主要来自多轮检索。如果查询改写后触发二次检索，延迟直接翻倍。优化方法是设置最大检索轮次上限，比如最多两轮，第二轮还不理想就返回兜底答案。同时可以并行执行多个子查询的检索，用异步 IO 降低总延迟。

6.4 常见问题速查表

提示：排查问题时建议打开详细日志，记录每个环节的输入输出和耗时。没有日志的排查就是盲人摸象，效率极低。

6.5 几个踩过的坑和实操心得

第一个坑是过度依赖向量检索。我们早期只用向量召回，发现对于包含精确术语的查询（比如某个 API 名称），向量模型经常召回语义相关但术语不匹配的片段。后来加了 BM25 关键词召回做混合检索，两路结果合并后再重排序，精确术语查询的召回率提升了 30% 以上。混合检索的权重可以调，我们的经验是向量占 0.7，关键词占 0.3，具体比例看内容类型。

第二个坑是忽略内容更新时间。RAG 链路检索时如果不考虑时间因素，可能召回已经过时的内容。我们在 Schema 里加了更新日期字段，检索时对近期内容做加权，权重随时间衰减。这样新内容的可见性显著提升，用户拿到的答案也更及时。

第三个坑是Agent 死循环。早期 Agent 编排没有轮次上限，遇到无法回答的问题会一直改写查询、一直检索，直到超时。后来加了最大轮次限制和兜底策略，问题才解决。兜底策略很简单：如果三轮检索后相关性分数都低于阈值，直接返回“抱歉，我没有找到相关信息”，同时记录这次失败用于后续优化。

第四个心得是人工评估不可省略。自动化指标（召回率、准确率）只能反映整体趋势，具体到某个查询为什么失败，还是要人工看。我们每周会抽 50 个线上查询做人工评估，标记失败原因，积累了两千多条标注数据，这些数据反过来用于优化切分策略、微调重排序模型、改进 Agent 编排逻辑。这个闭环是 GEO 工程化持续迭代的核心驱动力。

7. 内容可见性的度量与持续优化

7.1 定义可见性指标：从排名思维转向引用思维

GEO 的可见性度量不能沿用 SEO 的排名思维，要看引用指标。我们定义了三个核心指标：引用率（内容被 RAG 链路召回并进入上下文的比例）、引用位置（内容在上下文中的位置，越靠前权重越高）、引用完整度（内容被引用的片段占原文的比例）。这三个指标综合起来，能比较全面地反映内容在生成式引擎里的可见性。

引用率的计算方式是：统计一段时间内所有查询的召回结果，看你的内容出现了多少次，除以总查询数。引用位置用加权分数表示，第一条权重 1.0，第二条 0.8，依次递减。引用完整度用片段长度除以原文长度，反映内容被“切碎”的程度。

7.2 基于指标做内容优化：哪些内容值得重写，哪些值得扩展

拿到指标后，优化方向就清晰了。引用率低但内容质量高的，可能是切分或向量化环节有问题，需要调整技术策略。引用率高但引用位置靠后的，可能是内容开头不够精炼，需要把核心结论前置。引用完整度低的，可能是内容太长太散，需要拆分成更聚焦的短内容。

我们还发现一个规律：包含具体数据、步骤、对比的内容，引用率显著高于泛泛而谈的内容。比如“RAG 召回率优化”这个主题，一篇包含具体参数配置和实测数据的文章，引用率是纯理论文章的 3 倍以上。所以内容创作阶段就要有 GEO 意识，多写干货、少写空话。

7.3 持续迭代：把评估结果反馈到工程链路

GEO 工程化不是一次性项目，而是持续迭代的过程。我们建立了一个周级迭代节奏：周一收集上周的查询日志和人工评估结果，周二分析失败案例并定位原因，周三到周四实施优化（调整切分参数、更新重排序模型、修改 Agent 规则），周五上线验证并记录效果。这个节奏跑了半年，核心指标的提升非常明显：引用率从 34% 提升到 67%，平均引用位置从 3.2 提升到 1.8，引用完整度从 41% 提升到 63%。

这个过程中最大的体会是：GEO 的优化空间在工程链路的每一个环节，但优先级最高的是切分和重排序。切分决定了召回的上限，重排序决定了上下文的质量，这两个环节优化好了，整体效果提升最明显。向量模型和 Agent 编排的优化空间相对小一些，但也不能忽视，它们是锦上添花的部分。

最后分享一个我们内部用的检查清单，每次上线新内容或调整链路时都会过一遍：切分片段是否语义完整？嵌入模型是否匹配内容语言？索引参数是否适合当前规模？重排序候选数是否合理？上下文拼装是否考虑了顺序和去重？Agent 是否有轮次上限和兜底策略？监控是否覆盖了每个环节的延迟和成功率？这个清单看起来简单，但能避免 80% 的低级问题。