WordPress 标签清理实践（一）：大语言模型匹配的失败尝试

WP 博客多语言化实操

(1) 博客多语言化决策｜为什么我决定花时间做多语言？（附真实发现）

(2) 博客多语言插件选型｜免费vs付费、服务端vs浏览器端，实测对比+配置教程

(3) 博客分类翻译实操｜695个分类，4小时手动翻译全流程（避坑指南）

(4) 博客标签翻译实操｜8060个标签，基于 PHP 脚本实现全流程

(5) 博客菜单翻译实操

(6) WordPress 多语言博客文章翻译实操全记录（Polylang 插件，附避坑指南）

(7) WordPress 新增文章分类标签多语言前置翻译流程（Polylang 总数校验+标签脚本复制避坑）

(8) 告别手动编号：用 PublishPress Series 优雅管理 WordPress 系列文章

(9) WP 6.9 标签同步脚本在 WP 7.0 失效完整排查与解决实录

(10) 阿里云RDS数据库误操作损毁，完整备份恢复实操避坑指南

(11) AI生成代码深度避坑：数据库操作代码绝不可以直接上线执行

(12) WordPress 标签清理实践（一）：大语言模型匹配的失败尝试

(13) WordPress 标签清理实践（二）：Go 脚本工程化落地

(14) WordPress 标签清理实践（三）：完美解决Polylang中英文同义标签合并难题

(15) WordPress 标签清理实践（四）：基于Go脚本实现WordPress中英文标签合并与URL自动跳转

(16) WordPress 标签清理实践（五）：基于 PHP/Go 脚本解决 English 语言下残留的中文标签问题 ，并实现自动化的标签合并与 URL 跳转

(17) WP 标签批量翻译脚本准确性问题排查与修复

(18) WordPress 英文站日历链接变成双重 URL：Polylang 子域名迁移后的 WPCode 与 W3TC Object Cache 排查

(19) WordPress 英文站出现横向滚动条：排查 Polylang 多域名下 W3TC Object Cache 缓存旧 CSS 的问题

(20) WordPress Polylang 英文子域名迁移后链接仍指向中文站：分类下拉、面包屑与区块模板的完整修复

(21) WordPress 英文站从 /en/ 迁移到子域名后，如何调整 GA4 与百度统计

(22) WordPress 多域名架构下 W3 Total Cache 缓存失效：Polylang、Redis 与 admin 子域名的完整排查和修复

(23) 第三次排查才找到真因：Polylang 标签同步脚本总数长期不一致，原来是持久化 Term Query 缓存

(24) 从 SyntaxHighlighter 到 Code Block Pro：把 WordPress 历史文章摘要与英文覆盖翻译流程标准化

在推进博客搜索引擎优化的过程中，我发现了一个严重的阻碍：由于多语言同步机制，产生了大量 /en/tag/中文 这样的冗余网址。这不仅造成了标签库的臃肿，更让搜索引擎难以正确索引英文页面。为了彻底清除这些不利于 SEO 的网址，我必须对多语言标签进行合并清理……

我的 WordPress 站点使用 Polylang 实现了中英双语。由于存在一个同步的 PHP 脚本，每次发文时，中文标签会被自动复制到英文语言下。久而久之便产生了数据冗余：例如“支付宝”和“alipay”，在中文和英文语言下均同时存在。

这不仅导致标签库臃肿，更产生了 /tag/支付宝 和 /en/tag/支付宝 这样的冗余网址。我的最终目标非常明确：彻底清除 /en/tag/ 路径下包含中文的网址。为此，必须在中文语言下将“支付宝”合并至“alipay”（或直接删除），并在英文语言下执行相同的清理操作。

起初，我认为这类语义匹配任务非常适合大语言模型处理，便开始尝试使用各大主流模型进行数据清洗，但最终结果却迫使我将方案转向了编写代码。

第一阶段：原始数据的提取与整合

使用大模型的前提是提供完整的数据集。在阿里云 DMS 中导出全量数据的过程颇为繁琐。

首先，需要查询出所有被 Polylang 标记为中文、且 Slug 包含中文字符的标签。

DMS 的查询结果默认仅展示前 3000 行，而我的中文标签数量超过了此限制。尝试全量导出时，系统仅提供 Excel 格式且依然会分割为多个文件，不符合后续处理需求。因此，只能逐页执行 CSV 格式的导出操作，最后再手动将所有分页文件整合为一份完整数据。

其次，还需要导出被标记为中文、但 Slug 不包含中文字符的标签。这部分数据实际上是中文语言下的纯英文标签（例如“alipay”由于同步机制也存在于中文语言下）。至于中英混合标签，其 Slug 中必然包含中文编码，因此已被包含在上一批数据中。导出这部分纯英文标签数据，同样需要经历逐页导出与手动合并的过程。

经过上述繁琐的数据提取与整合，终于获得了完整的标签数据集。随后，我将这些数据带入各大语言模型的对话框中进行了测试。

第二阶段：大语言模型测试表现

测试的逻辑很明确：要求模型对比两份标签列表，将语义相同的条目进行映射，同时对纯中文的同义标签进行聚类。测试时并未使用文件上传功能，而是直接将数据文本粘贴至对话框中。

1. DeepSeek：上下文超限

首先测试了 DeepSeek 模型。数据粘贴完成后，系统即提示输入长度超限约 58%。单次对话的上下文窗口无法容纳该规模的数据，任务在初始阶段即被终止。

2. 豆包：严重的幻觉问题

随后测试了豆包模型。该模型接收了完整数据并输出了结果，但经过抽样检查，发现其输出存在严重的“幻觉”。模型未能进行准确的语义匹配，反而凭空捏造了诸多不存在的标签聚合关系。例如，它将多个中文标签错误地聚类到一个数据库中根本不存在的“谷歌play无法打开”标签下。此类看似格式规范实则内容谬误的结果，若直接应用于生产库，将造成严重的数据污染。

3. 通义千问：服务过载

在前述模型表现不佳的情况下，转而测试通义千问。但由于当前访问人数过多，服务处于过载状态，未能进入实际测试环节。

4. ChatGPT：部分有效但无法全量处理

最后测试了 ChatGPT（GPT-4o）。其表现相对较优：在粘贴大量数据时，模型自动识别数据规模并将其转换为文件上传模式。此外，模型在分析数据结构后，主动建议将混合数据拆分为 zh_tags.csv 和 en_tags.csv 两个独立文件。

在交互过程中，它确实输出了一批高置信度的映射结果（如“支付宝->alipay”、“队列->queue”）。然而，受限于上下文长度与复杂逻辑处理能力的算力开销，处理过程在完成极小部分后便停止，无法完成 3000 余条数据的全量吞吐。

反思与方案重构：大语言模型的局限性

经过上述测试，可以得出结论：对于此类需要严格比对海量结构化数据且容错率为零的任务，大语言模型的概率生成机制存在根本性缺陷。 上下文窗口限制、执行过程易中断以及无法根除的幻觉问题，均使其无法胜任此类批量化、高精度的数据处理工作。

因此，我决定放弃基于大模型的语义匹配方案，转向确定性的工程化实现：

1. 机器翻译：调用百度通用翻译 API，将中文标签稳定转换为英文。
2. 精确匹配：使用 Go 脚本将翻译结果与英文标签库进行字符串级别的精确碰撞，生成映射关系。
3. 自动化执行：依靠脚本稳定完成 3000+ 次的 API 调用与数据处理，杜绝中断。

无法依赖大模型完成这数千条多语言标签的清洗，我只能回归代码。只有通过程序精准地将中文标签映射并合并到英文标签，才能从根源上消灭那些冗余的英文中文网址，完成这次 SEO 深度清理。下一篇文章，我将记录如何用 Go 脚本把这套多语言数据清洗逻辑落地。