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

推荐订阅源

博客园_首页
博客园 - 【当耐特】
博客园 - 叶小钗
阮一峰的网络日志
阮一峰的网络日志
WordPress大学
WordPress大学
D
Docker
T
The Blog of Author Tim Ferriss
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
Microsoft Azure Blog
Microsoft Azure Blog
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
月光博客
月光博客
M
MIT News - Artificial intelligence
H
Hackread – Cybersecurity News, Data Breaches, AI and More
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
云风的 BLOG
云风的 BLOG
F
Fortinet All Blogs
罗磊的独立博客
小众软件
小众软件
A
About on SuperTechFans
MyScale Blog
MyScale Blog
D
DataBreaches.Net
The GitHub Blog
The GitHub Blog
C
Check Point Blog
L
LangChain Blog

博客园 - aqi00

鸿蒙版本的JSBridge兼容与安卓配套的H5啦 15天学会AI应用开发(二十)使用LangChain实现RAG检索功能 15天学会AI应用开发(十九)使用LangGraph实现持久记忆功能 鸿蒙版本的小小机器人APP开放源码啦 15天学会AI应用开发(十八)使用LangGraph实现精确记忆功能 15天学会AI应用开发(十七)使用LangGraph实现会话记忆功能 15天学会AI应用开发(十六)LangChain实现对话记忆功能 15天学会AI应用开发(十五)使用LangChain封装AI执行链 15天学会AI应用开发(十四)搭建LangChain的开发环境 15天学会AI应用开发(十三)上下文与RAG的阶段性总结 15天学会AI应用开发(十二)从PDF、WORD、网页构建RAG 15天学会AI应用开发(十一)从TXT文件构建RAG知识库 15天学会AI应用开发(十)把文本嵌入模型换成国产模型 15天学会AI应用开发(九)利用Chroma持久化向量数据 15天学会AI应用开发(八)使用向量数据库实现RAG功能 15天学会AI应用开发(七)有了大模型为什么还要引入RAG 15天学会AI应用开发(六)使用离线大模型对文本生成摘要 一文速览 HarmonyOS 6.1.1 推出的十个新特性 15天学会AI应用开发(五)使用AI摘要来压缩上下文消息 15天学会AI应用开发(三)把历史对话作为提示词会怎样 15天学会AI应用开发(二)为什么编写提示词这么重要 15天学会AI应用开发(一)搭建AI大模型应用开发环境 一文理清 HarmonyOS 6.0.2 涵盖的十个升级点 FFmpeg开发笔记(一百零二)国产的音视频移动开源工具FFmpegAndroid FFmpeg开发笔记(一百零一)跨平台的开源音视频移动框架MobileFFmpeg 一文速览 HarmonyOS 6.0.1 引入的十个新特性 一文读懂 HarmonyOS 6.1 带来的十大重要升级 新书《鸿蒙HarmonyOS 6应用开发:从零基础到App上线》出版啦 FFmpeg开发笔记(一百)国产的Android开源视频压缩工具VideoSlimmer FFmpeg开发笔记(九十九)基于Kotlin的国产开源播放器DKVideoPlayer
15天学会AI应用开发(四)根据Token长度截断历史对话
aqi00 · 2026-06-06 · via 博客园 - aqi00

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

历史对话内容不光要存入数据库,还要作为初始提示词发给下次新会话的大模型。太长的提示词不仅冗余,还会消耗大量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消耗)》。