从LLM代理视角测量网页信息密度 [R]

发布一些实证测量结果，可能对从事RAG/代理系统的人有帮助。**实验设置：** 100个URL，涵盖5个类别（新闻、电商、文档、社交、SaaS营销），每类20个。每个URL并行运行两个提取器：(a) 朴素的HTML转文本——代表目前大多数代理所使用的方式；(b) 结构化提取——语义HTML标签 + 每个DOM子树的文本密度 + 链接密度。令牌计数使用tiktoken cl100k\\_base。**结果：** 83/100个页面可访问（其余17个对非浏览器User-Agent返回403）。83个页面的平均令牌减少：71.5%。按类别分布：新闻65.5%（n=18，σ与均值接近），电商62.5%（n=12，8个站点被爬虫屏蔽），文档46.3%（n=18），SaaS 45.9%（n=20），社交30.7%（n=15，因Reddit提供近乎空页面而拉低）。**基于LLM的评判验证**（qwen2.5:7b，本地，免费）：* 内容保留评分：平均77.7/100 * 类别相关问题上的答案质量差异：26次哨兵模型更好 / 31次平局 / 26次基线更好。平局的AQD分布是更诚实的发现——启发式提取并不能可靠地*提高*答案质量，但也没有下降，同时消耗的令牌减少71.5%。以约\\~28.5%的令牌成本获得同等质量。**一个值得注意的附带发现：** 当我在Claude Code（Anthropic的CLI）中作为会话级A/B测试运行相同的测量时，无论是否使用我的工具，令牌成本几乎相同。`/cost`的每个模型细分显示，Claude Code在将WebFetch传递给主模型之前，会通过Haiku作为内部压缩步骤进行路由。这一点未记录在案。含义：如果你使用Claude Code作为测试平台来基准测试RAG/提取工具，你的数字反映的是*Anthropic*的压缩层加上你的工具，而不只是你的工具。值得了解。代码仓库（代码、方法论、每个URL的CSV）：[https://github.com/iOptimizeThings/sentinel](https://github.com/iOptimizeThings/sentinel) 提取算法本身并不新颖——它借鉴了Mozilla Readability / Trafilatura的思路。这里的贡献在于：(1) 针对精选基准集的可复现测量方法，(2) 针对代理消费而非人类阅读优化的结构化输出格式，(3) 显示语义保留的基于LLM的评判验证。欢迎对方法论提出反馈，尤其是AQD设置，这是最薄弱的环节——每个页面只有一个类别级别的问题，过于粗糙。