如果只看项目名“Between Tokens”会让人以为又是一个 LLM 推理框架或 API 封装工具。但这个项目特殊的地方在于它是一个交互式作品核心不是“调用语言模型”而是让你成为语言模型本身。换句话说它把 LLM 的 token 预测过程拆开让你站在模型的位置上面对上一段文本自己决定下一个 token 应该是什么。看到候选 token、试着理解上下文、猜测概率分布、体会“看似合理但又不确定”的生成感受——这一整套体验就是这个项目的核心内容。这篇文章会做几件事先说明这个交互作品在模拟什么再把体验过程拆成可验证的步骤最后结合 tokenizer、采样策略、上下文窗口这些真实模型概念讲清楚它为什么值得玩、怎么玩、以及玩的过程中能学到什么。无论你是刚开始学 transformer 的开发者还是日常在调 Prompt 的 LLM 应用工程师这个作品都能提供一个非常直观的“模型视角”。1. 核心能力速览从标题和项目形态来看“Between Tokens”是一个偏向教育实验性质的 Web 交互项目而不是一个需要显存、需要模型权重才能跑的推理项目。先给一份速览表方便判断它适不适合你。能力项说明项目类型交互式 AI 实验作品模拟语言模型生成过程运行方式浏览器 Web 页面通常无需安装重型依赖硬件需求极低普通电脑、平板均可运行不需要独立 GPU显存需求无推理过程由用户完成不加载真实 LLM主要体验扮演语言模型在给定上下文中选择下一个 token学习价值理解 token、上下文窗口、采样策略、生成不确定性接口 API从项目本身看是交互作品不提供业务 API批量任务不适合批处理但可以通过多次实验对比生成行为适合场景LLM 原理学习、提示词工程教学、技术科普、开发者内省工具这里要说明一点由于项目本身是交互式网页不涉及本地模型推理所以你看不到显存占用、CUDA 版本、PyTorch 依赖这类传统部署问题。反而是它的浏览器性能和交互设计更值得关注。“运行门槛低”是这个项目最大的友好之处。2. 这个作品到底在模拟什么要理解“你成为语言模型”这件事得先回到 LLM 生成文本的最基本逻辑。2.1 语言模型的本质是“预测下一个 token”现代大语言模型不管参数是 7B 还是 70B训练目标都是给定一段 token 序列预测下一个 token 的概率分布。生成过程本质上是把预测出的 token 拼接到已有序列后面再继续预测下一个循环往复直到遇到结束标记或达到最大长度。例如模型看到今天天气真它可能在 token 候选里给出“好”“不错”“糟糕”“适合出门”等不同概率。最终选择哪个取决于概率大小和采样策略。这个“在每个位置做选择”的过程就是“Between Tokens”想让你亲身体验的核心。2.2 用户扮演模型时的选择压力在真实模型里每一步选择背后有庞大的概率分布模型“知道”所有候选 token只是概率高低不同。而作为人类的你在面对一段上下文时也会产生“最可能的下一个词”的判断。这个判断来自你对语言模式、常识和上下文的直觉。这个作品把这种直觉摆到了台面上。它会给你一段文本、几个候选 token要求你用人类直觉模拟模型的概率判断。这时候你会发现两件事第一语言生成没有唯一正确答案。很多位置有多个合理选择真实模型只是给它们不同的概率。第二人类的选择非常依赖上下文长度。上下文给得越充分你越容易做出稳定判断上下文越短选择越像盲猜。这正是 LLM 上下文窗口对生成质量影响的直观体现。2.3 体验“模型视角”为什么有价值平时我们使用 ChatGPT 或各类开源模型时视角是“用户”输入指令然后看输出。这个作品提供了一个罕见的反向视角你是生成者你面对的是不完整的上下文和不确定的未来。这种视角转换有几个实际价值你会更理解为什么模型会“胡说八道”。当你站在生成位置看到候选 token 各有道理时就能明白幻觉很多时候来自概率采样而不是模型“故意犯错”。你会更理解 temperature、top-k、top-p 这些采样参数的作用。不同参数会影响候选 token 的选择宽度而你在交互中做出的选择其实就是在扮演“特定采样策略下的模型”。你会更理解提示词工程质量。为什么指令要写清楚、上下文要补充完整因为下一个 token 的预测难度直接取决于上下文信息量是否足够。3. 交互设计的技术拆解虽然目前公开材料不算多但从这类交互作品的设计范式出发可以梳理出几个关键模块它们分别映射了真实 LLM 推理链路中的不同环节。3.1 上下文窗口幕布上的可见 token 序列真实 LLM 有上下文窗口限制比如 4096、8192 token超出部分会被截断或压缩。交互作品会把这个限制可视化你只能在可见的上下文范围内做判断看不到“窗口之外”的信息。这种设计迫使你像一个真正被截断上下文的模型那样工作只根据可见内容做预测。你可能会体验到一个很真实的挫败感——上下文信息不够时候选 token 看起来都像正确答案选哪个都没有把握。3.2 候选 token 列表模拟概率分布模型每一步会为整个词表生成概率但交互作品不可能让你在几万个 token 里选一个。它会选出几个概率最高的候选 token 展示给你并在设计中暗示概率差异。你选择的过程实际上是在模拟一个已经经过 top-k 过滤的语言模型。你的直觉是哪条路径“更顺”就相当于给一个 token 赋予了更高的采样权重。3.3 生成序列反馈预测结果的累积真实语言模型生成是自回归的前一个选择会影响后面所有选择。交互作品通常会保留你的选择轨迹形成一段由你“生成”的文本。这段文本不一定像人写的但能看出你的选择逻辑也能暴露你在上下文理解上的偏差。从工程角度看这部分设计非常接近一个简化版的 transformer 解码流程输入上下文、选 token、拼接、再输入、再选择。它把“概率分布采样”替换成了“人的选择”其余流程保持一致。4. 运行环境与启动准备既然这是一个 Web 交互作品运行环境的要求非常低。你不需要安装 CUDA、不需要下载模型权重、不需要考虑显存占用。下面给一个通用的环境检查清单和启动思路具体文件结构需要以你获取到的项目为准。4.1 环境检查清单检查项建议操作系统Windows / macOS / Linux 均可浏览器建议使用最新版 Chrome、Edge、Firefox、Safari网络首次加载静态资源需要网络后续可离线体验Python如果项目需要本地构建建议 Python 3.9 以上Node.js如果项目使用前端框架建议 Node.js 16 以上显存不需要磁盘空间项目文件通常很小预留 200MB 足够需要说明的是如果你拿到的只是在线网页版那就连环境都省了直接打开浏览器地址就能用。如果拿到的是源码仓库则需要按 README 说明安装依赖并启动本地服务。4.2 本地启动命令模板如果项目是基于 Node.js 的前端工程通常启动方式类似# 安装依赖实际命令以项目 README 为准 npm install # 启动开发服务 npm run dev如果项目是 Python 静态服务也可以用最简单的 HTTP 服务# 在项目目录下启动静态服务8000 换成你喜欢的端口即可 python3 -m http.server 8000然后浏览器访问http://localhost:8000这类项目的共同点是启动轻量不会有“模型加载中”的长等待。如果打开后页面长时间空白优先检查浏览器控制台报错以及静态资源路径是否正确。5. 功能测试与效果验证虽然是交互作品但依然可以用“测试用例”的方式系统体验。下面给出一套验证流程帮助你判断项目运行正常、以及体验是否达到预期。5.1 测试一页面加载与基础交互测试目的确认项目能正常加载核心交互组件可点击。操作步骤在浏览器中打开项目地址。观察页面是否出现上下文文本、候选 token 区域和选择按钮。随机点击一个候选 token。观察页面是否进入下一步并刷新上下文。预期结果页面无长时间白屏。点击候选 token 后上下文得到更新新的候选项出现。浏览器开发者工具中没有明显的 JavaScript 报错。判断标准能连续完成 10 次以上的 token 选择说明项目基本可用。常见失败原因浏览器版本过旧不支持项目使用的现代 JavaScript API。静态资源文件缺失控制台报 404 错误。5.2 测试二不同上下文长度下的选择稳定性测试目的验证“上下文信息量影响预测难度”这一核心体验。操作步骤找到项目中最短的上下文起始位置。记录自己在候选 token 上的选择偏好和犹豫程度。等上下文累积变长后再次做选择。对比前后两次选择的确定感。预期结果上下文越长你越能快速排除不合理的候选 token。上下文越短选择越困难多个候选看起来都是“合理的下一个”。判断标准如果你能明显感受到这种不确定性差异说明项目成功模拟了模型生成时面临的信息不足问题。参考观察指标上下文长度候选数平均犹豫时间正确率感受短上下文4 个左右高低中上下文4 个左右中中长上下文4 个左右低高数值会因人而异重点是比较你自己的相对差异。5.3 测试三生成结果的累积效果测试目的观察每一次选择如何影响最终生成序列。操作步骤从头开始完整走完一轮生成。在开始阶段选择一个“非最自然”的 token。后续继续按照最自然的理解选择。观察最终文本是否因为初始选择偏差而走向完全不用的方向。预期结果一个早期 token 的选择偏差会使整段生成文本偏离“最初的最优路径”。同样的上下文换一个用户操作生成结果完全不同。判断标准如果你用两种不同策略跑出两段差异明显的文本说明自回归生成中的“误差累积”被成功体现。这个测试对应到实际 LLM 工程里就是解码过程中的级联效应。这也是为什么 beam search、多次采样再筛选等策略会被用在正式场景。5.4 测试四观察性测试与浏览器性能测试目的评估项目在普通设备上的流畅度。操作步骤打开浏览器开发者工具切到 Performance 面板。连续进行多轮 token 选择。记录页面帧率和大规模重排是否频繁。预期结果页面动画流畅没有明显卡顿。长时间操作后浏览器内存占用不会持续暴涨。判断标准如果页面在连续 50 次交互后依然流畅说明前端实现没有性能问题。注意这种交互项目对性能要求很低。如果你在普通电脑上依然卡顿优先检查浏览器硬件加速是否关闭以及是否有其他标签页占用资源。6. 从交互作品到工程实现一个简化模拟体验完交互过程可以进一步思考如果自己实现一个“你扮演语言模型”的简化版本代码应该怎么写下面的内容是一个教学向的伪实现帮助你理解核心机制不是项目本身的源码。6.1 简化 Tokenizer先模拟一个极简 tokenizer把文本拆成 token。出于演示目的这里直接用字符切分实际项目可能按词或子词切分。# 极简 tokenizer 示例仅用于演示 token 切分概念 # 实际 LLM 使用 BPE 或 SentencePiece 等算法 def simple_tokenize(text: str): return [c for c in text] input_text In the beginning tokens simple_tokenize(input_text) print(tokens)这段代码说明了最朴素的 token 概念文本被转换成离散单元模型在这些单元上计算概率。真实模型的 token 列表要比这复杂得多但基本逻辑一致。6.2 简化采样循环用户选择 token 的过程对应模型采样。下面的代码展示一个简化采样循环将temperature和top_k参数可视化。# 简化模型采样循环说明用户扮演模型的替代过程 import random candidates [was, is, will be, had] scores [0.7, 0.2, 0.07, 0.03] def sample_token(candidates, scores, temperature1.0, top_k2): # 温度调整简单示意 adjusted [s / temperature for s in scores] # top_k 截断保留概率最高的 k 个候选 top_indices sorted(range(len(adjusted)), keylambda i: adjusted[i], reverseTrue)[:top_k] top_candidates [(candidates[i], adjusted[i]) for i in top_indices] return random.choices( [c for c, _ in top_candidates], weights[s for _, s in top_candidates] )[0] print(sample_token(candidates, scores, temperature0.8, top_k2))在“Between Tokens”这类交互作品里user choice替代了random.choices这一步。你在几个候选里做出的选择本质上就是一次采样。不同参数下模型的“犹豫程度”不同候选范围和概率分布也会变化。6.3 生成循环真实模型生成文本不是只采样一次而是循环拼接、重复采样# 简化自回归生成循环 def generate(prompt, max_tokens5): output prompt for _ in range(max_tokens): # 返回下一个 token 和更新后的候选 next_token sample_token(candidates, scores) output next_token return output虽然这段代码很粗糙但它抓住了自回归生成的骨架每一步都在已有序列的基础上追加新 token再继续下一次预测。交互作品让你手动执行这个循环从而获得“模型视角”。7. 资源占用与性能观察由于项目不加载大型模型资源占用通常很低。但作为技术文章还是有必要说明如何观察和判断性能表现。7.1 内存占用观察方法打开浏览器开发者工具切到 Memory 面板。记录页面加载完成后的内存基线。连续完成 30 轮交互再查看内存变化。如果内存持续大幅增长可能存在事件监听器泄漏或未释放的 DOM 节点。7.2 显存与 CPU这类项目完全不依赖 GPU 和显存。即使你在一个没有独立显卡的办公电脑上也能正常运行。唯一可能出现负载的是页面动画和样式重绘这对现代浏览器的 CPU 来说没有压力。7.3 与真实 LLM 推理的差异值得专门指出的是交互作品只模拟了“选择 token”的认知过程并没有模拟真实模型推理的计算负载。真实 LLM 在每一步选择时都要把整个上下文重新过一次神经网络前向计算候选 token 的概率分布来自数亿甚至数千亿参数的计算结果。你的“模型扮演”是在用人类大脑的语言直觉替代神经网络计算。这带来一个有趣的问题为什么人类小样本就能学会语言规律而大型模型需要海量数据和算力才能接近人类水平这个项目虽然没有直接回答这个问题但会让你更具体地感受到两者的差异。8. 体验中的常见问题与排查建议交互式网页项目的主要问题集中在浏览器兼容、加载失败和交互异常。下面给出一份排查清单。问题现象可能原因排查方式解决方案页面打开后白屏JavaScript 报错或静态资源缺失打开浏览器控制台查看报错信息检查静态资源路径或换浏览器访问点击候选 token 没有反应脚本未初始化或事件绑定失败刷新页面观察网络请求是否完成等待资源加载完成后重试页面样式错乱CSS 文件未加载检查 Network 面板中 CSS 请求状态清除浏览器缓存并刷新移动端触控无效未适配触屏事件切换到桌面模式测试优先使用桌面浏览器体验中文字符显示异常字体或编码问题检查页面 meta 字符集设置在浏览器中强制字符编码为 UTF-8长时间使用后卡顿浏览器内存占用上升查看 Memory 面板趋势刷新页面后继续体验遇到问题时最直接的方法是复制浏览器控制台里的报错信息结合项目文档去定位。对于交互作品类项目绝大多数问题都能通过换浏览器、清缓存、检查静态资源路径解决。9. 教学与实践使用建议这个项目最核心的应用场景不是生产工具而是教学和理解工具。下面给几个实际使用建议。9.1 在 LLM 原理课上做演示如果你在带学生或新人入门 LLM传统的 PPT 讲解很难说清楚“预测下一个 token”是什么感觉。让学生亲手上手体验一下“在候选 token 里做选择”会比五十页幻灯片更有体感。可以设计一个课堂练习不看上下文直接让学生猜测下一个 token。展示短上下文再次让学生选择。展示完整上下文第三次选择。对比三次准确率让学生理解上下文信息量对预测的影响。9.2 用于提示词工程的效果演示如果你经常和提示词工程打交道这个项目可以帮你在团队内部做一次“换位思考”培训当模型面对信息不足的提示词时它本质上和这个交互体验一样只能在低概率判断下做选择。培训时可以这样引导一段模糊的任务指令对应的是上下文不足时的模型状态。补充清晰约束、示例、背景信息后模型相当于获得了更长的上下文预测成功率自然上升。因此写提示词的本质是提升模型在每个 token 位置上的预测置信度。9.3 作为 Prompt 写作“内省工具”对于经常写 Prompt 的工程师来说这个作品也可以当作一个“内省工具”。当你感觉自己像模型一样面对一堆候选词不知所措时就会意识到“哦原来模型是这种体验”。这种直觉对诊断模型输出质量不高的问题很有帮助能让你更快想到补充上下文、降低温度、提高格式约束等方案。9.4 注意使用边界这类项目使用上不存在明显安全风险但在教学传播时需要注意两点第一不要把它当作真实 LLM 的准确模拟。它是对生成机制的简化表达真正理解语言模型仍需要学习 transformer、注意力机制、训练目标等概念。第二如果要截图、录屏或二次创作传播注意查看项目协议开源项目通常会注明许可证类型。尊重作者版权尤其不要去掉作者署名。10. 总结与下一步“Between Tokens”不是一个需要显存、需要大量依赖才能跑起来的重项目但它提供了一个非常稀缺的视角把语言模型生成过程变成你的亲身经历。最值得尝试的点有三个一是体验上下文长短对预测难度的直接影响二是感受候选 token 之间“各有道理”的不确定性三是用自己的选择轨迹回看生成结果理解自回归生成中误差累积的必然性。如果你打算上手体验第一步不是找教程而是先打开页面完整走完一轮生成。中途有意识地变更选择策略观察最终文本的变化。然后回头来看核心概念比如 temperature、top-k、beam search。最容易踩的坑不是环境而是心态——不要把它当成“游戏”来追求高分。它的价值不来自“选对 token”而来自“发现正确与否很多时候并不存在”——生成文本本来就有一条充满不确定性的路径这就是语言模型工作的真实样貌。下一步可以做的事有很多如果你对 tokenizer 感兴趣可以系统学习 BPE、SentencePiece如果你对采样策略感兴趣可以看看 Hugging Face Transformers 里 generate 方法的 temperature、top_k、top_p 参数如果你想深入研究生成级联效应可以阅读有关 beam search 和采样权衡的工程文章。这个项目把“语言模型到底是什么”这个问题从抽象公式变成了具体体验。哪怕你只花十分钟玩完再去看语言模型的推理原理也会多一层“原来如此”的实感。
