jevchat 将 Jev 变成一个（糟糕的）聊天机器人——功能、模式与社区反响

摘要

jevchat 是一个开源封装器，通过反复询问 “根据用户的问题和已写出的回复，下一个符号是什么？” 将 Jev API 变成一个逐轮对话的聊天机器人；它支持多种字母表、采样策略和束搜索，但这种方法成本高昂，主要是一个有趣的实验。

---

jevchat 的功能

• 在每一步生成中，jevchat 向 Jev 发送一个单选题：当前部分回复后面应该跟哪个符号？。
• Jev 返回所选字母表上的概率分布；采样器从归一化分布中抽取下一个符号。
• 该过程重复进行，直到选择特殊的 STOP 符号，从而生成最终答案。
• 该工具显示实时统计信息（符号/秒、字符/秒、每次 API 调用的延迟）以及每一步得分最高的符号，让用户实时观察分布情况。

---

安装与基本用法

# 通过 Poetry 安装依赖
poetry install

# 将你的 Jev API 密钥存储在 .env 中（或使用 JEV_API_KEY / TYPESAFE_API_KEY 环境变量）
# 示例 .env 内容：
# api_key="YOUR_KEY"

# 交互式聊天
poetry run jevchat

# 一次性查询
poetry run jevchat ask "do people need water?"

# 列出可用的字母表
poetry run jevchat alphabets

# 基准测试所有模式（会调用真实 API）
poetry run jevchat bench

按一次 Ctrl‑C 在当前请求完成后停止；按两次立即中止。

---

采样策略

策略	工作原理	典型命令
choice（默认）	对整个字母表提出一个问题。	jevchat -s choice ask "how many eyes do people have?"
choice – 不打乱顺序	禁用字母表重排（该重排可缓解 Jev 的位置偏差），产生最差情况的质量。	jevchat -s choice --no-shuffle-criteria ask "…"
choice – 集成	发送 N 个具有不同字母表顺序的并行问题，并对结果取平均。	jevchat -s choice --ensemble 4 ask "…"
bisect	递归地将字母表分成两半，提出是/否问题，直到剩余一个小分组，然后进行最终选择。	jevchat -s bisect ask "…"
bisect – 更大切分	在最终选择前增大分组大小，减少 API 调用次数。	jevchat -s bisect --bisect-cutoff 32 --no-bisect-swap ask "…"
buckets	将大字母表分成多个桶，每个桶带有 OTHER 转义；唯一支持 >255 个符号的策略。	jevchat -a bpe5k -s buckets --bucket-size 127 ask "…"
refine	使用 buckets，然后对获胜桶进行第二阶段选择，可选地随后进行核重打分。	jevchat -a words1k -s refine --refine-nucleus 6 --refine-rounds 2 ask "…"

---

呈现模式

• hypothesis（默认）：每个选项是一个 完整的 文本片段；Jev 直接对完成的字符串进行评分。这使字符字母表的 top‑1 准确率大约提升 3 倍。
• symbol：每个选项是一个单独的符号；Jev 必须在评分前想象拼接后的结果。

---

束搜索

poetry run jevchat -b 3 ask "what is the opposite of hot?"

同时保留 N 个候选回复。每个束在每一步产生一次评分，传统的 temperature/top‑p/top‑k 设置被忽略——束仅按概率排序。

---

字母表

字母表	描述	使用场景
lower26	a‑z 加空格	简单的仅字母演示
ascii	完整的可打印 ASCII	任何文本生成
tokens	整词标记	自然语言查询
words1k	1 000 个最常用词（需要 buckets）	受限词汇实验
bpe2k, bpe5k	2 k / 5 k 标记的字节对编码词汇表	更大但仍受限的词汇

---

性能亮点（来自 jevchat bench）

• 默认字母表的 choice 是最慢的，因为它为每个符号发送单独的请求。
• bisect 将 API 调用次数减少约一半，同时保持相当的质量。
• buckets 和 refine 支持超过 255 个符号的词汇表，延迟略有增加。
• 束宽 >1 会使成本线性增加（每个活动束每步一次评分），但可以提高连贯性。

---

Hacker News 上的社区反响

• Eric PrUitt 将这种体验比作 “Morty 与死亡水晶对话”——模型在观察自身消亡的同时迭代地完善其答案。
• OtherShrezzing 强调了幽默之处：模型的输出往往读起来像笑话，产生了一个真正有趣的短篇故事。
• boodleboodle 将该项目与旧想法 “BERT has a mouth and it must speak”（arXiv:1902.04094）联系起来，指出逐标记生成的传承。
• yipinwong 将系统比作一个 “多动症的重朋友”，不断在想法之间跳跃，反映了 Jev 的 System 1 风格。
• fen_wick 想知道 Jev 的结构化数据格式是有助于还是阻碍了聊天式界面的快速原型开发。
• K0IN 问为什么这种方法不能简化为简单的嵌入相似性查找，引发了对每个符号需要显式决策的讨论。
• petercooper 提出了需要严格受限词汇的实际用途（例如 SQL 生成），并报告说 jevchat 可以生成合理的查询，尽管带有 linting 的传统 LLM 仍然表现更好。
• IceDane 批评了使用 Poetry 进行 Python 打包，反映了社区中的一种普遍情绪。
• nowittyusername 提出了一个仅表情符号的机器人，指出该架构的约束可能适合非文本输出。

---

局限性与成本考虑

• 每个符号需要单独的 API 调用（或使用 ensemble 时的小批量），这使得该方法对于较长的回复 成本高昂。
• 质量因所选策略和字母表而有很大差异；默认的 choice 模式可能嘈杂，而 refine 提供了最佳权衡。
• 实时交互受网络延迟和 Jev 每符号评分开销的限制。

---

测试与可靠性

• 仓库包含 158 个离线测试，使用模拟的 HTTP 客户端和假的生成循环；这些测试不需要 API 密钥。
• jevchat bench 命令是唯一与实时 Jev 服务交互的部分，允许开发人员评估实际成本和延迟。

---

结论

jevchat 展示了语言模型可以通过反复询问 下一个符号是什么？ 被强制转换为确定性的、符号级别的聊天机器人。该项目展示了多种采样策略、字母表配置和束搜索，将 Jev 变成了一个有趣但昂贵的对话玩具。社区反馈强调了这种方法的创新性和实际限制，暗示了在严格受限词汇有利的细分应用。