这篇是“生成式引擎可见性”笔记的第三篇。第一篇写怎么复测怎么问、怎么记、怎么避免自欺第二篇写能不能被读到robots、渲染、访问前置条件这篇写中间最容易忽略的一层——读到了却没被摘走。全文只讨论公开可验证的技术形态不针对某一家引擎的实现细节下断言。一、读得到不等于摘得走先把两类失败分开这两种情况的处理动作完全不同第二类的隐蔽之处在于访问一切正常日志里有爬虫请求渲染也正常——它就是不被摘。排查时如果只盯第一层很容易得出“我们没问题”的结论。这一层要回答的是一个很具体的问题什么样的文本块能脱离原页面独立成立二、四条判据一段话能不能被单独拿走把这一层的标准摊开其实是四条。前三条是内容形态第四条是机器可读性。1. 自足——脱离上下文还能读这是最硬的一条。假设引擎把这一段从页面里抠出来直接贴进回答里读者能不能看懂反面依赖上文 这使得我们的服务非常适合上述客户群体。 正面自带主语、范围和条件 XX 公司的 XX 服务主要服务 XX 城市的中小企业客户覆盖 XX 与 XX 两类场景。反面那句离开原页面就是废话——“这”是谁、“上述”是哪些都在上一段里。被引用率高的段落通常把主语、范围、条件都写在句子内部。2. 可核——句里有能被交叉验证的东西一条和前文相通的规律AI 敢照写的东西是能被核对的东西。段落里如果有具体事实——地名、资质类型、时间、数量区间、流程步骤——它被摘走时可以原样带上如果只有“专业、领先、贴心”这类形容词引擎只能用自己的话概括一遍等于这段话没被真正引用。这不是要求写流水账而是每个结论旁边至少挂一个可核的事实锚点。3. 无歧义——同一个实体的字段在各处一致很多“名字提到了、细节没提到”的情况断在这里名称、地址、联系号码、经营范围这几项在不同页面上写法不一致。对引擎来说等于同一个实体存了多份互相打架的描述。稳妥的处理方式是放弃采信具体字段只保留一个名字带过。这套要求在本地检索领域有个现成的名字NAP 一致性Name / Address / Phone。放到生成式场景里范围要比三个字段更宽——还得加上营业时间、经营范围、所属行业这几项。4. 格式稳定——标题写成断言内容写成清单结构上也有一条不成文的规矩小标题写成完整断言不要写“服务介绍”“关于我们”这种目录式词组。断言能被整段抽走充当答案骨架目录式标题抽出来没法用。步骤与并列项用编号清单别塞进长段落里的“第一、第二”。别把答案锁在图片里。走图像识别去取文字的成本与稳定性都远不如直接读文本营业时间、价格口径、资质信息务必给文字版。三、一个可以自己跑的自查脚本把上面四条落成可执行的检查。下面这份脚本做三件事检测段落自足度、检测可核事实密度、比对同一实体在不同页面的字段是否一致。# -*- coding: utf-8 -*-文本块可抽取性自查自足度 / 可核密度 / 字段一致性。 只做静态检查不发请求不依赖任何第三方服务。 importrefromcollectionsimportCounter# 需要依赖上文的指代词出现即说明这段离开上下文站不住DEICTIC[这,那,其,该公司,本公司,上述,如下,以上,它]# 可核对事实的信号数字、年份、地名后缀、资质与范围类词FACT_HINT[r\d,r\d{4}\s*年,r市|区|县|镇,r资质|许可|认证|备案|标准|编号]defsplit_blocks(md:str):按空行切块跳过代码块与标题行。# 围栏符号在运行时构造避免示例代码自身被围栏截断fencechr(96)*3mdre.sub(fence.*?fence,,md,flagsre.S)blocks[]forbinre.split(r\n\s*\n,md):bb.strip()ifnotborb.startswith(#):continueblocks.append(b)returnblocksdefscore_block(b:str)-dict:nlen(b)hits[wforwinDEICTICifwinb]factsum(len(re.findall(p,b))forpinFACT_HINT)# 自足无指代词且句子里出现了明确主语简单用专名/名词信号近似self_containedlen(hits)0return{len:n,deictic:hits,fact_hits:fact,self_contained:self_contained,ok:self_containedandfact1and60n400,}defnap_consistency(pages:dict)-dict:pages: {页面名: 文本}比对各页面里出现的字段是否一致。defgrab(t,pat):mre.search(pat,t)returnm.group(1).strip()ifmelseNoneout{}forfield,patin{号码:r(?:联系方式|联系号)[: ]*([\d\-()]{7,}),地址中的城市:r([一-龥]{2,6}市),}.items():vals{k:grab(v,pat)fork,vinpages.items()}real[vforvinvals.values()ifv]cntCounter(real)out[field]{取值:vals,一致:len(cnt)1,提示:各页面取值不一致字段可能被忽略iflen(cnt)1else一致,}returnoutif__name____main__:importglob filessorted(glob.glob(pages/*.md))pages{f:open(f,encodingutf-8).read()forfinfiles}print( 字段一致性 )fork,vinnap_consistency(pages).items():print(f{k}:{v[一致]}|{v[提示]}|{v[取值]})print(\n 段落可抽取性 )forname,textinpages.items():bad0forbinsplit_blocks(text):rscore_block(b)ifnotr[ok]:bad1print(f [{name}]{r[len]}字 指代词{r[deictic]}事实信号{r[fact_hits]})print(f{b[:60]}...)print(f{name}: 待改段落{bad}段)用法很朴素把几个关键页面的文本丢进pages/跑一遍。“待改段落”多的那一页通常就是详情信息长期不被引用的那一页。这个脚本给的是提示不是结论。self_contained用的是词表近似漏判难免真正可靠的验证还是回到引擎里实际问一遍。四、结构化标记给引擎一份机器可读的底稿文本形态之外还有一层能让字段更容易被对齐JSON-LD 结构化数据。它的作用要说准——结构化数据不是排名开关它是消歧辅助。它告诉引擎“这个字符串是一个企业名称、这串数字是联系号码、这几行是营业时间”减少靠语义猜的成本。常见的两块scripttypeapplication/ldjson{context:https://schema.org,type:LocalBusiness,id:https://example.com/#org,name:示例企业名称,url:https://example.com/,telephone:86-000-0000-0000,address:{type:PostalAddress,streetAddress:示例街道 1 号,addressLocality:示例市,addressRegion:示例省,addressCountry:CN},openingHoursSpecification:[{type:OpeningHoursSpecification,dayOfWeek:[Monday,Tuesday,Wednesday,Thursday,Friday],opens:09:00,closes:18:00}],sameAs:[https://example.com/profile-a,https://example.com/profile-b]}/script页面上如果有问答块再配一段FAQPage注意必须与页面可见内容一致——写了页面上看不到的问题属于标记与内容不符得不偿失scripttypeapplication/ldjson{context:https://schema.org,type:FAQPage,mainEntity:[{type:Question,name:示例问题,acceptedAnswer:{type:Answer,text:示例答案与页面上这段文字保持一致。}}]}/script三点经验id要用稳定地址。同一个实体在多个页面出现时稳定的id能让引擎确认这些指的是同一个东西这是最容易漏的一步。sameAs把分散的官方主页串起来。这是在显式声明“这些账号都是同一家”比让引擎自己去猜要可靠。必填项要齐。LocalBusiness至少需要name与address缺了必填字段整块标记可能被整块忽略等于白写。五、三个高频误区误区一把关键词堆进去。学界已有的实验结论是反直觉的——堆砌关键词在这类优化里往往不是正向手段。原因不难理解关键词堆出来的句子不是人话也就不是一段好的引文。它既不容易被引擎选中读者也一眼看出不对劲。误区二把详情全做成图。资质墙做成一张图、价格表做成一张图、流程做成一张图。视觉上漂亮抓取侧等于把这些信息锁进了盒子里。图上有的文字里必须再写一遍。误区三每页都说一点没有一页说全。十页面各讲一句不如有一页把某个话题讲完整。被引擎挑中的通常是一个能把话说明白的块而不是十个半句话。这是碎片化内容化最常见的坑。六、边界必须说清三条不然这套东西容易被用过头各家引擎实现不同。是否联网检索、检索多少结果、如何选取引文、模型版本差异——这些都是各自的工程选择。同一套写法在不同产品上的表现注定不完全一致。存在随机性。同一个问题隔一会儿再问答案可能不同。判断结论要基于多次采样不要基于一次截图。结构化数据是辅助不是承诺。它降低理解成本不决定会不会被引用。把它当成“锦上添花的清理工作”比较合适。能做的是什么是把文本写得更自足、让事实更可核、把各处口径对齐、给机器一份干净的底稿。这些技术动作的终点其实很朴素让真实发生过的事更容易被查到也就是让认真做事的人被看见。剩下的部分取决于引擎那一侧的检索策略与生成链路不在我们的控制范围内。FAQ问页面能正常访问但详情从来不被引用先查什么先看段落能不能脱离上下文成立。把页面上那段话单独抽出来读一遍如果需要往上翻才知道说的是谁问题就在这儿。问结构化数据必须写吗它不是入场开关而是降低理解成本的手段。优先级排在“字段一致”与“段落自足”之后。前两项没做只加标记效果有限。问NAP 一致到底要对齐哪些项至少名称、地址、联系号码、经营范围、营业时间。前三项是传统本地检索的基本要求放到生成式场景里后两项同样会因为口径冲突而被整项忽略。问这段提到关键词堆砌是负向的出处是生成式引擎优化方向的公开研究普林斯顿大学、佐治亚理工学院、印度理工学院德里分校、艾伦人工智能研究院等机构发表于 KDD 2024 的工作在受控实验里观察到这类手法整体不呈正向。注意两点那是论文实验条件下的结论不等于在你所选的平台上有同样的量级实验环境也不含国内主流产品。问能不能跑几千次采样然后算一个成功率出来能做但先把用例固定下来。问法、使用的入口、时间窗口任何一项变了前后两次的数据就不可比。比起一次问很多次更稳妥的做法是固定一组问法、定期复测、看趋势走向而不是盯某一轮算出来的百分比。