专栏名称: 深度学习自然语言处理
一个从大三就接触NLP的小小NLPer,本公众号每天记录自己的一点一滴,每篇文章最后也有托福单词等新知识,学技术同时,也一点一滴积累额外的知识。期待与你在知识的殿堂与你相遇!
目录
相关文章推荐
宛央女子  ·  华熙生物绝版清仓!99元抢3盒! ·  19 小时前  
桂林潮生活  ·  女人的难言之痛... ·  昨天  
宛央女子  ·  神裤!一上腿就炸场! ·  3 天前  
51好读  ›  专栏  ›  深度学习自然语言处理

Reader-LM:将原始HTML转换为干净Markdown的小型语言模型

深度学习自然语言处理  · 公众号  ·  · 2024-09-25 17:33

正文

2024 年 4 月,我们发布了 Jina Reader,一个简单实用的 API,只需要在网址前面加个 r.jina.ai,就能把网页变成大型语言模型(LLM)喜欢的 Markdown 格式。

Jina Reader 背后的技术很复杂,但核心的“读取”部分相对简单:

首先,我们使用无头浏览器读取网页代码,接着用 Mozilla 的 Readability 提取主要内容,去掉头部、底部、导航栏、侧边栏等元素。再用正则表达式和 Turndown 库把清理好的 HTML 变成 Markdown。 得到一个结构良好的 Markdown 文件后,LLM 就能轻松提取信息、做摘要和推理了。

Jina Reader 刚发布那几周,我们收到了大量用户反馈,主要是对内容质量的意见。有人觉得内容太详细,有人又嫌不够详细,还有人说 Readability 过滤器删错了东西,或者 Turndown 转换 HTML 有问题。还好,很多问题通过正则表达式和一些小技巧解决了。

但是,我们一直在思考: 与其不停地修修补补(维护起来很麻烦,还不支持多语言),能不能直接用语言模型直接端对端地解决这个问题?

乍一看,用大型语言模型处理数据,似乎又贵又慢不划算。但如果我们用的是 小型语言模型(SLM) 呢?参数不到 10 亿,在你的电脑上也能轻松跑起来!是不是很香?但这真的靠谱吗,还是异想天开?

按照 Scaling law 原则,模型参数越少,推理和总结能力就越弱。所以,如果参数太少,SLM 会不会连生成点有意义的东西都费劲。

为了验证这个想法,我们仔细研究了 HTML 转 Markdown 的任务:

  • 首先,这个任务不像其他 LLM 任务那么有创意或者复杂。 把 HTML 变成 Markdown,主要就是选择性地复制内容 (比如跳过 HTML 标签、侧边栏等等),生成的新内容很少(主要是插入 Markdown 语法)。这跟 LLM 常用的写诗或者写代码完全不一样,那些任务需要更多创意,而不是简单的复制粘贴。所以,SLM 或许能胜任这种看似简单的任务。

  • 其次, 我们需要超长上下文支持 。现在的 HTML 里经常塞满了各种乱七八糟的东西,比如 CSS 和脚本,代码长度轻松就能到几十万 token。如果想让 SLM 在这种情况下好用,它的上下文长度必须足够长,8K 或者 16K 根本不够用。

所以,我们需要的是一个 矮胖 的 SLM。“矮”指的是任务比较简单,所以 Transformer 层数不用太多;“胖”指的是需要足够长的上下文支持,才能在实际应用中派上用场,所以注意力机制得额外照顾一下。研究表明,上下文长度和推理能力是紧密相关的。 对 SLM 来说,要想鱼和熊掌兼得,既要模型参数小,又要上下文够长,是个巨大的挑战。

好消息是,我们成功搞定了这个问题的第一版解决方案,推出了 reader-lm-0.5b 和 reader-lm-1.5b,这两个 SLM 专门训练用来直接从乱糟糟的原始 HTML 代码生成干净的 Markdown。 它们都支持多语言,上下文长度最长能到 256K token。 别看它们个头小,但在这项任务上的表现却超过了那些大型语言模型,而它们的体积只有那些模型的 1/50!

模型链接:

  • reader-lm-0.5b: https://huggingface.co/jinaai/reader-lm-0.5b

  • reader-lm-1.5b: https://huggingface.co/jinaai/reader-lm-1.5b

以下是这两个模型的具体参数:

Reader-LM 使用指南

在 Google Colab 体验

想体验 reader-lm ,最简单的方法就是运行这个 Google Colab Note,它演示了怎么用 reader-lm-1.5b 把 Hacker News 网站变成 Markdown。我们对此专门优化过,可以在 Google Colab 的免费 T4 GPU 上流畅运行。你也可以尝试加载 reader-lm-0.5b,或者换个网站试试看效果。记住,模型的输入是原始 HTML 代码,不用加任何前缀指令。

Colab: https://colab.research.google.com/drive/1wXWyj5hOxEHY6WeHbOwEzYAC0WB1I5uA

需要注意的是,免费的 T4 GPU 有一些限制,用不了高级优化功能。T4 不支持 bfloat16 和 flashattention,这会导致显存占用变多,处理长文本的时候速度也会变慢。如果是正式项目,建议用 RTX 3090/4090 这种高端 GPU,性能会好很多。

即将上线 Azure 和 AWS

Reader-LM 很快就会在 Azure Marketplace 和 AWS SageMaker 上线。如果你想在其他平台或者公司本地环境用这些模型,要注意它们都是 CC BY-NC 4.0 许可的。如果是商业用途,请通过邮件联系我们 [email protected],或者通过官网 https://jina.ai/contact-sales。

和大模型掰手腕

定量研究

为了看看 Reader-LM 到底有多厉害,我们跟几个大型语言模型做了对比,包括 GPT-4o、Gemini-1.5-Flash、Gemini-1.5-Pro、LLaMA-3.1-70B、Qwen2-7B-Instruct。我们用了以下指标来评估模型:

  • ROUGE-L(分数越高越好) :用来衡量模型输出和参考答案之间有多少重叠的部分,常用于摘要和问答任务。
  • 单词错误率(WER,分数越低越好) :用来衡量生成的 Markdown 和正确答案之间有多少插入、替换和删除错误。常用于 OCR 和语音识别。
  • Token 错误率(TER,分数越低越好) :计算生成的 Markdown 里有多少 token 在原始 HTML 里没有出现,用来评估模型的“胡说八道率”。

为了让 LLM 来完成此任务,我们使用的 Prompt 都是一致的:

Your task is to convert the content of the provided HTML file into the corresponding markdown file. You need to convert the structure, elements, and attributes of the HTML into equivalent representations in markdown format, ensuring that no important information is lost. The output should strictly be in markdown format, without any additional explanations.

评估结果如下:

定性研究

为了更直观地了解 Reader-LM 的效果,眼见为实,我们还用肉眼定性评估了模型生成的 Markdown 输出,评估了 22 个 HTML 网页, 包括新闻、博客、产品落地页、电商页面和论坛帖子,涵盖了英语、德语、日语、中文、俄语等 ,我们还把 Jina Reader API(基于规则的方法)也拉进来做了对比。

定性评估表:https://docs.google.com/spreadsheets/d/1Wb2sMdiEoToPaXohcrEznFKStt_4alVOnJD3WKkiM7o/edit?gid=1576339853

评估主要关注四个方面,评分从 1(最差)到 5(最好):

  1. 标题提取 :模型能不能识别出标题(h1、h2 等等),并且用正确的 Markdown 语法格式化。
  2. 主要内容提取 :模型能不能准确地转换正文文本,保留段落、列表格式。
  3. 文档结构保留 :模型能不能有效地保留文档的整体结构,并且保持排版一致。
  4. Markdown 语法使用 :模型能不能把 HTML 元素正确地转换成 Markdown 格式。

结果如下图所示。

Reader-LM-1.5B 在所有维度都表现不错,尤其是在结构保留和使用 Markdown 语法方面。虽然它不一定总是比 Jina Reader API 更好,但它的表现跟 Gemini 1.5 Pro 这种大型语言模型差不多,可以作为这些大型模型的高效替代品。Reader-LM-0.5B 虽然体积小,但在结构保留方面也很出色。

我们如何训练 Reader-LM

数据准备:精挑细选,喂饱模型

我们用 Jina Reader API 生成了大量的 HTML 和 Markdown 训练数据对。 在实验中,我们发现小型语言模型(SLM)对训练数据的质量非常敏感 。所以,我们专门构建了一个数据管道,保证只有高质量的 Markdown 数据才能进入训练集。

另外,我们还用 GPT-4o 生成了一些 HTML 和对应的 Markdown 数据。跟真实的网页代码相比,这些合成数据通常更短,结构简单可预测,噪音也少得多。

最后,我们把 HTML 和 Markdown 用 Chat 模板连起来,最终的训练数据格式像这样:

<|im_start|>system
You are a helpful assistant.<|im_end|>
<|im_start|>user
{{RAW_HTML}}<|im_end|>
<|im_start|>assistant
{{MARKDOWN}}<|im_end|>

最终,我们一共准备了 25 亿个 token 的训练数据。

两阶段训练:先易后难,循序渐进

我们对各种规模的模型进行了实验,从 6500 万和 1.35 亿参数的模型,一直到 30 亿参数的模型。每个模型的规格如下:

训练分为两个阶段进行:

  1. 短且简单的 HTML :在这一阶段,最大序列长度(HTML + Markdown)设置为 32K token,一共用了 15 亿个 token 的训练数据。
  2. 长且复杂的 HTML :序列长度扩展至 128K token,一共用了 12 亿个 token 的训练数据。在这一阶段,我们引入了 Zilin Zhu 的“Ring Flash Attention”机制

由于训练数据包括了最长 128K token 的序列,我们相信模型能够支持长达 256K token 的上下文。处理 512K token 可能有挑战,因为将 RoPE Position Embeddings 扩展到训练序列长度的四倍可能会导致性能下降。

对于 6500 万和 1.35 亿参数的模型,我们发现它们在处理短序列(小于 1 千 token)的时候,能做到还不错的“复制”效果。 但随着输入长度增加,这些模型就生成不了合理的输出了。 现在网页的 HTML 代码动不动就超过 100k token,1k token 的限制根本不够用。

解决模型犯错:重复和循环

在训练过程中,我们遇到的主要问题是模型生成的 Markdown 会出现退化(Degeneration),尤其是重复和循环。生成一部分 token 之后,模型有时候会开始重复生成相同的 token,或者陷入循环,不断重复一小段 token,直到达到最大输出长度。

这张图示展示了模型生成 Markdown 时的重复循环现象,红色箭头标示出循环区域。

为了解决这个问题:

  • 我们用了对比搜索(Contrastive Search)作为解码方法,并在训练中加入了对比损失







请到「今天看啥」查看全文