三个月前我第一次在内部评审会上看到AI搜索带来的流量占比曲线时后背是发凉的。作为一家深耕上海本地生活服务的老牌站点我们过去几年的SEO打法基本围绕“关键词排名外链权重”展开但那一季度来自AI搜索会话式入口的推荐流量突然占了总搜索流量的17%而且还在以每周两三个百分点的速度往上爬。这意味着用户开始习惯用对话式提问代替传统关键字检索而我们精心维护的落地页在AI生成的摘要里压根排不上号。更扎心的是AI搜索的引用逻辑和传统爬虫完全不是一回事它不看你Title标签里堆了多少词它看的是你的内容能不能喂饱它的生成链路。这个项目就是在这个背景下立项的。我们把整套工作称为“AI搜索GEO全链路工程”落地周期用了大约三个半月核心涵盖四个模块查询改写解析、知识库驱动的内容生产、网页质量检测、以及基于多模型的监测与效果评估。整个项目组横跨算法、搜索运营、前端工程和内容生产四个角色人数不多但协作链路拉得很长。这篇文章不打算讲那种“我们很厉害”的总结报告我想把四个模块为什么这么设计、内部怎么协同、实际跑起来踩了哪些坑从头到尾捋一遍给同样在搞AI搜索优化的团队一个可参考的落地样本。先说结论GEO这个东西本质上不是“搜索引擎优化”的简单升级版而是把搜索流量的入口逻辑从“网页排名”切换到了“答案生成”。传统SEO服务的是爬虫和索引库GEO服务的是大模型和知识库。理解这个切换后面所有模块的设计逻辑才立得住。1. 立项背景传统SEO团队接到的那封“降权”邮件项目真正启动的导火索是一封来自某AI搜索平台的站点收录异常通知。对方措辞很客气但核心信息就一句话您的站点内容在与用户查询意图的相关性评估中得分偏低暂时不会作为高优引用来源。当时我们第一反应是技术层面出了问题比如结构化数据缺失、页面加载速度不达标但彻查之后发现传统SEO指标全部正常。后来尝试通过该平台的AI搜索入口实测了十几个核心关键词才看清问题本质AI搜索在生成回答时引用的内容偏好是“带有明确立场、能够直接回答某个具体问题、有上下文连贯性”的段落而不是我们那种“围绕关键词展开、布局了数百字铺垫”的传统营销页面。这个发现让我们意识到需要有一套机制能持续把站点的内容翻译成AI搜索“看得懂、愿意引用”的结构。具体来说我们确定了四条必须同时解决的链路查询侧AI搜索的用户提问是长句、口语化、带模糊意图的必须有一套查询改写解析能力把五花八门的问法归一到我们能够响应的语义框架里。内容侧要让AI搜索引用我们的内容需要有足够优质的知识库作为底料而不是靠编辑临时写稿。质检侧网页上线前必须过一次“AI友好度”质检从内容实体完整性、答案覆盖度、引用友好度等维度打分不合格的不允许发布。监测侧AI搜索的效果不像传统SEO那样有足够透明的排名数据必须自建多模型监测能力用不同大模型当“裁判”来判断我们内容在不同AI平台上的表现。四个模块听起来各管一摊但真正执行起来会发现它们根本拆不开。查询改写解析的输出决定了知识库该命中哪些内容片段知识库的内容结构又直接影响质检规则的权重设计而多模型监测的反馈反过来又要修正查询改写的分词逻辑。所以这个项目从一开始就不是“搭四个工具”而是在搭一条完整的生产线。2. 全局架构四条流水线如何在一个编排框架里协同整个工程落地时我们没有选择把四个模块做成独立微服务再互相调用的方式而是用一个统一的流水线编排框架把它们串起来。核心原因是我们发现这些模块之间除了数据依赖还有非常频繁的策略联动。比如查询改写模块改了一版同义词映射表知识库检索的命中率马上就会波动如果两套系统之间只靠接口通信每次调参都要跨团队扯皮。所以我们做了一个极其朴素但有效的设计所有模块共享一张配置表和一个调度日志任何一方的改动都会触发下游联动验证。模块核心职责上游依赖下游输出查询改写解析将自然语言问题归一到标准查询框架全网热词、站内搜索日志、AI搜索会话样本结构化意图标签、关键实体词、扩展查询词集知识库驱动内容基于知识库生成/改写页面内容查询改写输出的意图标签结构化内容块、实体关系图、引用索引网页质检对内容块进行AI友好度与合规性检测知识库输出的内容结构、质检规则库质检评分、处置建议、阻断列表多模型监测评估内容在主流AI搜索平台的可见性与引用率质检通过后的页面URL集合效果报表、策略调优建议这个架构里最容易被忽略但实际最关键的是“调度日志”这个东西。我们要求四个模块在处理同一条内容时必须把中间态结果全部落日志包括查询改写前的原始语句、改写后的标准查询、知识库命中的片段ID、质检打出的每个维度分数、监测模型给出的评判理由。这套日志一开始只是为了排查问题后来变成了我们调优GEO策略最重要的数据资产。比如我们发现某个类目内容始终不被AI搜索引用回溯日志后发现是查询改写阶段把“附近实惠的亲子餐厅”错误归一到了“性价比餐厅”这个大类导致知识库命中的全是人均消费数据而没有命中“适合带娃”“有儿童餐”这些真正构成答案的实体。没有日志这种问题几乎不可能定位。关于模型选型我们在查询改写和质检阶段用了两个不同的模型分工查询改写解析用的是中等规模、推理延迟低的模型目标是快速把用户问题拆成意图和实体网页质检和知识库内容生成则用更强语义理解能力的大模型保证内容生成的深度。这个“快模型处理入口、强模型处理内容”的搭配是我们在实际压测中一点点调出来的组合后面章节会具体讲。3. 查询改写解析从“关键词匹配”到“意图翻译官”查询改写这个模块表面看就是“把用户的话换成系统听得懂的话”但一旦落到AI搜索场景复杂度会呈指数级上升。因为传统搜索引擎的用户搜索词通常只有两三个词而AI搜索里的用户问题是一整句话甚至带着口语化的情绪和无关信息。比如“上海周末带娃去哪里玩比较好最好不要太远”这句话里传统SEO只需要抓住“上海”“周末”“带娃”几个词就能匹配页面但AI搜索需要理解的是“地点上海”“时间周末”“人物亲子家庭”“约束条件距离近”“需求类别游玩场所”。缺了任何一个维度生成出来的答案就可能完全不匹配。3.1 查询改写解析的实现框架我们这一层用了一个比较轻量化的pipeline没有一上来就上大模型全家桶。第一步是预处理和分词这里我们接入了自研的领域词典把上海本地的商圈名、地标名、餐饮品类名、亲子场所名做了强召回。这一步看起来基础但实际效果立竿见影。比如坦白说通用分词器对“前滩太古里”这种词经常会切成“前滩/太古里”甚至“前滩太/古里”但有了领域词典后它会被当成一个不可拆分的实体词后续的意图识别准确率直接上升。第二步是意图识别。我们把站内用户历史检索日志和AI搜索会话样本做了一轮人工标注定义了十几个核心意图类别包括找地点、比价格、查营业时间、看评价、找攻略、了解优惠等。这个环节我们没有用复杂的意图分类模型而是基于标注数据训练了一个轻量文本分类器配合规则兜底。原因很简单我们的业务域是本地生活服务意图类目有限且边界相对清晰用大模型做分类反而容易因为幻觉输出不存在的意图标签。第三步才是关键叫“实体抽取与槽位填充”。系统要把用户问题里的核心实体和约束条件填到标准化的查询框架里。我们会把问题里的地点、品类、时间、人群、价格区间、特殊需求等字段全部抽取出来形成一个结构化的查询条件集。这个环节用到一个经验不能只靠模型必须配置一套“约束条件识别”规则。像“不要太远”“性价比高”“适合拍照”这类表达模型很容易漏掉但它们恰恰是用户最在意的决策因素。我们把这些高频约束词做了映射词典比如“性价比高”映射到“人均消费偏好中低”“不要太远”映射到“距离5km内”然后再交给模型做整体判断。3.2 热词挖掘与检索日志反馈闭环查询改写模块不是一次建完就躺平的系统。它的词典、意图类目、约束条件映射都需要持续迭代。我们每两周会从三个渠道拉取新样本站内搜索日志用户在站内搜索了什么、百度/微信搜索的下拉相关词外部user intent、AI搜索平台的会话样本用户在对话框里实际怎么问。拉下来的数据会先做一轮聚类把高频出现的表达方式沉淀成“查询改写种子词库”再人工复核后更新到词典里。这个机制运行一个月后我们明显感觉到知识库检索的命中率在上升。原因其实不复杂AI搜索的提问方式在快速演化比如五六月份还在流行“上海哪里好玩”七八月就变成“上海citywalk路线推荐带咖啡店的那种”。如果查询改写模块不跟着迭代知识库检索再强也接不住这些新表达。所以如果你也要做类似系统我的建议是第一时间把检索日志的反馈闭环建起来这比优化任何一个模型参数都重要。3.3 查询改写与大模型的接口约定最后讲一下查询改写模块和知识库检索之间的接口设计。我们把改写结果定义成一种简单的JSON结构包含意图类别、实体列表、约束条件和扩展查询词集四个字段。扩展查询词集是一个特别有用的设计除了用户原始问题系统会自动生成几个同义改写版本作为召回时的候选。比如“上海周末带娃去哪里玩比较好最好不要太远”会生成“上海亲子游玩地推荐”“上海周末亲子活动地点”“上海适合带孩子的公园或商场”等几个变体。这一步能显著提高知识库向量检索的召回率因为向量相似度对同义表达非常敏感多几个变体等于多几次命中机会。4. 知识库驱动内容让模型“带着答案去写作”而不是“现编答案”知识库驱动内容是整条GEO链路里最重的一环也是我们投入人力最多的部分。这里的核心逻辑不复杂AI搜索在生成回答时需要的是有依据的、结构化的、覆盖特定问题视角的内容片段而不是一篇从头讲到尾的长文章。如果我们的页面内容是一篇完整的攻略AI搜索的抽取模型往往只能截取其中一两句话而且不一定能抓到最关键的那几句。所以我们需要把内容拆解成知识库结构让AI容易抽取、容易关联、容易引用。4.1 从“写文章”到“搭知识块”我们做了一个在内容团队内部一开始抗拒很大的变革把页面内容从“文章”改成“知识块”。具体来说针对一个具体主题比如“徐汇滨江遛娃攻略”不再让编辑写一篇1500字的连贯文章而是拆成多个独立的知识块每个知识块只负责回答一个具体问题或呈现一个具体维度。例如基础信息块地址、开放时间、门票价格、交通方式。特色亮点块这个场地最核心的3-5个卖点每句都带上具体名称和数据。适合人群块针对什么年龄段、什么兴趣偏好的人推荐。用户常问块围绕“附近停车方便吗”“有餐厅吗”“下雨天能去吗”等具体问题直接给出答案。同类对比块和附近其他同类场地的优缺点对比。这个结构的价值在于AI搜索的引用机制偏爱“一个片段能完整回答一个子问题”的内容单元。我们把一篇长文拆成五个知识块后每个知识块都有可能在被召回时作为独立引用来源。从实际监测数据看知识块上线后页面被AI搜索引用的概率比长文形态提升了大约2.3倍。4.2 RAG管线的切片、向量化与召回知识库的载体本质上是一个RAG检索增强生成系统。我们把所有知识块内容做切片每个切片控制在300~500字之间然后通过向量化模型转成向量存入向量数据库。在切片这块我们踩过一个教训必须按“语义完整单元”来切不能傻乎乎按固定字数切。最初我们为了省事让脚本每300字一刀切下去结果大量切片把“地址是XXX营业时间是XXX”这种变到了后半截导致问答召回时经常返回不完整的答案。后来我们改为按知识块自然边界切再对过长的块做二次拆分保证每个切片都是一个自洽的语义单元。检索召回方面我们用了一个混合检索策略。第一路是向量检索用用户查询改写的输出做embedding在知识库里找语义相近的切片第二路是关键词检索直接用实体词和约束条件做BM25匹配。两路结果做一个加权融合再排序。这个混合策略非常重要因为向量检索擅长找“意思像”的关键词检索擅长找“字面完全匹配”的AI搜索里的用户问题往往同时包含两种需求。比如“静安寺附近人均300的日料”向量层面要能命中“高级日料餐厅”这种表达关键词层面又要确保“静安寺”“人均300”这两个硬条件不丢。4.3 让内容带“引用锚点”知识库内容除了要写得好还要让AI搜索容易“引用”。我们给每个知识块设计了三个层面的引用锚点显式结论每个知识块的开头第一句必须直接给出结论比如“徐汇滨江适合遛娃的核心原因是空间开阔、设施齐全、餐饮配套完善”。AI模型抽取时最喜欢这种“观点句支撑证据”的结构。数据支撑知识块中的关键判断尽量带上数字、名称、年份等具体信息比如“拥有2.5公里滨江步道”比“有很长的步道”强十倍不止。语义标识在HTML中给不同知识块加上清晰的语义标签比如用section>