LLM 在语法工程里到底有没有用尤其是像粤语这种资源少、正字和口语边界模糊、语法现象和标准中文不完全一样的语言答案不是一句话能说清的。最近我在梳理 ParGram 相关资源时看到一种做法把 LLM 当作语法工程师的辅助工具先在英语基线任务上做受控实验再迁移到粤语资源构建里。这个思路最大的价值不是证明“LLM 能写语法”而是把“有用”拆成了可以量化的子任务。这篇内容我就把这个思路翻译成可执行的工程流程重点讲清楚语法工程到底在做什么、LLM 能切入哪些环节、受控实验怎么设计、粤语评价为什么容易踩坑。1. 语法工程不是让 LLM 直接写语法而是让语法工程师少做重复判断1.1 语法工程和 ParGram 到底在做什么“语法工程”听起来像纯理论实际上是非常具体的开发工作。你要写词条、写句法规则、配特征结构再用真实句子去跑语法分析器看到输出树、特征结构或逻辑形式出错再回头改规则。和普通软件工程相比它的调试对象不是函数而是语法约束。比如某条规则允许动词后直接接名词短语但粤语里“佢食完飯”这种结构可能还涉及体貌标记的位置。开发效率很大程度上取决于两件事词法覆盖和测试套件质量。ParGram 项目做的就是多语言平行语法工程底层采用 LFG词汇功能语法框架。不同语言的语法规则共享同一套形式化基础但保留各自的语言特点。在这个框架里粤语不是标准汉语的附属品而是一个独立的语法对象需要单独处理语序、量词、助词和句末成分。传统语法工程非常依赖人的精确判断。一条规则加进去可能要连带改几十条测试句。LLM 的问题在于它输出的是概率文本不是可保证一致性的形式化代码。所以真正值得讨论的不是“能不能让 LLM 自动完成语法工程”而是“什么环节适合交给 LLM 做候选生成再由人来确认”。1.2 为什么粤语语法资源适合做实验很多人以为给 LLM 一段粤语对话它就会“自动懂粤语”。真实做语法工程时不是这样。粤语语料在互联网上不算少但结构化资源很少词性标注、依存树库、带完整特征信息的测试句都远不如英语丰富。而且粤语书面语存在大量变体同一个句末助词可能有不同汉字写法。开发粤语 ParGram 资源时你甚至要先决定用哪套正字、哪种粤拼、词类体系怎么设计。这种环境很适合评估 LLM。理由有两个第一LLM 训练语料里包含大量粤语文本能生成很自然的粤语句子表面看“很懂”。第二一旦把它放到形式语法任务里它缺少的恰恰是结构化能力词类边界、特征一致、规则约束、测试句覆盖范围。因此粤语能暴露 LLM 对低资源语言形式化建模的真实水平。再和英语基线放在一起就能看到哪些问题来自资源不足哪些来自语法工程本身的复杂度哪些来自模型能力上限。1.3 LLM 能切入的三类位置我一般不建议让 LLM 直接从零写一个完整语法而是只做三件事。第一词法条目候选生成。给一个粤语句子给定词类体系让 LLM 输出可能的词条和特征。这个任务有明确输入输出人可以快速校验错了也不影响全局。第二测试套件扩展。从已有测试句出发让 LLM 生成否定、疑问、时体变化、句末助词替换等变体。语法工程非常需要批量测试句靠人手工构造很慢。第三错误解释。当语法分析器解析失败时把输入句子和解析轨迹丢给 LLM让它列出最可疑的规则位置。语法调试是最耗时的环节LLM 能做一个粗筛。这三个位置有一个共同点都存在可校验的参考标准。词条对不对看词类体系和句子上下文测试句合不合法看语法分析器和人错误解释准不准看它是否命中了真实规则。只要人能兜底LLM 犯错的影响就可控。2. 把“LLM 有没有用”转成可评估的子任务2.1 子任务设计原则评估之前先定义任务否则指标没有意义。我在做实验前会把“LLM 对语法工程有没有用”拆成几个单点任务每个任务必须满足四个原则。单点一次只做一件事。不要问“帮我写一条粤语语法”而是问“给这句话补充词法条目”。任务越小输出越容易判断。可验证每个输出都能被人或现有工具校验。比如词法条目可以用当前词表对比测试句可以交给 parser 试跑错误解释可以对照规则文件。可修改输出不能是一大段文本而应该是一种易编辑的格式。比如词条每行一个测试句每行一个错误解释按规则行号输出。这样人工修改成本低。可重复同一提示在相同参数下多次运行结果应该大体稳定。如果同一个任务跑五次五次差异巨大那说明任务定义还不够清晰。遵循这四个原则后续打分才不会变成“感觉它好像有用”。2.2 词法条目生成和测试句生成以粤语句子“佢食完飯喇”为例如果要补齐 Lexical-Functional Grammar 词法条目不能只把整句翻译成“他吃完饭了”。语法工程师关心的是“完”和“喇”分别是什么词类、带什么特征、约束什么成分。提示词最少要包含可用词类、输出格式、一个示例、当前句子。否则模型会自己发明词类体系。角色粤语语法工程师 任务为下列粤语句子生成 LFG 词法条目候选 可用词类名詞、動詞、量詞、助詞、句末助詞、代詞、語氣詞 输出格式漢字|粵拼|詞類|特征 示例 佢|keoi5|代詞|人稱3 數單 句子佢食完飯喇 输出这种任务看起来简单但很容易跑偏。模型可能把“飯”标成“動詞”也可能把“喇”标成“語气詞”之外的自造词类。所以要在提示里锁死词类编号并且在输出说明里强调只能使用给定词类。测试句生成任务的方向不一样。假设你已经有一条句子“佢食完飯”想覆盖更多测试点可以让 LLM 生成否定、疑问、加体貌标记等变体。这里最关键的是约束不能改变核心论元结构。将下面句子改写为否定句、疑问句、加句末助词“咩”的疑问句。 要求保留原句的核心论元结构不要增加额外事件。 原句佢食完飯。如果约束不写清楚模型可能生成“佢食完飯就去瞓”这种增加后续事件的句子。测试套件里出现这种句子会污染结果让你分不清是规则问题还是句子本身超出了测试范围。2.3 规则调试和错误解释语法工程最花时间的不是写规则而是调试解析失败。一个大型语法仓库里有成百上千条规则解析一条句子可能产生很长的约束冲突记录。人工逐行看效率很低。LLM 可以做的是把输入句子、解析轨迹和局部规则文件一起放进上下文让它输出最可能导致失败的三条规则。这里有个关键一定要把相关规则片段贴进去。规则名字符串本身没有语义模型没看过文件内容就只能猜自然会胡说八道。我一般会这样设计提示下面是一段粤语语法分析器的失败轨迹。 轨迹中提到的规则都在文件片段中给出。 请找出最可能导致失败的三条规则按可能性从高到低排列。 每条输出格式规则名|失败原因|建议检查方向 注意只能使用文件片段中实际出现的规则名。加了“只能使用文件片段中实际出现的规则名”之后幻觉率会明显下降。因为模型不再需要从自己的记忆里编造规则名而是从给定文本里选择。错误解释任务能不能自动化评估可以。用人工判断它是否命中了真正的根因或者再用一个小型测试集看按它的建议修改后解析是否成功。如果按它的建议改了之后测试句还是失败那这条结果就应该标记为“未命中”。3. 英语基线不是“对照组”而是“测量尺”3.1 为什么必须和英语放在一起测很多人做低资源语言评估时只测目标语言。得分高就说明 LLM 有用得分低就说明没用。问题是你没有一个参照点根本不知道这个分数是高还是低。英语是一种很好的参照。英语语法资源成熟LLM 训练语料充足提示词在英语里更容易被理解。如果同一个任务逻辑下英语基线可采纳率是 70%粤语是 50%那么差的 20 个百分点可以归因到语言资源、模型语言能力、测试集难度等因素。但还有一种情况英语基线也只有 30%。这就说明问题出在任务设计或提示结构而不是语言本身。此时你去换更强的粤语模型大概率也救不回来应该先回看子任务是不是定义得太模糊。英语基线的作用不是“证明 LLM 在英语上厉害”而是给粤语结果一个解释坐标。没有这个坐标任何数字都是孤立的。3.2 受控实验里要控制哪些变量受控实验里的“受控”不是指把 LLM 关在封闭环境里跑而是指模型、提示、采样参数、测试集、评估标准尽量保持一致。这样才能把差异归因到语言或任务上。需要控制的变量包括变量控制方式原因模型版本固定同一个模型版本不同版本能力差异大不能混着比较采样温度固定比如 0.2温度高随机性大会影响指标稳定性提示结构同一套角色、任务、输出格式防止把提示工程差异误当成语言差异测试集平行设计同一类语法现象英语和粤语句子不是随便挑要覆盖同类结构重复次数每个样本至少跑 3 到 5 次单次输出随机性高不能代表能力上下文截断策略记录规则文件截断位置不同上下文长度会影响模型判断有一点要注意并不是要让英语和粤语提示完全逐字一致。粤语提示可能需要本地化比如使用粤语解释词类这时要记录你做了哪些改写。受控实验的目标是“差异有记录变量有边界”不是机械地追求字符串一致。3.3 怎么打分可采纳率、修改率、幻觉率评估 LLM 输出不能只看“它说得对不对”。因为语法工程的产出不是判断题而是可编辑的候选材料。我建议记录四类指标。指标计算方式说明可采纳率无需修改可直接使用的输出数 / 总输出数衡量输出质量的第一印象修改率经过少量修改后能使用的输出数 / 总输出数衡量辅助成本幻觉率引用了不存在的规则、词类或词条的输出数 / 总输出数衡量可靠性解析通过率生成内容跑过语法分析器后成功解析的比例最客观的工程指标人工评分时至少要有一个人熟悉 LFG 或类似形式语法框架。另一个人可以负责数据整理但不应该让完全不懂语法的人去判断“可采纳”否则很容易把“读起来通顺”当成“语法正确”。如果条件允许我还建议记录“修改所需步数”。比如一个输出需要修改 3 处还是 10 处这直接决定辅助效率。不过这个指标成本较高小规模实验可以不做规模化之后再考虑。4. 粤语场景下最容易误判的三个点4.1 “粤语感”不等于语法代码正确LLM 能生成“佢食完飯喇”这种自然句子会让人误以为它已经理解粤语语法。但在语法工程里问题不是这句话是否通顺而是“完”和“喇”分别属于哪个词类、有什么约束、和前后成分什么关系。一个常见的例子是句末助词“喇”。它可以表示完成、变化、语气但在词法条目里必须被明确标注成句末助词并设置必要的句法约束。模型可能凭语感知道这里该有助词却把“喇”标成“連接詞”或自造词类。所以判断标准必须以语法分析器输出为准不能只看文本自然度。LLM 的语言直觉只是素材不是语法定义。人工审核时要重点检查词类归属、特征一致性和规则文件中的实际约束。4.2 输出不稳定会污染实验结论我第一次做类似实验时每个任务只跑了一次结果很漂亮。后来改成每个样本跑五次发现词性标注每次都不一样。不是模型坏了而是提示里缺少约束条件。输出不稳定的影响不只是分数波动还会让后续的人工修复成本大幅上升。比如同一个句子第一次生成的“飯”是“名詞”第二次生成的是“動詞”你无法判断哪一次可信只能手工再查词表。解决顺序是先压制输出格式在提示里给出严格的词类列表和示例。再固定温度建议 0.2 或更低。如果仍然不稳定回到任务定义看看是不是任务本身有歧义。记录多轮输出也很重要。可以写一个简单的循环把每次结果保存成独立文件for run in range(5): result generate(prompt, temperature0.2) save(f{task}-{sample}-run{run}.txt, result)这样做之后不仅能看到最终指标还能回看哪一类样本最容易漂移。样本级漂移率过高的任务应该从实验里单独标出来不能混进平均值。4.3 遇到幻觉先看任务设计而不是换模型有次我让 LLM 分析解析轨迹它很认真地给出了一个不存在的规则名。我的第一反应是模型不行后来发现是提示里根本没有提供规则文件内容。模型没有上下文只能靠训练记忆猜测就很容易编造。现在再遇到幻觉我不会急着换模型而是按顺序检查三件事。先看提示里有没有提供足够材料。如果规则名、词类、文件路径都没有出现模型必然会猜。这时应该把相关文档片段或规则文件片段放入上下文。再看输出格式是否锁死了范围。如果提示写的是“列出可能的规则”模型就会自由发挥。改成“只能从以下规则中选择规则A、规则B、规则C”幻觉会低很多。最后才考虑模型能力问题。如果材料都给了格式也约束了它仍然频繁引用不存在的规则那可能是模型对特定任务的理解不足再考虑换模型不要一开始就在模型选型上纠结。5. 更务实的落地顺序从小规模测试集开始5.1 最小实验模板如果你想在自己的粤语语法项目里验证 LLM 有没有用不必一开始就做很大的数据规模。我建议按下面的最小实验模板走。选一个小语法现象。比如“完成体标记‘完’位于动词后句末助词‘喇’出现时表示变化”。这个范围足够小又足够体现粤语特色。然后准备测试集。20 条粤语测试句再配 20 条英语平行测试句。英语句子不必逐字对应但必须覆盖同类的语法现象。比如英语里没有句末助词你可以用完成时态或语气词来构造对照。接着写三个子任务提示词法条目生成、测试句生成、错误解释。每个任务跑五次固定温度保存每一轮输出。最后让熟悉形式语法的人按可采纳率、修改率、幻觉率打分再用语法分析器跑一遍解析通过率。整个过程不依赖高价 GPU只要能用模型 API 或本地模型就行。小规模跑完你已经能看出这个方向值不值得继续。5.2 哪些环节可以放心交给 LLM哪些不要根据我自己的实践下面这几个环节可以放心一些。可以交给 LLM 的词法条目候选生成。让人工审核后合入。已有句子的句式变换。只作为测试套件候选不直接当标准。解析失败后的规则定位提示。只作为排查方向不直接改规则。将一些口语化粤语改写为规范化书面粤语。方便建立测试样本。不建议交给 LLM 的自动把输出合入语法仓库。语法仓库是长期资产必须经过人工 review 和回归测试。把 LLM 生成的例句当成标注黄金标准。它生成的句子可能合法也可能只是“听起来像粤语”。让 LLM 自行决定词类体系。词类体系是语法工程的骨架不能由文本概率决定。把单次成功当成功能稳定。必须有多轮重复和异常记录。边界其实很清楚LLM 负责提出候选人类负责决策。一旦让 LLM 直接主导决策错误会被悄悄写进语法仓库后面排查成本会翻几倍。5.3 后续可以扩展的方向如果最小实验模板跑通你可以继续扩展。第一构建一个“粤语语法工程评测集”。按词类、句式、助词、句末语气成分分类长期维护。每次调规则、换模型、改提示都可以在评测集上重跑避免回归。第二引入检索增强。把现有规则文件、词表、测试套件提前切分成片段生成时先检索相关片段再给 LLM。这能显著降低幻觉也会让输出更接近当前仓库的真实状态。第三用 git 管理所有 prompt、输出和评分结果。提示词只要改一行就要记录下来方便回看“这次效果变化到底是模型的功劳还是提示里多了一个示例”。第四如果后续要扩展到其他低资源语言保留英语基线会非常有用。模型版本更新后旧结果可能被推翻但只要基线流程固定重新跑一遍就能知道新模型对语法工程任务的通用影响。我自己比较推荐的做法是把“LLM 辅助语法工程”当成一条长期维护的流水线而不是一次性测试。流水线里最重要的不是单个模型有多强而是任务定义、测试集、评分标准、版本记录这套基础设施是否稳定。基础设施稳了模型换多少次都能快速得出结论。真正做下来之后我的感受是LLM 对语法工程确实有用但用处是提高语法工程师的效率不是替代语法工程师。把任务拆小用英语基线校准再用人工和语法分析器双重校验这套流程比单纯追求某个高分更可靠。很多问题看起来像模型能力问题实际是提示里没给够上下文、输出格式没锁死、重复次数不够。如果你也要做类似评测建议从最小样例开始先把这三个问题回答好再谈自动化合入语法仓库。