给 LLM 插上四肢五官是热点探索的方向之一，前有 perplexity.ai 基于LLM搜索引擎估值20亿，也有更早之前 OpenAI 结合 Bing 的搜索能力，近期也即将正式推出 Search 产品。
然而就我体验过的各类给AI“联网”产品的感受而言，我认为表现都不够好。因此虽然我日常工作大量使用 GPT4，但却很少用GPT联网，需要搜索还是会用Google。究其表现差的原因很复杂，可能有爬虫覆盖面的问题、有大模型幻觉的问题、RAG(Retriever-Augmented Generation)架构的问题等等。本篇主要谈其中一个小点：html数据预处理。
HTML to Markdown
所谓“联网”（爬虫）最简单的方式就是直接访问这个url获取到HTML，然而HTML内容过长并且有太多无用的信息比如css、js、svg，对于LLM而言，一是最大context长度不够用，二是无用信息占比过大会分散模型的注意力。而LLM一般都对markdown数据友好，基本都针对markdown进行了训练或微调。
Markdown是一种轻量级标记语言，设计上注重易读易写。这种格式简洁、结构清晰，有助于语言模型更准确地理解和生成文本。Markdown的一致性和简化的结构特征使得大型语言模型在处理这类文本时更有效，能够更好地抽取关键信息。因此，将HTML删减无用标签后，再转为Markdown是一个很自然的思路。
有推友实现的简单版本的 https://github.com/JimLiu/gpt-api 原理很简单，就是删减一些标签，然后交给html2md的库做转换。
也有直接做爬虫框架的 https://github.com/unclecode/crawl4ai 。然而，尽管看起来很厉害，当我用它来测试一个简单的 GitBook 文档页面时，发现很多正文内容均已丢失。
相比之下，https://jina.ai/reader 这个项目效果更好（目前还免费提供API）。我粗略看了下代码，它不仅在 html2md 转换上下了功夫，还使用了 Puppeteer 进行浏览器自动化操作。也就是说遇到浏览器端渲染的内容，也能解析到。
注意力问题
上面提到的三个项目，都有一个共同的问题。因为我们访问的网站都是千奇百怪的，一些网站不按套路写HTML标签，比如本该用标题<h1>的语意，用的是<div>加大字号来表示。再比如很多网站都有的底部“是否接受隐私许可协议接受cookie”的大段提示，也都被收入正文内容里了。
遇到转换效果好的网站，往往都是一些按语意书写html的网站，像是<nav>就用来做导航栏，<main>内就是正文内容，交互按钮就用<button>。而页面中交互内容比较多的网站，效果就不是很好。
总结来说，就是传统的HTML 转 markdown 库，只解决按一个固定规则的标记语言映射。这带来两个难解问题：
- 标记映射不全面不准确，不能正确解读文字的结构。
- 不会取舍，把与正文内容无关的文字都囊括进来。
第一性原理思考
抛开前面的这些问题，从本质想一想，我们人类是如何浏览网站的？
我们通过纯视觉看到网页的大框架，给网页划分了几块大的区域：
- 依据经验知道顶部的一排是“导航栏”，这部分是当我们无法在当前页面获取到想要的信息了，才会去关注它，看看它会把我们引导去哪里。
- 页面的正文，无论它放在了什么顺序，它总是占据视觉最大的区域。
- 条幅、弹窗一般都是提示性的文字或广告，不应给予过多的注意力。
- 将可交互的元素，脑海中总结为一句功能描述：“网站还提供了xxx功能，可以xxx”
- 我们会带着目的性浏览，不关注的信息不投入注意力。
这里引出两个问题：
- 最适合大模型阅读的数据形式是怎样的？
最高效当然是最底层的向量数据。其次是和训练数据/微调数据最类似的数据格式（markdown、json ）。如果我们的互联网是为 AI 设计的，那么完全不需要HTML这种东西了，它太低效不能很好表达文字、媒体间的逻辑结构。RSS、Blockchain、API 才是以AI为本的互联网。
从这个分析中，我们可以得出以下结论：
1. 如果有现成的接口，我们应该让AI去学习调用接口，而不是让它像人类一样浏览网页。
2. 或许在后人类时代，这是一种更普遍的交互方式。
但问题在于，我们距离那个终局还很远，AI 必须先适应人类文明的产物，适应符合人类设计的网站。 - 大模型如何做到和人类一样浏览网站？
可以延伸出很多思路，这里依旧从第一性原理出发。按终局性依次递减，可行性依次递增的顺序来讲：
1. 人类最本质是靠视觉阅读，那拥有多模态的大模型，就应该直接通过视觉，看到网页上的各部分内容。通过它们的视觉关系，理解出他们的层次关系。这是终局方案。
2. 具备超长context，针对HTML（或JSON-LD之类结构化数据）训练或微调出的模型，能够直接输入HTML作为prompt，输出可读性强，有注意力重点的内容，给下一层LLM使用。
3. 人工模拟人类浏览网站的视觉经验，将这些经验写成固定的HTML预处理代码（过滤无用标签、树状总结各部分数据、按区域大小标注关注权重、对媒体资源路由给相应模态的模型等等）。也就是基于规则的预处理。
4 . 像上面提到的项目一样，简单粗暴 HTML to Markdown，在prompt工程方面多做点事情，依靠 LLM 自身的理解力。也就是目前所处的状态。
以上梳理出来的这些方案业界都有相关的项目在研究，我也会持续关注，如果有新的进展突破会写一篇更深入的调研。
对于 ChainBot 业务而言，我们力所能及做探索的是 1.1 和 2.3。也就是利用现有成熟的API，结合基于规则的爬虫预处理来实现LLM的阅读互联网能力。后续有实践案例的进展也会分享出来。
