大语言模型真能帮语法工程师写规则吗从粤语 ParGram 与英语基线对比实验说起如果你觉得语法工程离自己很远先想一个场景你正在做一个低资源语言的机器翻译或对话系统规则语法是最可靠的那条路但项目里没人写过 LFG 规则市面上也找不到现成的资源。这时候你会不会想直接问大语言模型帮我写一条粤语的动词短语规则这个问题看起来很简单答案却比很多人以为的更微妙。最近有一批研究者真的沿着这个方向做了严谨实验研究题目是“How Useful are LLMs for Grammar Engineering? Cantonese ParGram Resources and Controlled Experimental Evaluation with English Baselines”。一句话概括这项工作的核心判断LLM 能显著提升语法工程的生产效率特别是在测试用例生成和错误分析阶段但它没法直接替你写出一份可靠的语法规则。这篇文章会从“语法工程为什么难”讲起把 LFG、ParGram、粤语资源、受控实验设计、评估指标一次讲清楚。文末我会给出可以照抄的 LLM 辅助语法工程工作流和完整代码示例。无论你是做 NLP 的研究生还是做规则策略引擎的工程师这篇文章都能让你重新理解“规则 大模型”这件事的边界。1. 语法工程为什么难规则系统不是“写着玩”的东西语法工程的本质是用形式化规则描述一种语言里“什么是合法的句子”。这和普通人理解的“学语法”完全是两回事。普通人学语法是描述性的知道主谓宾、知道时态变化就够了但语法工程要求的是可执行的形式化描述规则系统必须对任意输入句子给出明确判定能解析还是不能解析。这就带来了三个核心痛点。第一覆盖度是个无底洞。自然语言的表达方式近乎无限每种句法结构、每种成分顺序、每个词的可选论元搭配都可能在某个真实句子里出现。手工写规则时你至少要保证常见句式全部覆盖这对一个 2000 条规则级别的语法系统来说维护成本极高。第二过生成与欠生成是天生矛盾。欠生成指的是语法拒绝了一批本来合法的句子过生成指的是语法接受了一批不合法的句子。调低约束条件欠生成减少但过生成增加调高约束条件反之。语法工程师的大量时间就是在平衡这两个指标。第三调试是黑盒体验。LFG 这类深度语法系统跑一次会输出 c-structure 和 f-structure 的完整推导当某条规则导致整体解析失败时你面对的可能是一大段晦涩的约束冲突日志。传统上语法工程师靠两种手段缓解这些痛点人工阅读语料库编写测试句子反复运行语法系统查看失败案例和约束冲突。这两件事有一个共同特点劳动密集、经验依赖强、且门槛极高。LLM 能切入的正是这两个环节。2. LFG 与 ParGram这篇文章的“语法工程”到底指什么要理解 LLM 在语法工程里的位置先要知道语法工程的主流形式体系之一——LFGLexical Functional Grammar词汇功能语法。LFG 的核心思想是分两层描述句子c-structure成分结构描述句子的表层句法构成形式是上下文无关语法树f-structure功能结构描述句子内部的语法功能关系形式是属性-值矩阵。f-structure 是关键——它不关心词序只关心“谁是主语、谁是宾语、一致关系是否成立”。举个例子“我吃苹果”和“苹果被我吃了”在 c-structure 上完全不同但 f-structure 会清楚地表示“吃”这个谓词的主语和宾语分别是什么。传统 LFG 语法开发时工程师要同时写两套规则一套 PSG 规则 phrase structure rules定义 c-structure一套词汇条目定义每个词在 f-structure 层面的功能注释。ParGramParallel Grammar项目是这个领域的国际协作平台之一。它由施乐帕洛阿尔托研究中心Xerox PARC等团队发起目标是开发一组基于 LFG 框架的平行语法资源覆盖多种语言。不同语言的语法在各自语言团队维护但共享形式化框架和底层工具链比如 XLE 解析器。粤语 ParGram 资源属于这个项目在汉藏语系方向上的一个分支。粤语有三个对语法工程尤其不友好的特点语序类型上是 SVO 但话题化现象频繁语气助词系统复杂且句法位置独特量词和动词补语结构使用规则与普通话有明显差异。这些特点导致“搬运”普通话语法资源并不现实必须单独建模。也正是因为资源薄弱、开发工作量巨大粤语 ParGram 天然适合作为“LLM 辅助语法工程的实验场”。3. LLM 在语法工程中的四个切入点不是替代是分流“LLM 能不能做语法工程”是一个伪命题。真正的问题是在语法工程这条流水线上哪些环节能够让 LLM 做哪些环节必须人工做结合粤语 ParGram 这批研究我把 LLM 的辅助价值总结为四个切入点。第一个切入点测试句子的自动生成。语法工程的一个基础实践是维护测试套件用来验证规则是否按预期工作。传统做法是从语料库中人工挑选句子或者凭经验人工杜撰句子。LLM 可以按规则自动生成大量满足特定句法约束的测试句。比如指定“生成 20 个粤语 V 得 C 补语句式”LLM 可以在几秒内给出候选。第二个切入点失败句子的错误分析。当语法系统无法解析一个句子时传统流程是工程师在 rule-based 日志里手动排查。LLM 可以读取解析日志和句子本身输出“很可能是这条规则的约束条件过强”之类的初步判断把工程师的定位时间缩短一大半。第三个切入点语法规则的草稿生成。注意这里的用词是“草稿”而不是“最终规则”。LLM 可以从语法注释段里推断规则模板但生成结果通常需要人工逐条校验。那些声称“让 LLM 直接写完整语法规则”的尝试在受控实验里往往过生成严重工程上不可直接落地。第四个切入点词典资源的半自动构建。语法工程大量工作其实是词汇层尤其是粤语这种缺乏现成电子词典资源的语言。LLM 可以根据上下文自动生成候选词条和基本的句法类别信息但词义细粒度区分和特殊搭配仍然需要人工核对。这四个切入点看似分散实则指向同一条逻辑语法工程的知识天花板仍然在语法工程师这边LLM 的价值是降低时间成本和操作门槛而不是提供可靠的知识来源。4. 受控实验设计为什么必须和“英语基线”对比讨论 LLM 辅助语法工程时最常见的错误做法是拿一组粤语句子让 LLM 生成规则然后直接说“LLM 效果不错”或“LLM 效果很差”。这种结论没有对照基本不具备科学价值。研究中反复强调“controlled experimental evaluation with English baselines”真正想说的是这个方法论的三个原则。原则一比较对象必须同类。英语语法资源成熟、训练语料海量LLM 在英语上的表现天然会优于粤语。用英语做基线不是为了证明“英语就是好”而是为了分离出“语言资源稀缺带来的影响”和“LLM 自身能力的影响”。没有英语基线你无法知道粤语结果差到底是因为 LLM 不会做语法工程还是因为粤语相关资料太少。原则二任务必须可控。语法工程能力不能靠一个笼统的“能不能用”来评估而要拆成互相独立的子任务。例如测试句生成任务、错误句诊断任务、规则补全任务、词条生成任务。每个任务都有明确定义输入输出统一评分口径结果才能横向对比。原则三评估必须有量化指标。语法工程场景下最经典的指标是覆盖率和过生成率。覆盖率 能被语法正确解析的测试句比例衡量“语法有没有漏掉合法句子”过生成率 语法错误接受的非合法句子比例衡量“语法是否过度宽泛”。LLM 辅助产出的质量最终都要落到这两个指标上。从方法论文本来看这套设计可以概括为把语法工程拆解成若干可量化的原子任务在同样任务上分别运行 LLM 和传统人工方案然后在英语和粤语两个语言资源条件下做交叉对比。5. 实验实现提示词设计、调用与评估脚本这一节给出可以照跑的完整流程。环境方面只需要 Python 3.9、一个可用的 LLM API任意主流大模型均可本文不绑定具体厂商和一个安装好 XLE 的 Linux 环境。版本细节以你实际使用为准本文重点演示通用思路。5.1 提示词模板让 LLM 生成测试句语法工程的测试句生成提示词不能是“帮我生成几个粤语句子”。必须是带约束、带格式要求的结构化提示词。# 文件路径prompts/test_sentence_generation.txt 你是一位粤语语法学助手。请根据指定的句法结构生成10个合法的粤语句子。 句法结构主语 动词 量词短语 补语 要求 1. 句子必须符合粤语口语的实际表达习惯。 2. 每个句子都必须包含一个使用正确句末语气助词的完整结构。 3. 每个句子用一行输出不要编号不要额外解释。 示例输出格式 我食紧一碗饭。设计这段提示词时有一个容易被忽略的技巧必须给示例输出格式few-shot。语法工程的下游工具比如 XLE 测试套件对输入格式非常敏感一行多出个编号都可能破坏流程。给示例LLM 的格式遵循率会大幅提升。5.2 批量调用与 JSON 结果落盘生产级使用不能只靠网页聊天窗口一条条问。下面用一个 Python 脚本批量调用 LLM 生成测试句并把结果按 JSON 落到磁盘供后续语法测试。# 文件路径scripts/generate_test_sentences.py import json import time from openai import OpenAI client OpenAI() # 请配置环境变量 OPENAI_API_KEY或使用你自建的兼容服务 SYSTEM_PROMPT 你是一名粤语语法工程师的助理输出严格遵循用户指定的格式。 def generate_test_sentences(structure_desc: str, num: int 10) - list[str]: user_prompt f请按以下句法结构生成 {num} 个合法的粤语句子 {structure_desc} 要求 1. 每个句子一行。 2. 句子之间不要空行。 3. 不要编号不要添加任何解释。 resp client.chat.completions.create( modelyour-llm-model, messages[ {role: system, content: SYSTEM_PROMPT}, {role: user, content: user_prompt}, ], temperature0.7, ) content resp.choices[0].message.content.strip() return [line.strip() for line in content.splitlines() if line.strip()] if __name__ __main__: structures [ 主语 动词 量词短语 补语, 动词谓语句 句末语气助词啊/啦/咩, 话题化结构话题 主语 谓语, 连动句动词1 动词2共同主语, ] output {} for idx, structure in enumerate(structures, start1): print(f正在生成第 {idx} 组{structure}) output[fstructure_{idx}] { description: structure, sentences: generate_test_sentences(structure), } time.sleep(1) # 控制请求频率避免触发限流 with open(test_sentences.json, w, encodingutf-8) as f: json.dump(output, f, ensure_asciiFalse, indent2) print(生成完成结果已保存到 test_sentences.json)这个脚本的核心是批量化和结构化。真实语法工程中你会需要上百组句式测试手工逐条问 LLM 不现实。用脚本自动化另一个直接好处是可复现——同一条提示词、同一批句式任何人在任何时间跑出来的结果可以放进项目仓库做回归测试。5.3 用 XLE 批量解析测试句从生成到验证生成的句子不能直接算数必须过一遍 LFG 语法解析器。XLE 的交互模式不适合批量测试正确姿势是写一个包装脚本逐条调用 xle并解析返回结果。# 文件路径scripts/parse_test_sentences.sh #!/bin/bash # 用法bash parse_test_sentences.sh test_sentences.json grammar.lfg # 说明逐条读取JSON中的句子调用XLE解析将解析结果追加到解析日志。 INPUT_JSON$1 GRAMMAR$2 LOG_FILEparse_log.txt $LOG_FILE # 使用 python 读取 JSON 中的句子逐条送入 xle 解析 python3 - $INPUT_JSON $GRAMMAR $LOG_FILE PY import json import subprocess import sys input_json, grammar, log_file sys.argv[1], sys.argv[2], sys.argv[3] with open(input_json, encodingutf-8) as f: data json.load(f) sentences [] for key, item in data.items(): sentences.extend(item[sentences]) with open(log_file, a, encodingutf-8) as log: for sid, sent in enumerate(sentences): # 这里以最简单的命令行调用为例实际接入根据你安装的XLE版本调整 result subprocess.run( [xle, -f, grammar, -e, fparse {sent}], capture_outputTrue, textTrue, timeout30, ) success No violations in result.stdout or Solutions: in result.stdout log.write(f{sid}\t{success}\t{sent}\n) print(f{sid}: {OK if success else FAIL} - {sent}) PY echo 解析完成结果请查看 $LOG_FILE这段脚本的关键是sid\t成功与否\t句子的日志格式。后续的覆盖率计算、错误分析、失败句子分类全都依赖这个结构化的日志文件。5.4 覆盖率与过生成率评估脚本语法工程效果评估指标必须算清楚。覆盖率计算相对直接统计有多少测试句子被解析器接受过生成率则需要一组“非法句子”作为负样例然后看语法错误接受了多少。# 文件路径scripts/evaluate_grammar.py import json # 读取解析日志 def load_parse_result(log_path: str) - dict[int, bool]: result {} with open(log_path, encodingutf-8) as f: for line in f: parts line.strip().split(\t) if len(parts) 3: continue sid, success, sent int(parts[0]), parts[1] True, parts[2] result[sid] success return result # 读取负样例非法句子 def load_negative_samples(path: str) - list[str]: with open(path, encodingutf-8) as f: return [line.strip() for line in f if line.strip()] def calculate_metrics(positive_result: dict[int, bool], negative_result: dict[int, bool]): total_positive len(positive_result) accepted_positive sum(1 for v in positive_result.values() if v) coverage accepted_positive / total_positive if total_positive else 0.0 total_negative len(negative_result) accepted_negative sum(1 for v in negative_result.values() if v) overgeneration accepted_negative / total_negative if total_negative else 0.0 return coverage, overgeneration if __name__ __main__: pos load_parse_result(parse_log.txt) neg load_parse_result(negative_parse_log.txt) coverage, overgeneration calculate_metrics(pos, neg) print(f覆盖率: {coverage:.1%}) print(f过生成率: {overgeneration:.1%})这里的过生成率是简化口径。更严格的做法是对每个被错误接受的句子做人工复核确认它确实是非法句子再进入分母。但即使简化口径脚本跑出来的趋势已经足够指导语法调试方向覆盖率低先补规则过生成率高先收紧约束。6. 结果分析粤语资源稀缺对 LLM 表现的影响有多大在分析结果之前先给读者一个预期管理受控实验的具体数字依赖语法资源版本、LLM 型号、提示词风格等多个变量不能跨实验直接搬运。以下是基于该研究方法论可以做出的合理判断用于理解实验结论的走向。从方法论推理看英语基线和粤语实验会呈现三个层次的差异。第一层测试句生成质量差异明显。英语测试句生成任务里LLM 生成结果基本可以直接进入测试套件粤语测试句生成任务里LLM 通常会生成一些“看起来像粤语、实际上混合了书面语或普通话结构”的句子。原因不是 LLM 的能力退化而是训练语料中粤语口语语料占比远低于英语和普通话。粤语书面语和口语的差异比普通话更大LLM 容易把“粤语”泛化成“广东话版本的标准中文”。第二层规则补全类任务LLM 在英语上可行但在粤语上不能直接用。英语资源成熟LLM 见过大量英语语法标注数据生成的规则草稿往往结构完整粤语资源稀缺LLM 会“参考”普通话或英语的规则模式去补全粤语规则结果可能在 f-structure 层面上出现粤语特有的错误例如量词短语的功能注释被错误地当成形容词短语处理。第三层错误诊断任务上LLM 对两种语言都能提供有效辅助。这其实是这项研究最重要也最被低估的发现之一。错误诊断依赖的不是语言本身的语法知识而是对“解析失败模式”的理解。XLE 的日志格式、特征冲突类型、约束传播机制在不同语言间是共通的LLM 在调试建议上表现出跨语言的可迁移性。从这些推理可以得出一个结论LLM 对语法工程的辅助价值在工具链理解层面是跨语言通用的在语言知识层面高度依赖训练语料覆盖度。这也是为什么要做所谓 English baselines——它让你能区分“LLM 不擅长语法工程”和“LLM 擅长语法工程但不熟悉粤语”这两种完全不同的结论。7. 常见误区与排查方法语法工程师最容易踩的坑以下问题来自真实语法工程实践中高频出现的场景按现象、原因、排查方式和解决方案整理。问题现象可能原因排查方式解决方案LLM 生成句子包含大量普通话书面语粤语训练语料占比过低对比粤语母语者人工纠错结果提示词中额外加入“必须为口语粤语”约束同时提供口语特征词示例“食”“咗”“紧”等LLM 生成的 LFG 规则过生成严重提示词只给了规则骨架没有约束细节对 LLM 生成的规则跑负样例测试在提示词中增加 f-structure 约束描述例如“要求主语和谓语的数特征一致”批量调用被限流没有控制请求频率查看 LLM API 返回状态码在脚本中加入 sleep 或指数退避重试XLE 解析日志为空句子没有被正确地发送给解析器检查 XLE 命令行调用语法先用人工交互模式验证单条解析再改脚本批量调用覆盖率指标为 0语法文件路径错误或测试套件格式错误查看 XLE 启动日志确认语法文件能单独解析并检查测试句是否包含非法字符LLM 诊断结论与 XLE 日志不一致LLM 没有看到完整解析上下文把前序多条规则的输出一起放入提示词在提示词中提供“解析过程 冲突信息 失败句子”三段上下文这里有一个值得强调的工程判断LLM 提示词中的约束数量和生成质量并不是简单线性关系。在语法工程这类高专业度任务里给出一个清晰的结构化任务描述和示例效果优于一次性罗列十多个细碎规则。8. 最佳实践把 LLM 接入语法工程的可靠工作流语法工程团队若要认真引入 LLM我建议按下面这个流程组织开发第一步先把语法测试套件建起来。不要一上来就让 LLM 写规则或生成语料。先把已有的合法/非法句子固化成测试套件作为一切后续评估的基准线。这个测试套件是客观标尺没有它LLM 的任何表现都无法度量。第二步用 LLM 生成增量测试句而不是一次性生成全部句子。每写完一批规则用 LLM 生成对应句式的测试句扩充测试套件。这些句子是否合法必须由人工复核不能用 LLM 自问自答。第三步让 LLM 分析失败案例但保持人工决策权。解析失败的句子交给 LLM 时要同时提供解析日志和失败上下文让 LLM 给出修改建议最后语法工程师决定是否采纳。这个环节中LLM 真正贡献的是把“逐条人工看日志”变成“只看 LLM 高置信度的建议”。第四步对 LLM 生成结果做版本管理。每次实验的提示词、生成的句子、LLM 模型、温度参数都应固化为配置文件。语法工程的回归测试周期通常较长没有完整的版本记录一次规则改动导致测试套件里哪些句子失败会变得无法追溯。# 文件路径config/llm_grammar_task.yaml task_name: cantonese_psg_rule_draft llm: model: your-llm-model temperature: 0.3 max_tokens: 1024 prompt_template: prompts/psg_rule_draft.txt input: structure_desc: 粤语连动句两个动词短语共享同一主语 requirements: - 必须包含 f-structure 注释 - 动词1 和 动词2 必须具有相同的主语 output: format: text validated_by: grammar_engineer第五步联合评测而不是单点评测。LLM 辅助引入的测试句必须和人工编写的测试句放在一起跑覆盖率与过生成率。注意观察一个关键指标LLM 增加的句子是不是大量集中在少数句式上。如果出现这种情况恭喜你说明测试套件存在明显偏斜。还有一个容易忽略的工程问题安全与授权边界。如果你的语法资源或语料包含内部数据不要直接丢给外部 LLM API优先考虑自部署或在符合数据合规要求的环境内调用。语法资源往往是团队多年积累的资产不是随意的公开文本。9. 结论LLM 是语法工程师的加速器不是替代品回到开头那个问题“让 LLM 写一条粤语的动词短语规则靠谱吗”现在可以给出一个更成熟的答案直接让 LLM 写规则不靠谱但让 LLM 生成测试句、辅助错误诊断、提供规则草稿再配上语法工程师的人工校验整个开发效率可以大幅提升。真正稀缺的仍然是语法工程师的判断力——知道什么句子合法、什么特征约束必须保留、为什么某条规则会导致过生成。从这项粤语 ParGram 与英语基线的研究里留给语法工程社区最重要的方法论点有三条第一条评估任何 LLM 辅助方案必须设置基线。语言资源丰富程度差异太大没有基线就无法判断结果差异的根源。第二条任务拆解是 LLM 落地的关键。语法工程整体不可自动化但拆成测试句生成、错误诊断、规则补全等子任务后LLM 可以在部分子任务上达到可用水平。第三条可信的语法资源建设仍然需要语言学和工程学双重能力。LLM 降低了入门门槛但最终决定语法系统质量的还是规则体系本身的架构设计。如果你正在考虑把 LLM 引入语法工程团队建议从一个小句式集开始先建测试套件再试 LLM 生成测试句最后再尝试规则草稿生成。用两到三周拿到第一轮评估数据你会比自己想象中更快得出结论你的语言资源、你的语法架构、你的团队流程到底适不适合走 LLM 辅助这条路。