惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

J
Java Code Geeks
量子位
MongoDB | Blog
MongoDB | Blog
N
Netflix TechBlog - Medium
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
B
Blog
A
About on SuperTechFans
腾讯CDC
The GitHub Blog
The GitHub Blog
云风的 BLOG
云风的 BLOG
雷峰网
雷峰网
Last Week in AI
Last Week in AI
H
Help Net Security
WordPress大学
WordPress大学
博客园 - 司徒正美
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
H
Hackread – Cybersecurity News, Data Breaches, AI and More
T
Tailwind CSS Blog
博客园 - 【当耐特】
S
SegmentFault 最新的问题
美团技术团队
M
MIT News - Artificial intelligence
L
LangChain Blog
博客园 - 聂微东

博客园_首页

Plist 二进制格式 Milvus 和 PGVector,哪个更好? OpenClaw 已过时?在 VS Code 中运行 Hermes Agent! 第30篇文章:一个大三计科生的自白 Manim如何在数学公式中完美显示中文? Docker 部署 RocketMQ 5 并发编程核心概念辨析 C#事务处理最佳实践:别再让“主表存了、明细丢了”的破事发生 CLI 是什么?为什么大厂突然集体卷命令行? 【从0到1构建一个ClaudeAgent】协作-自主Agent UIImageView 设置图片不生效的原因排查 最小二乘问题详解20:无先验约束下的增量式SFM自由网平差 痞子衡嵌入式:大话双核i.MXRT1180之XIP应用里借助MU实现可靠Flash IAP的方法 AI Chat 封装, SemanticKerne.AiProvider.Unified 已发布 Windows下右键编辑js文件无法打开记事本——在注册表中使用环境变量 在后台服务中使用 Scoped 服务,为什么总是报错? H200 安装驱动并使用sglang启动模型 wireshark 抓包Trap上报告警内容 我用 AI 辅助开发了一系列小工具(2):图片压缩工具 [A Primer On MC and CC] 2.1 Memory Consistency 1 - 指令重排序和 SC 模型 Oracle数据库SCN推进技术详解与实践指南 玩转控件:封装个带图片的Label控件 Claude Code 4.7 真正该升级的不是模型,而是你的工作流 前端小白一句话,AI 帮我做了个颜值拉满的桌面媒体播放器。当代码不再是门槛,一句话编程就是现实。 5. WorkBuddy: 小龙虾的灵魂三件套,让你的小龙虾不只是工具 SQLite 分片方案实战:三种分片策略的深度对比 告别简陋 UI!一款基于 Fluent Design 和基于 WinUI 的开源免费、现代化的 Avalonia UI 控件库 关于二进制排列组合枚举的总结 AI开发-python-LangGraph框架(3-27-LangGraph从零实现大模型智能决策工作流) ElasticSearch主分片和副本分片概念详解
15天学会AI应用开发(四)根据Token长度截断历史对话
aqi00 · 2026-06-06 · via 博客园_首页

上一篇文章说到按照消息数量来截断历史对话,这种方式有个问题,就是每次对话的内容可长可短,导致固定消息数量的对话内容忽长忽短。

历史对话内容不光要存入数据库,还要作为初始提示词发给下次新会话的大模型。太长的提示词不仅冗余,还会消耗大量Token,让用户钱包快速缩水。太短的提示词容纳的信息量不足,难以起到充分记忆的功能。

一、为什么统计Token个数而非文字个数

改进方式是按照文字长度来截断历史对话,不过字跟字又有所不同,不如“猪”是个单字词,而“鹦鹉”是个双字词。对于大模型来说,“猪”和“鹦鹉”具有同等权重,它们都占用一个Token,也就是词元。所以,更好的办法是统计Token数量,而非统计文字数量。

Token不是单个字、也不是单个字母,而是大模型训练时固定好的“最小词块”。早期的AI库主要适配英文,常用单词、词根、词缀直接就是一个Token。对于中文则没有完整常用中文预制词块,大多只能拆成偏旁、笔画、字节片段。

原因是传统的Token分词器采用BPE算法,该算法属于字节级对子压缩,它的底层是按UTF-8编码的字节来切分,不是按中文语义切分。由于每个中文的UTF-8编码固定占用3个字节,而BPE分词器是按字节流拆分、合并成词块,因此3字节的中文很难刚好凑成1个Token。常用汉字还能凑成1个Token,生僻字、复杂字基本拆成2个Token。

可见传统的Token分词器极其违背常识,竟然还能将1个中文拆成两个Token,如此倒翻天罡,敢情是歧视中文用户吧?所以我们的国内开发者挺身而出,开发了中文分词库,能够依据习惯把中文句子切分为各个词语,使得Token数量小于文字数量,这才提高了中文大模型的效率。

二、传统的Token数量统计方式

传统的Token分词器依赖于tiktoken库,在编写Python代码前,要先在命令行执行下面的pip安装命令:

然后编写下面的Python分词测试代码:

运行上面的Python代码,输出日志结果如下:

总共16个字符的中文,使用传统的Token分词器,竟然统计得到25个token,不合理简直太不合理了。

三、中文Token数量的统计方式

中文的Token分词器依赖于jieba库,在编写Python代码前,要先在命令行执行下面pip安装命令:

然后编写下面的Python分词测试代码:

运行上面的Python代码,输出日志结果如下:

总共16个字符的中文,中文传统的Token分词器,精简后统计得到11个Token,可见相较传统分词器大幅瘦身。

四、根据Token数量精简上下文

接下来将以Python代码演示如何按照Token数量来截断早期的上下文(即问答内容)。下面是只保留100个Token的Python代码例子:

运行上面的Python代码,观察到最后一轮的输出日志:

可见最后一轮根据Token限制删去了较早的对话记录,使得总Token数维持在50以内,这就节约了下次会话的初始Token消耗。

本系列的AI应用开发文章目录为《15天学会AI应用开发全目录(零基础小白,零Token消耗)》。