NLTK 文档所示例的“正则表达式”与来自同一文档的 CFG 在功能上是否存在任何实际差异？肯定应该有，因为存在不规则的上下文无关语言，但我找不到 CFG 方法胜过正则表达式的具体示例。
最佳答案
来自 RegexpParser 的文档:
The patterns of a clause are executed in order. An earlier pattern may introduce a chunk boundary that prevents a later pattern from executing. Sometimes an individual pattern will match on multiple, overlapping extents of the input. As with regular expression substitution more generally, the chunker will identify the first match possible, then continue looking for matches after this one has ended.
The clauses of a grammar are also executed in order. A cascaded chunk parser is one having more than one clause. The maximum depth of a parse tree created by this chunk parser is the same as the number of clauses in the grammar.
也就是说，每个子句/模式都执行一次。因此，一旦您需要将后面的子句的输出与前面的子句匹配时，您就会遇到麻烦。
一个实际的例子是，一些本身可以是一个完整句子的东西可以用作一个更大句子中的从句:
The cat purred.
He heard that the cat purred.
She saw that he heard that the cat purred.
正如我们可以从上面的文档中读到的那样，当您构建 RegexpParser 时，您正在为此类句子的“深度”设置任意限制。上下文无关语法没有“递归限制”。
文档提到您可以使用循环来稍微缓解这种情况——如果您对合适的语法运行两三四次，您可以获得更深入的解析。您可以添加外部逻辑多次循环您的语法，或者直到无法解析更多内容为止。
但是，正如文档还指出的那样，这个解析器的基本方法仍然是“贪心”的。对于固定或可变数量的步骤，它会像这样进行:
- 在一个步骤中尽可能多地进行分块。
- 将上一步的输出作为下一步的输入，重复。
这很天真，因为如果早期步骤出错，这将破坏整个解析。
想想“花园小径句子”:
The horse raced past the barn fell.
还有一个相似的字符串但是一个完全不同的句子:
The horse raced past the barn.
构建一个将解析这两个句子的 RegexpParser 可能很困难，因为该方法依赖于正确的初始分块。一个正确的初始分块对另一个可能是不正确的初始分块，但您无法知道“您在哪个句子中”，直到您处于解析逻辑的后期级别。
例如，如果“the barn fell”在早期被分块在一起，解析将失败。
您可以添加外部逻辑来回溯，当您以“糟糕”的解析结束时，看看您是否可以找到更好的解析。但是，我想您会发现，到那时，解析算法的更多重要部分都在您的外部逻辑中，而不是在 RegexpParser 中。
关于python - NLTK 正则表达式和 CFG，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/15768680/