在文本信息提取的领域，正则表达式长期以来都是精准匹配结构化数据的强大工具，而LLM（大语言模型）的崛起为非结构化文本解析带来了更灵活的可能性。本文将围绕正则匹配与 LLM 提取展开探讨，并结合Prompt 调用的细节，分析不同模型在文本解析中的表现。

任务描述

从自然语言中提取时间与提醒事项

[2025-10-05 11:25 周日] 三天后早上8点通知我检查邮件  ---> {"time": "2025-10-08 08:00", "Remind": "检查邮件"}
[2025-08-30 09:30 周六] 周一上午10点叫我去银行     ---> {"time": "2025-09-02 10:00", "Remind": "去银行"}

正则表达式：精准的刻刀

在文本提取任务中，正则表达式（Regular Expressions, 简称Regex）是一种强大的工具，能够通过预定义的模式匹配和提取特定格式的文本内容。作为最经典且高效的文本处理方法之一，正则表达式以其简洁性和可靠性著称，尤其适用于结构化或半结构化数据的提取。

对于以上任务，分开设计正则表达式

1. 匹配内容

try:
    content = re.search(r'(提醒|叫)我(.*)', input_text).groups()[-1]
except:
    content = None

2. 匹配时间

简单总结

很显然，函数1匹配案例2；函数2匹配案例1。如果需要匹配其他情况还得写其他表达式。

虽然表达式有限制，但它却是可控的，这对于开发者而言非常重要：对于有问题的新输入开发者知道哪里出了问题，那就没有问题。

结合llm的一些想法

在如今可以通过llm分析表达式中晦涩的表示，而遇到匹配不上的问题，也只需扔到llm中生成新的函数并入到匹配链中。

基于llm的文本提取：万能的钥匙

利用大型语言模型（LLM）通过精心设计的提示（Prompt）来指导模型完成特定任务的方法。这种方法的核心在于通过优化提示语句，使得模型能够更准确地理解需求并生成符合预期的输出。

直接上测试

LongCite-llama3.1-8b

虽然表达式基本准确，但很难进一步提取内容。

• 内存： 22039MiB

deepseek-r1:32b

deepseek就算是量化模型 令人意外的结果

• 内存 21821MiB

可能因为LongCite训练数据，已经自动构建CoT，很难有标准化输出。意外的是，同样内存消耗的deepeek-r1 4Q量化也能有惊人的表现。而且prompt也只是写了简单几条规则。
但类似第一条、第三条这种应该限定日期的，会当作为每天任务（思考链有时候还会否认明确日期），但之后用新的prompt基本解决了这个问题

1. 从给定的自然对话中提取时间信息，生成对应的5位Cron表达式（分 时 日 月 星期），并分析任务是否为一次性的, 然后以字典形式返回`Cron表达式`与`事项说明` `是否一次性`。
2. 生成的Cron表达式必须符合5位格式，时间解析必须准确，事项说明必须清晰，一次性必须为`True`或`False`。
3. 你需要明确知道时间（时和分）与日期（日期或星期）的信息。
4. 输出示例：
   1. `{"cron": "0 7 * * 1", "remind": "开会", , "ones": "False"}`
   2. `{"cron": "15 17 3 7 *", "remind": "买菜", , "ones": "True"}`
   3. `{"cron": "0 20 * * *", "remind": "运动", , "ones": "False"}`

其他model测试 （api）

测试免费的r1:7b，有一半的输出没有达到标准。 32b 和 14b 效果差不多，但17b 会think更多（将近 32b的两倍），两者的价格也是 2:1 左右。这样看来还是用 r1:32b 最好
在其他非推理模型测试，模型总会尝试写代码（估计过拟合了，怎么调prompt无效）。只有在gpt上，可以规范输出内容。 顺便一提，在调api使用全量 QwQ-32B 时，总会思考过度。价格更是32b的4倍，这效果真没人用啊

llm prompt 的一些看法

这种无需规范格式和明确参数的输入，确实很让人上瘾（测试中 xxx上午xxx 也能命中到 8 -9 点的范围）。
但也有明显的缺点：

1. 耗钱耗时，起码得14b模型才能得到较高的命中率，而且也不保证百分百准确，生成速度和表达式相比，差了太多。
2. 不可控、难以预测，就算温度拉最低、tok_p=1 都难以复现答案。这个任务中或许没什么影响，但在更复杂的需求下，这种不可控是致命的。