大模型能生成流畅的自然语言也能完成不少语法层面的纠错任务但回到“语法工程”这个领域情况要复杂得多。语法工程不是让模型输出一段通顺的文本而是要把一门语言的词类、语序、论元结构、形态变化和功能关系写成一套可执行、可测试、可复用的形式规则。以粤语 ParGram 资源建设为例最近的工作把问题推进得非常具体LLM 到底能在语法工程里承担多少工作生成出来的词条、句子和规则解释能不能直接进资源库过去一年里很多团队尝试用大模型自动构建语料、自动标注、自动生成规则但真正产出可靠语法库的并不多。原因在于语法工程对精确性的要求极高而 LLM 的输出天然带有概率性没法保证每次都在同一个逻辑体系内自洽。与其问“LLM 能不能做语法工程”不如问“LLM 能在哪个环节、以什么方式、在什么样的评估标准下帮上忙”。粤语 ParGram 资源建设正好是一个不错的测试场因为它语法现象丰富、数据资源稀缺又有相对成熟的英语语法基线可以对照。这篇文章想围绕“可控实验评估 英语基线”这条主线展开。我会先解释语法工程和 ParGram 的基础再谈粤语语法资源建设的难点然后分析 LLM 可以切入的环节最后给出一个受控实验评估的完整思路并配上可复用的代码示例。读完你会得到一个更实际的判断LLM 不是语法工程师的替代品但足够好的工作流确实能把语法资源建设的门槛拉低一大截。1. 为什么语法工程需要重新被审视1.1 传统语法工程的现实痛点传统语法工程指的并不是“写一些正则表达式去匹配句子”而是构建能覆盖一门语言核心句法现象的形式化语法系统。以 LFG词汇功能语法为例语法工程师要维护词汇条目、形态规则、短语结构规则和功能约束最终让计算机能够解析一个句子并输出其功能结构f-structure和构成结构c-structure。这套过程非常依赖语言学专家的判断也需要大量的语料验证。最大的痛点是成本。一个中型语法的词条量动辄上万规则数量也可能达到几百条每新增一种语言现象就要修改规则、补测试用例、跑回归再检查是否破坏了已有分析。这个过程既费时又容易出错而且高度依赖个人经验。如果团队里没有资深计算语言学家项目几乎寸步难行。更麻烦的是很多语言和方言并没有足够的电子词典、树库或平行语料。粤语就是一个典型例子。主流搜索引擎和预训练模型里包含的粤语文本远少于普通话和英语传统机器学习方法需要的数据规模根本凑不齐而人工从零构建语法资源又太慢。于是大家自然会想到能不能让 LLM 来补足一部分资源建设工作1.2 LLM 解决了一部分问题但没有解决全部问题LLM 对语法工程最有价值的不是“生成一篇语法论文”而是它在很多局部任务上表现得相当好。比如给定一个粤语句子它可以给出几种合法变体给一个词条它可以补充搭配和论元结构给一段规则它可以生成自然语言解释。这些能力在语法资源建设的初期非常有帮助因为我们需要大量候选内容供专家筛选。但问题也随之而来。LLM 的回答风格不稳定同一个问题换一种问法就可能得到不同的结果。它还会一本正经地生成语法上根本不存在的表达尤其对粤语这种书面资源较少、口语变化丰富的语言幻觉问题会更明显。如果直接把模型输出写入语法库很容易造成规则内部矛盾后期排查成本反而更高。所以关键并不是“LLM 能不能生成语法资源”而是“如何设计一套流程让 LLM 的产出可控、可验证、可追溯”。这正是受控实验评估要解决的问题。我们先把 LLM 当作候选生成器再用人工评价和英语基线对照来衡量其真实效果最后决定哪些产出可以入库。2. 从 ParGram 到粤语形式语法资源的基本盘2.1 ParGram 与 LFG 框架ParGramParallel Grammar是一个多语言语法开发项目核心思路是在 LFG 框架下用统一的语法描述体系来开发不同语言的语法资源。LFG 的全称是 Lexical Functional Grammar它把句子的信息分成至少两个层次构成结构表示短语结构的线性组织功能结构表示主语、宾语、时态、格等语法功能。这种两层表示对跨语言语法对比非常友好。英语、汉语、粤语的语序差异很大但在功能结构层面很多句法关系可以统一建模。比如英语的 “I ate rice” 和粤语的 “我食咗饭”构成结构很不一样但在功能结构上都有主语和宾语。工程实践上ParGram 依赖一些成熟的工具链比如用 Lexc 编写词法、用 XFST 做形态分析、用 XLE 解析句子并生成功能结构。这些工具的特点是对输入格式要求严格一个小错误就可能导致整个语法无法加载。这也是 LLM 难以直接生成“可运行语法”的原因之一它不理解编译器的内部约束也不容易生成满足工具严格格式的完整代码。2.2 粤语作为语法工程对象难在哪里粤语是汉语族中非常重要的一支但它不是标准书面普通话。它有自己的口语表达体系很多句子结构在普通话里不成立或者语序不同。比如完成体标记“咗”放在动词后双宾结构里常把“直接宾语”放在前面说“畀本书我”而不说“给我一本书”还有极其丰富的句末语气词用来表达疑问、确认、感叹、不满等语气功能。这些现象给语法工程带来了具体困难。第一粤语没有绝对统一的书写标准同一个词可能写成不同汉字给词条合并带来干扰。第二口语色彩强很多表达高度依赖语境脱离语料就很难判断一个句子是否合法。第三句末语气词数量多、组合方式复杂需要专门的规则和特征体系来处理不是简单加几个词条就能覆盖。从资源建设的角度看粤语 ParGram 还处于早期阶段。已有的英文语法资源比较成熟但粤语语法资源往往需要从零搭建光是把基础词类和常见句型撑起来就需要大量人工投入。正因如此像“LLM 对语法工程有多大用”这类问题在粤语场景下尤其值得研究因为一旦实验设计不严谨很容易把“LLM 能力不足”和“粤语资源稀缺”混为一谈。2.3 为什么英语基线能帮上忙英语在 ParGram 项目中已经有多年的积累语法类型、测试语料、评测指标相对完整。用英语做基线意义在于提供一个“参考刻度”。如果 LLM 在英语场景下生成的词条和规则建议也是七零八落说明问题大概率出在方法本身如果 LLM 在英语场景表现不错、在粤语场景却下滑明显那就可以把问题归因到语种资源覆盖度、提示词设计或粤语特有的语法复杂度上。所以一个严谨的实验至少要包含两个对照组一组用粤语提示一组用英语提示两者采用完全相同的任务模板和评估流程。通过横向比较我们才有底气说“LLM 在这个环节是否真的有用”。3. LLM 在语法工程中可以承担什么角色3.1 从“生成一句话”到“生成可审校的候选”如果只是让 LLM 写几个粤语例句它通常能完成但这对语法工程价值不大。语法工程需要的是“覆盖某个语法现象的例句、带注释的语义结构、符合词条格式的词典记录”这些是更结构化的产出。我建议把 LLM 的任务拆成下面几类任务类型传统做法LLM 辅助方式必须人工验证的程度词条扩写查阅词典和语料手工补充根据词汇生成搭配、论元结构候选高需要核对真实性测试句子生成专家根据规则手工编写针对指定句法现象批量生成变体中需要语法判断歧义句发现靠专家经验和语料检索生成同一句子的多种解释候选高容易幻觉规则文档解释专家手写注释和文档将规则改写成自然语言说明低可辅助阅读格式转换写脚本转换格式把词表转成 JSON/YAML/Lexc 片段中需要校验格式这种拆分很重要。不是所有任务都适合用 LLM比如“格式转换”用确定性脚本更可靠“歧义句发现”则一定要专家参与。LLM 的定位是扩大候选池而不是代替语法工程师。3.2 LLM 的短板不能靠“换模型”解决很多团队尝试换更大的模型来提高语法工程效果但实际瓶颈往往不在模型参数量而在任务设计。如果提示词里没有给出明确的输出格式和评价标准模型就会自由发挥生成大量不一致的内容。就算换成更强的模型也只能改善语言质量不能解决格式混乱和术语漂移。语法工程需要的是内部一致的形式系统。比如一个词在词典里标注为动词那它出现在规则里就必须遵守动词的约束如果 LLM 在不同轮次里把同一个词标成不同词类就会直接污染资源库。因此工程上必须把 LLM 的每次输出固定成 JSON 或 XML 这样的结构化数据并且配上版本号方便审计和回滚。3.3 我建议采用的工作模式最稳妥的工作流是人写种子种子词条和规则 → LLM 生成候选扩展 → 专家批量审核 → 通过测试用例后合并入库。每一步之间的接口固定下来LLM 只负责“生成”不负责“决定”。这套模式不会让语法工程一夜之间全自动但能把专家的精力从“翻词典写词条”转移到“审查关键语法判断”这才是 LLM 真正提升效率的地方。4. 从零搭建一个粤语语法 mini 资源4.1 先建立一个可验证的语法骨架不管是不是用 LLM第一步都应该是建立一个最小的语法骨架。这个骨架包含三类内容词库、规则、测试集。先不用追求覆盖面只保证结构清晰、能被程序解析后面的资源和规则才能稳定扩展。下面是一个简单的粤语语法资源骨架用 JSON 表示{ grammar_name: CantoneseMini, language: yue, lexicon: [ {word: 我, cat: N, gloss: I/me, features: {pers: 1, num: sg}}, {word: 你, cat: N, gloss: you, features: {pers: 2, num: sg}}, {word: 食, cat: V, gloss: eat, subcat: [SUBJ, OBJ]}, {word: 睇, cat: V, gloss: watch/read, subcat: [SUBJ, OBJ]}, {word: 咗, cat: Asp, gloss: PERF, features: {aspect: perfective}} ], phrase_structure_rules: [ {name: S - NP VP, annotations: SUBJNP; VPS}, {name: VP - V NP, annotations: OBJNP}, {name: VP - V Asp NP, annotations: OBJNP} ], test_sentences: [ 我食咗饭。, 你睇咗书。 ] }这个 JSON 文件本身不是一个完整的 XLE 语法但它定义了一个可读、可校验的语法骨架。后续无论是让 LLM 扩展词条还是让评估脚本统计覆盖率都可以从这份结构开始。这里的重点是所有资源都必须是结构化、可解析的数据而不是散落在一段段自然语言里的解释。4.2 使用 LLM 扩展词条候选有了骨架我们可以用 LLM 来扩展词条。下面的 JSON 是一个提示模板的示例你可以在本地模型服务或商用模型 API 中调用但不要直接把输出入库只作为候选{ purpose: expand_cantonese_lexicon, system_prompt: 你是计算语言学助手熟悉粤语语法。你只输出 JSON不要输出额外解释。, user_prompt: 根据以下粤语词汇列表为每个词补充词类、英文释义、常用论元结构。只输出合法 JSON 数组。\n词汇食、睇、畀、行、讲、知、想、要 }为了让输出格式稳定最好在提示词里写明“只输出 JSON 数组”和字段定义。模型返回后先用 JSON parser 解析无法解析的记录直接丢弃或重新生成。这段处理逻辑是语法工程里最容易忽略的环节因为很多失败不是模型不聪明而是输出格式不可控。4.3 把候选转成 LFG 规则LLM 生成的词条不是最终资源还需要映射到 LFG 规则中。比如“畀”这个动词涉及双宾语结构语法上需要两个宾语功能不能简单塞进动词条目。一个概念性的 LFG 规则可以写成这样% 注意这是示意写法不是可直接运行的 XLE 代码 VP - V NP NP { ^ !; (^ OBJ) !; (^ OBJ2) !; }.这段代码用 LFG 的注释方式说明双宾动词“畀”“送”等会把两个 NP 分别映射为 OBJ 和 OBJ2。真正使用时还需要在 XLE 里处理语序、格标记、可选项等细节但思路是清楚的LLM 负责生成候选词汇规则形态由人工工程师把关。这样既能利用 LLM 的词汇知识又能保证最终语法资源的一致性。4.4 用 Python 校验 JSON 资源资源文件会越来越大第一步要做的是格式校验。下面这段 Python 脚本可以检查词典里的词条是否重复、词类是否有定义、规则名是否唯一import json import sys def validate_grammar(path): with open(path, r, encodingutf-8) as f: g json.load(f) errors [] pos_set {N, V, Asp, P, Adv, Conj, Part} for item in g.get(lexicon, []): if word not in item or cat not in item: errors.append(f词条缺少 word 或 cat: {item}) elif item[cat] not in pos_set: errors.append(f未定义的词类 {item[cat]}: {item[word]}) names [r[name] for r in g.get(phrase_structure_rules, [])] if len(names) ! len(set(names)): errors.append(规则名存在重复) if errors: print(校验失败:) for e in errors: print( -, e) sys.exit(1) print(校验通过) if __name__ __main__: validate_grammar(canto-grammar-mini.json)这个脚本不是什么复杂功能但它能确保每一步都是可重复的。实际工程里你可以在提交代码前把它放进 CI持续集成流程一旦 LLM 生成的新词条导致格式错误立刻会暴露出来。5. 受控实验设计为什么要用英语基线5.1 避免“选几个漂亮例子”的陷阱很多 LLM 演示喜欢展示几个成功案例比如 LLM 生成了几个粤语句子看起来不错。但语法工程不是“看个例”而是要看覆盖率、准确率和错误模式。如果只挑成功案例很容易高估 LLM 的作用。受控实验的核心是固定输入、固定提示、固定评估标准然后比较不同条件下的表现差异。具体到粤语 ParGram 项目至少应该比较四种条件条件语种任务预期产出粤语 LLM粤语词条扩展/句子生成JSON 候选英语 LLM英语词条扩展/句子生成JSON 候选粤语 专家粤语词条扩展/句子生成人工资源英语 专家英语词条扩展/句子生成人工资源这里的英语基线不是用来证明“英语比粤语简单”而是作为一条校准线。如果 LLM 在粤语任务上的表现明显低于英语基线说明需要进一步分析是提示词问题、训练数据覆盖问题还是粤语本身的语法复杂度问题。5.2 提示模板要尽量固定受控实验里提示模板必须对每个语种做同样处理不能粤语用一套模板、英语用另一套模板。模板中的差异越小结论越可信。比如都采用“为以下词汇列表补充词类、释义、论元结构”的格式只是词汇列表不同。同时每个语种最好准备多组词汇和句子避免只测少量样本造成偏差。通常的做法是划定一个“语言现象清单”比如粤语里的完成体、双宾结构、句末语气词英语里的时态、被动结构、宾语从句再针对每个现象设计 10 到 30 条测试输入。这样实验既覆盖多个语法现象又能对每个现象单独统计。5.3 实验流程也可以完全自动化LLM 调用、输出解析、格式校验、指标统计都可以写成脚本。这样整个实验能够复现只要给定相同的输入和模型版本任何人跑一遍都能得到相同的结果。这个“可复现性”对语法工程尤其重要因为我们需要不断更新模型版本和提示词没有自动化流程根本没法比较新旧版本的效果。5.4 英语基线并不是“越高越好”需要提醒的是英语基线高不一定代表实验成功。英语在大模型的训练语料里占比很高模型对英语语法更熟悉很容易生成“看起来专业”的内容但这不代表它真的理解语法工程。所以英语基线更重要的作用是暴露方法瓶颈如果英语这么高资源的语种LLM 产出的采纳率也只是一般那就说明“用 LLM 直接生成语法资源”这个路径本身仍需谨慎。6. 评估指标与验证脚本6.1 选择什么指标语法资源建设不是问答评测不能只看“生成内容是否通顺”。我建议至少统计以下四个指标指标含义计算方式可接受率LLM 生成的句子或词条是否被专家认为是合法表达专家标记为“可接受”的数量 / 总数直接采纳率LLM 生成内容无需修改即可进入资源库的比例专家标记为“直接可用”的数量 / 总数平均编辑距离LLM 生成内容距离专家修改后版本的差异使用编辑距离越小越好格式有效比例输出能被 JSON/YAML/Lexc 解析的比例解析成功数 / 总输出数这四个指标能分别反映LLM 的语言水平、资源可用性、修正成本、工程稳定性。只看其中某一个是片面的。比如 LLM 输出格式很好但内容全部不合格那说明任务设计有问题如果内容合格但格式一塌糊涂说明提示模板解析策略需要优化。6.2 写一个简单的评估脚本下面的 Python 脚本可以处理包含专家标注的结果 CSV计算可接受率和平均编辑次数。你需要先准备一个 CSV 文件例如case_id,language,condition,accepted,edit_count yue_001,yue,llm,1,2 eng_001,eng,llm,1,0 yue_002,yue,llm,0,5 eng_002,eng,llm,1,1然后是评估脚本import csv import sys from collections import defaultdict def load_results(path): rows [] with open(path, newline, encodingutf-8) as f: reader csv.DictReader(f) for row in reader: rows.append({ language: row[language], condition: row[condition], accepted: row[accepted].strip().lower() 1, edit_count: int(row[edit_count]) }) return rows def summarize(rows): groups defaultdict(lambda: {accepted: 0, total: 0, edit_sum: 0}) for r in rows: g groups[(r[language], r[condition])] g[total] 1 g[accepted] 1 if r[accepted] else 0 g[edit_sum] r[edit_count] for (lang, cond), g in sorted(groups.items()): print(f{lang} | {cond}: acceptance{g[accepted] / g[total]:.2%}, avg_edit{g[edit_sum] / g[total]:.2f}) if __name__ __main__: path sys.argv[1] if len(sys.argv) 1 else results.csv summarize(load_results(path))运行方式很简单python evaluate_results.py results.csv预期输出大致是这样的格式具体数值会因实验数据不同而变化eng | llm: acceptance72.00%, avg_edit1.40 yue | llm: acceptance51.00%, avg_edit3.10看到这种结果后下一步不是马上下结论说“粤语比英语难”而是排查三类原因提示词是否对粤语足够友好、输出解析是否丢掉了某些正确内容、粤语测试集本身是否设定了过高的语言标准。7. 常见问题与排查思路实际运行这套流程时你会遇到很多细节问题。下面几个是最常见的问题现象可能原因排查方式解决方案LLM 输出大量非法 JSON提示词没有限制输出格式或模型自由发挥查看原始输出前 20 条确认是否被额外文本包裹在提示词中强制“只输出 JSON”解析失败时重试或丢弃粤语词条重复同一个词有不同汉字写法或繁简体差异对词条做归一化观察重复模式建立别名表统一转换成标准字专家对可接受率判断不一致粤语语法本身存在地域差异或评分标准不清晰计算不同专家标注的一致性制定详细评分手册先做一轮校准LLM 生成明显不存在的粤语表达模型对粤语资源覆盖不足产生幻觉把不合法句子单独聚类分析是否存在共同句型增加人工审校门槛对高频幻觉句型做黑名单英语基线比粤语高很多训练数据覆盖差异、提示词翻译偏差、语言复杂度差异固定同一提示模板逐项对比错误类型不要只归一化到总指标按语言现象拆分分析部分合法粤语句子被判定为非法评分人员对粤语口语变体不熟悉漏判的句子单独复盘确认是否属于特殊用法邀请更多粤语母语者参与标注补充上下文这些排查都不是一次性工作。语法工程本身是持续迭代的LLM 候选质量也会随着模型更新而变化。每一次实验都应该记录模型版本、提示词模板、种子资源版本和评测结果这样后续出现问题才能回溯。8. 最佳实践与工程建议8.1 把 LLM 当作“候选生成器”而不是“权威判定器”这句话值得反复强调。LLM 可以快速给出词条、例句和规则解释但它没有能力保证一套语法系统内部的逻辑一致性。专业语法工程师的价值并不在“知道某个词是什么意思”而在“知道这个词进入规则后会不会影响其他词类的处理”。所以资源入库前必须经过至少一位语法专家确认尤其是涉及论元结构、语序限制、语义角色这些关键判断时不能省这一步。8.2 所有资源都要版本化语法资源和普通代码没有区别需要版本管理。每次 LLM 生成的候选、每次人工修改、每次实验评估都应该有迹可循。文件名里可以加上日期和模型版本例如canto_lexicon_2025_06_qwen.json然后通过 Git 维护合并历史。这样即使某次生成内容质量很差也能快速回滚。8.3 警惕训练数据污染很多粤语例句可能已经出现在 LLM 的训练数据里所以它生成一个合法句子不一定代表它理解了句法规则。实验设计时最好准备一部分“不可能出现在公开语料中的新造词”或“人工构造的边际句”比如把不常见名词放入典型句型观察 LLM 是否能正确给出论元结构。如果模型在常见句上表现好、在构造句上大幅下降说明它更多是在记忆而不是推理。这个结论对语法工程尤其重要。8.4 注意内容安全与版权边界语法资源建设通常会用到大量例句LLM 生成例句时可能无意间生成含有冒犯性或隐私风险的句子。尤其是粤语是日常口语更容易出现不礼貌表达。工程上要加一道“内容过滤”步骤至少排除明显不文明词汇并提醒标注人员不要将真实人名、地名写入测试语料。安全边界应该在实验设计阶段就确定而不是等语料发布后再补救。8.5 从最小可行语法开始别想一步到位一开始不要追求覆盖所有粤语语法现象。先选 3 到 5 个高频、规则清晰的现象比如完成体“咗”、双宾结构、基本语序搭建一个 mini 语法跑通“LLM 生成 → 人工审核 → 入库 → 测试”的完整循环。之后再逐步扩展。这样做的最大好处是每个环节的问题都能在小范围内暴露不会等语法库膨胀到几万词条后才发现设计缺陷。9. 接下来的方向从项目标题里可以看到研究者已经把“受控实验评估”和“英语基线”当作默认方法。这比单纯展示几个 LLM 生成的粤语例句要有说服力得多。顺着这个方向下一步最值得做的是三件事。第一建立一个小而完整的粤语金标测试集。测试集应覆盖核心词类、高频句型、典型句末语气词并且每条句子都要有专家标注的合法性判断和功能结构解释。这个测试集既是语法库的回归测试也是以后评估 LLM 新版本的基准。第二把实验流程包装成半自动管线。从提示词模板、模型调用、输出解析、格式校验到统计指标全部用脚本串起来。人工只负责审校最终生成的内容。这样的管线一旦跑通换一种语言、换一个语法框架也能快速复用。第三针对 LLM 的高频幻觉模式做错误分类。不要只记录“这条错了”而是记录“错在词类、错在语序、还是错在论元结构”。错误模式积累到一定量后可以根据错误类型定制修正规则甚至在提示词中主动加入反例来降低幻觉概率。回到最初的问题LLM 对语法工程到底有没有用答案是肯定的但它有用在一个很具体的位置——候选生成、文档解释、测试样例扩充。真正的语法决策、规则一致性和资源质量保证仍然要落在有经验的语法工程师手里。如果你正要开展类似的小语种资源建设与其焦虑模型能力够不够不如先把实验评估框架搭好。一个能准确衡量“产出质量”的流程远比单个惊艳的生成案例更能推动项目稳定前进。