先看一条很典型的工单。
凌晨两点，客服系统收到一句话。
「我昨天充的 500 没到账，订单号 A20260809173，别再让我重复一遍。」
大模型可以写出一句很体面的安慰，也能概括用户的问题。但真正决定这张工单会不会被正确处理的，往往是几件看起来已经「过时」的事：系统能否稳定识别金额、订单号、时间和投诉意图；能否把它们映射到数据库字段；能否用同一套规则回放、统计和审计。
大语言模型已经改变了文本系统的交互入口，分词、匹配、序列标注和信息抽取却没有随之消失。不是工程现场落后，而是这些任务承担的责任从来不只是在排行榜上拿分。
大模型替代的，主要是许多任务的交互入口；它没有替代文本系统对边界、字段、证据和延迟的要求。
模型可以不按词典分词，系统却不能没有边界。
Transformer 接收的是 token 序列。它不一定沿用词典里的「词」，却仍然必须把连续文本变成离散单元。BPE 一类子词算法通过反复合并高频相邻单元，在词表规模、序列长度和未登录词之间做折中。中文分词则可以被表述为 BMES/BMESO 序列标注：每个字处于词首、词中、词尾、单字或特殊位置。
这不是教材里无关紧要的前史。切分边界会影响至少四件事：
- 成本。 同一句话被切成多少 token，直接影响上下文占用与推理成本。
- 检索。 专有名词、型号、化学式被错误拆分，可能让关键词召回和稀疏检索失效。
- 对齐。 标注、脱敏、引用高亮都需要从 token 坐标还原到原文字符坐标。
- 安全。 规则引擎、敏感信息检测和输入过滤必须知道它匹配的是哪个原始片段，而不是一个模糊语义。
一个系统如果无法指出命中了原文哪几个字符，就无法稳定完成高亮、脱敏、引用和审计。因此，字符偏移、规范化偏移和模型 token 偏移都要保存。边界对齐以后，检索仍然需要区分语义相近和对象相同。
工程上应同时保留三套坐标：原始字符偏移、规范化文本偏移、模型 token 偏移。大小写归一、全半角转换、HTML 清洗和 OCR 修正，都应保存可逆映射。否则模型给出一个看似正确的实体，系统却无法把它准确标回用户看到的原文。
所以，「模型自己会理解」不能成为删除预处理层的理由。
恰恰相反，模型越复杂，边界映射越要显式。
语义匹配也没有消灭精确匹配，它只是扩大了召回面。
假设用户问「会员怎么退」。向量检索可以召回「取消自动续费」「终止订阅」「退款规则」等语义相近内容。这是大模型时代的重要进步。但如果查询包含发票号、药品批号、错误码或法规条款，近似相似可能把「看起来像」的错误对象排到前面。
可靠检索通常不是在「关键词」和「向量」之间二选一，而是分工：
精确匹配负责订单号、版本号、专名和硬性过滤；稀疏检索利用词项区分度，保留罕见词的信号；稠密检索处理同义改写和自然语言问题；重排模型综合问题与候选段落；业务规则检查权限、时效、地区和文档状态。
可以把混合评分写成一个简单形式：
[ S(d,q)=\alpha S_{dense}+\beta S_{sparse}+\gamma S_{exact}+\delta S_{policy} ]
这里最重要的不是四个系数，而是承认四类证据不可互相冒充。语义相似不能证明编号相同，关键词重合也不能证明回答了同一个问题。
检索评测必须加入「一字之差就不能召回错」的样本。解释型查询看语义召回，订单号、批号和条款号则看精确匹配。召回结果进入业务之前，还要变成受类型约束的结构。
实践中，应该把评测按查询类型切开：解释型问题看语义召回，标识符查询看精确率，时效性问题看新鲜度过滤，权限问题看越权率。一个总的 Recall@K 会把这些截然不同的失败揉成平均数。
再往下走，信息抽取不是低配版生成，而是把语言接到数据库。
信息抽取的目标不是「写一段合理的话」，而是从文本中得到可验证结构。命名实体、关系和事件都可以被统一描述成结构化抽取目标，关键是让每个字段能够追溯到原文证据。
大模型让开放式抽取更灵活，却没有自动解决结构契约。下面两个输出在人看来意思差不多，对机器却完全不同：
{"amount": 500, "currency": "CNY", "order_id": "A20260809173"}
{"money": "五百块", "order": "A20260809173（可能）"}
生产系统需要的是第一类输出，而且还要补上字段类型、是否必填、枚举范围、证据区间与置信度。真正稳健的流程是：
- 用 JSON Schema 或类型系统定义合同；
- 让模型按合同生成候选结构；
- 通过解析器、正则、词典或数据库校验；
- 保存每个字段对应的原文证据；
- 低置信度或冲突样本进入人工复核。
这时，传统方法不是和大模型竞争，而是在给它安装插座。正则善于号码和日期，词典善于受控实体，序列标注善于稳定领域，LLM 善于长尾表达与上下文消歧。组合后的系统通常比「全部交给一个提示词」更容易测试。
自然语言可以宽松，进入业务状态之前的结构必须严格。
更容易被忽略的，是这些老任务给大模型留下了一把评测尺。
生成答案的评测很容易滑向「读起来不错」。而分词、分类、匹配、抽取等经典任务提供了明确的对象：边界是否一致、标签是否正确、实体是否完整、关系是否成立、候选是否相关。
这套思想可以直接迁移到大模型系统：
RAG 不只评最终答案，还评检索段落是否包含证据；摘要不只评文风，还检查关键实体和数字是否保留；智能客服不只评「有帮助」，还评意图、槽位和下一步动作；Agent 不只评任务完成，还评每次工具调用的参数和权限。
建立评测时，可把一次端到端失败拆成四段：解析失败、召回失败、推理失败、执行失败。每段都有不同指标和责任边界。如果只给最终回答打一个总分，团队只知道「系统不太好」，不知道该修数据、检索、提示词还是工具层。
分层评测的价值就在这里。线上质量下降时，团队应该能迅速判断是解析、召回、推理还是执行出了问题，而不是只得到一个端到端总分。定位能力建立以后，小方法还承担着成本和降级。
经典 NLP 的真正遗产不是某个模型架构，而是任务定义：先明确输入、输出、标签和误差，再讨论算法。对今天的 LLMOps，这种克制比任何新提示词都更珍贵。
然后是产品一定会遇到的现实，延迟、成本和降级。
并不是每条文本都值得调用最大模型。垃圾过滤、路由分类、敏感词检测、格式校验、重复问题识别，常常要求毫秒级响应、大吞吐和稳定成本。一个小分类器、自动机或 BM25 索引，可能已经足够。
更合理的架构是级联：
规则/缓存 → 小模型 → 检索增强模型 → 大模型 → 人工
简单请求在前面结束；只有歧义大、风险高或长尾的问题才升级。这不是「降低智能」，而是把计算用在真正需要它的地方。当前一层故障或预算耗尽时，后面的确定性组件还可以提供保守降级：返回检索结果、填写半成品表单，或者明确转人工，而不是让服务整体失明。
设计级联系统时，不要只设置信心阈值，还要考虑错误代价。营销文案可以接受多样性；付款、医疗和权限变更宁可多一次确认。升级规则应由不确定性 × 影响范围 × 可逆性共同决定。
走到这里，真正现代的 NLP 反而很清楚，它是概率能力与确定性约束的协作。
「大模型会不会淘汰 NLP」这个问题，本身就把领域误解成了一组旧算法。NLP 的核心从来不是某个分词器，而是让自然语言进入可计算系统。大模型扩大了可处理语言的范围；分词、匹配、抽取、规则和小模型则把这种能力变成可定位、可度量、可执行的工程对象。
如果要重构一条已有文本链路，可以从一张表开始：
输入规范化时，规则与坐标映射要保留原文和规范化位置，失败就保留原文并告警。候选召回时，稀疏、稠密和精确匹配各自留下命中证据，故障时还能降级到关键词搜索。结构抽取进入 Schema 校验，字段必须能指回原文，低置信度就转人工。答案生成保存引用和版本，证据不足就返回证据，而不是补完剧情。动作执行则交给类型与策略引擎，权限或回执缺一项，默认都不执行。
这里没有「传统」与「先进」的阵营，只有不同部件各自该负的责任。
大模型让机器更会说话；经典 NLP 让系统知道自己究竟说了什么、依据什么、接下来能做什么。
回到开头那条工单。
用户要的不是一句更像人的安慰，而是那 500 元、那个订单号和那次失败，能被准确找到、写进正确字段，再交给正确的人处理。
下一次有人宣布分词、匹配或信息抽取已经死亡，不妨看看他的系统是否还需要控制成本、查找订单、标注证据、评估错误和写入数据库。只要这些需求还在，经典 NLP 就没有消失——它只是从舞台中央，进入了机器的骨架。
作者｜随机比特
