Harper项目中的数字与句号解析问题分析与解决方案

在自然语言处理工具Harper中，存在一个有趣的文本解析边界问题：当段落中出现以数字加句号结尾的句子时（如"1."），系统会错误地将其识别为单个长句子而非多个独立句子。这个问题看似简单，却揭示了文本解析中数字处理和句子分割的深层次技术挑战。

问题现象

典型场景出现在技术文档中，当用户编写包含编号列表的段落时：

1. 这是第一句话。2. 这是第二句话。3. 这是第三句话。

Harper会错误地将整个段落标记为"可读性问题"，认为这是一个超过50个单词的长句子，而实际上它包含三个独立句子。

技术根源分析

通过代码审查发现，问题源自Harper核心模块的两个关键设计：

1. 词法分析器(lexer)的数字处理逻辑
   在lex_number函数中，系统采用渐进式解析策略：不断尝试将文本切片解析为浮点数，直到成功为止。这种设计虽然能处理各种数字格式，但会将"1."这样的文本整体识别为TokenKind::Number，将句号吸收为数字的一部分。

2. 句子终止符判断机制
   is_sentence_terminator函数目前仅对明确的标点符号（句号、问号、感叹号）和段落分隔符返回true。由于"1."被整体识别为数字token，无法触发句子分割条件。

影响范围

这种解析问题主要影响：

• 技术文档中的编号列表
• 包含年份的句子结尾（如"事件发生在2023."）
• 任何以数字结尾的句子结构

解决方案探讨

方案一：修改数字解析逻辑

在lex_number函数中增加特殊处理：当解析到的数字以小数点结尾且没有小数部分时（如"1."），将其拆分为数字token和句号token。这需要：

1. 在Number结构体中添加has_decimal_point标志
2. 修改解析逻辑以识别纯整数带小数点的情况

方案二：增强句子终止判断

扩展is_sentence_terminator的功能，使其能够识别数字token中的终止性句号。这需要：

1. 分析数字token的原始文本表示
2. 对特定格式的数字（如以点结束的整数）特殊处理

技术权衡

方案一更符合语言处理的理论模型，将词法分析和句法分析明确分离，但实现复杂度较高。方案二实现简单但可能引入其他边界问题。从系统设计角度看，方案一更具长期可维护性。

延伸思考

这个问题反映了自然语言处理中的普遍挑战：

1. 歧义处理：同一个字符（如句号）在不同上下文中的多重含义
2. 领域特异性：技术文档与普通文本的解析需求差异
3. 错误恢复：当自动解析失败时的人性化处理机制

对于开发者而言，这类问题的解决不仅需要代码修改，更需要建立完善的测试用例集，覆盖各种数字与标点组合场景，确保解析器的鲁棒性。

结语

Harper项目中的这个案例生动展示了文本解析系统开发中的典型挑战。通过深入分析其词法分析和句子分割的交互过程，我们不仅找到了具体问题的解决方案，更提炼出了处理类似边界条件的方法论。这种问题驱动的技术剖析，对于开发高质量的文本处理工具具有普遍参考价值。