Stéphan Tulkens

RSS: https://stephantul.github.io/feed.xml

NLP 从业者的博客，关于自然语言处理与机器学习。

把 prompt 藏进 tokenizer

拥抱的脸<code>tokenizer.json</code>spec 允许你在后期处理器中隐藏提示。在这篇文章中，我将向你展示它是如何运作的，以及它如何提升代币化器的可移植性。<h2>前缀提示</h2>提示，或者更技术上说，设置系统提示，自从OpenAI允许用户通过API调用向模型发送系统提示后，已经变得无处不在。也许不太为人所知的是，许多普通变换器是在文档前缀前缀简单提示词来训练的，而不是作为单独的消息。例如，请你先做前言<code>query :</code>查询或一般文档，以及<code>passage :</code>要取回文件。这些提示词本身并非模型工件的一部分;你需要知道如何使用它们，忘记使用它们会降低性能。我觉得最后一点特别重要：忘记添加提示会降低性能，但这种下降在不做评估的情况下很难察觉。你的模型能正常工作，只是不会达到最佳状态。它很好地支持提示及其模型管理：提示词以字符串形式存储在<code>sentence-transformers-config.json</code>然后在文档前加上，之后整个字符串被标记化。 字符串连接的一个潜在问题是分词器可以跨提示边界分词，这可能会改变结果。不过，我认为训练模型是很常见的<code>sentence-transformers</code>然后通过专门的服务框架来服务它们，例如：.在这样做时，你必须记得以同样的方式在同样的提示前加上。我展示了隐藏一个单…

收藏38 天前

去掉"##"！将续接标记转换为词首标记

词首标记方案比续接标记（##）更简单实用，可用 skeletoken 工具无损转换。续接标记会让 BERT WordPiece 词表无法直接用于 BPE 或 UnigramLM 模型，而反向转换天然兼容。代码示例展示了贪心左到右推理在两种方案下的差异：续接标记需要维护两个独立词表并手动插入标记，词首方案只需一个自动机。skeletoken 的 to_normal_form 方法可将任意 tokenizer 转为词首格式，编码结果 ID 完全一致。

收藏44 天前

Skeletoken 0.4.0 发布：词汇表合并与模型嵌入安全调整

Skeletoken 0.4.0 新增 consolidate_vocabulary 方法，自动清理因添加 normalizer 或 pre-tokenizer 导致的词汇表冗余和冲突条目，同时保持 merge table 和 token ID 一致。新增 ModelDelta 功能，在编辑词汇表后自动映射旧 token ID 到新 ID，安全调整模型 embedding 表，无需从头重新训练。支持 transformers、sentence-transformers、pylate 和 model2vec 四个框架。修复词汇合并 bug 和预处理空 token 问题，CI 升级至 Python 3.14。

收藏59 天前

从“切斯特顿的栅栏”到“切斯特顿的缺口”

文章提出了“切斯特顿的缺口”这一概念，作为经典工程原则“切斯特顿的栅栏”的补充。前者指在开源项目中，贡献者因代码成本极低而盲目提交未经沟通的功能或配置（即“建栅栏”），而非先理解为何作者未实现该功能（即“不建栅栏”）。作者认为，这种缺乏上下文理解的“免费”代码往往增加维护负担，建议贡献者在添加功能前先提问，尊重原作者的设计取舍。

收藏105 天前

为某人创造些什么

作者引用音乐人Musa Okwonga关于“自动化正在让我们失去工作乐趣”的观点，结合自己使用AI编程辅助的经历进行反思。虽然AI提高了生产力，但作者认为最大的风险不是技术降级，而是失去与人协作的创造乐趣和情感连接。文章主张，软件开发的本质是人与人的共同创造，不应为了效率而牺牲协作中的人文关怀和智力刺激。

收藏134 天前

Scikit-learn 的 fit/transform 范式可能并不适合你

文章批评 scikit-learn 的 fit/transform 模式混淆了工厂模式和实际对象，指出其存在状态不可知、易出错等缺陷。作者建议将工厂与使用对象分离，通过返回新对象而非修改原对象状态，实现更清晰的类型安全和代码结构。

收藏136 天前

在RTEB基准上评估静态模型：监督学习为何击败知识蒸馏？

针对MTEB基准测试中存在的刷榜问题，新发布的RTEB基准引入了私有测试集。作者对比了静态嵌入模型的两种训练方式：知识蒸馏与监督学习。实验结果出人意料地显示，在私有测试集上，监督学习模型显著优于知识蒸馏模型，这反驳了作者关于蒸馏泛化性更强的预设。文章指出监督学习即使在不直接相关的任务数据上也能获得更好的检索性能，并建议未来探索混合训练及更广泛的知识蒸馏策略。

收藏357 天前

静态模型降维实战：PCA与MRL的深度对比

作者对比了静态嵌入模型降维的两种主流方法：PCA和MRL。实验发现，对于直接通过梯度下降训练的模型，PCA的额外收益微乎其微，因为模型本身已具备零均值特性。相比之下，MRL在低维场景下表现显著优于PCA，因为它能直接学习截断鲁棒性。结论是：若未训练且嵌入非零均值，可用PCA；否则应优先使用MRL，两者结合并无额外帮助。

收藏359 天前

静态晚期交互模型本质上就是稀疏模型

文章论证了在静态嵌入模型中应用晚期交互（Late Interaction）机制时，其数学本质等同于稀疏检索模型。作者指出，由于静态向量不随上下文变化，最大相似度计算（maxsim）实际上退化为基于词汇表的加权匹配，丢失了动态模型捕捉语义细微差别的能力。除非重新引入BM25等稀疏检索特有的权重调整机制，否则静态晚期交互模型在理论上和实践中都不优于传统的稠密或稀疏模型。

收藏365 天前

更优的贪婪分词器：解决 WordPiece 的 [UNK] 问题

文章指出 HuggingFace 的 WordPiece 算法在处理超长字符串时会因性能保护机制（max_input_chars_per_word）而静默输出 [UNK] 标记，导致多语言或长文本场景下分词失效。作者分析了其二次方时间复杂度的根源，并提出使用 FixedLength pretokenizer 将长串截断为有效块作为解决方案。这是针对 NLP 工程实践的具体技术优化，提供了清晰的代码实现思路，对从事大模型底层构建和数据处理的技术人员有较高参考价值。

收藏377 天前

笔记：字节分词器中正则分割的替代方案

作者指出之前提出的在字节空间使用正则分割的方案存在缺陷，因为某些字符类难以转换。随后发现可以通过堆叠预处理器的方法解决：先用正则进行Split预处理，再用ByteLevel处理器并将split设为False。这种方法不仅正确，而且是Qwen等模型实际采用的方案，允许自由设计正则表达式并进行字节归一化。

收藏414 天前

在 ByteLevel 分词器中将归一化与分词解耦

作者指出 Hugging Face Tokenizers 中 ByteLevel 预分词器的默认行为（插入空格、字节编码、英文正则分词）耦合过紧，且其英文正则分词器在多语言场景下表现不佳。文章建议将归一化（Normalization）与分词（Splitting）解耦，利用 Tokenizers 库提供的 Normalizer 和 Regex Splitter 组合来实现更灵活、多语言友好的处理流程。虽然自定义字节正则编写困难，但这种方式能避免破坏非英语语言的 tokenization 结构，适合对分词逻辑有精细控制需求的开发者。

收藏414 天前

将任意Tokenizer转换为贪心模式

作者重读论文发现将Tokenizer推理改为贪心算法能提升性能，但在下游任务实验中直接替换却导致效果全面崩盘。核心逻辑在于：预训练模型依赖特定的Token分布，强行改变分词方式而不重新训练，破坏了Embedding表与Token的对应关系。作者推测，如果在预训练阶段就使用贪心算法，可能因更符合形态学而获得更好效果。

收藏416 天前

为了乐趣给Transformer去大小写：一种优化Tokenizer的技巧

文章介绍了一种名为“decasing”的技术，用于将区分大小写的Tokenizer转换为不区分大小写的版本。作者指出，直接对输入文本进行小写化会丢失大量词汇表信息，而通过修改Tokenizer内部词表和合并规则来实现“decasing”，能更完整地利用词汇表。实验结果显示，在部分任务中，decasing的效果优于直接小写化，但通常不如保留原始大小写信息的模型。文章提供了具体的实现代码和实验数据，适合对NLP底层优化感兴趣的开发者。

收藏424 天前

使用重载处理Python中的联合返回类型

文章探讨了Python中处理联合返回类型（Union Return Types）的难题。当函数根据输入类型返回不同类型时，静态类型检查器往往无法准确推断，导致返回类型总是被标记为联合类型，迫使开发者使用强制转换。作者首先建议尽量避免这种设计，将其拆分为多个函数。如果必须保留原实现，可以使用 typing.overload 装饰器来为不同输入定义精确的签名，从而让类型检查器正确推断返回值。对于更复杂的情况，如基于参数值（而非类型）改变返回类型，作者展示了如何利用 Literal 类型将布尔值转化为类型，配合 overload 实现精确的类型提示。虽然这种方法有效，但作者认为代码过于复杂，仅建议用于修复遗留代码，新代码应尽量避免此类设计。

收藏550 天前

Evaluating ML classifiers using relative error instead of absolute accuracy

收藏566 天前

在不惹恼用户的情况下，彻底告别“字符串类型”编程

文章探讨了在Python中解决“字符串类型”（stringly typing）问题的最佳实践。作者建议在使用Enum进行强类型检查时，通过让Enum成员值为字符串（如StrEnum），并在API入口处兼容字符串输入，从而兼顾内部代码的类型安全性和外部用户的易用性。这种方法避免了用户必须导入Enum类的麻烦，同时提供了清晰的错误提示。文章最后指出，尽管这种模式在transformers等库中存在，但用户往往仍习惯直接使用字符串。

收藏572 天前