登录
首页/AI

我有一个猜测, muse 的产品方故意调整了模型的温度和 top k 或者是一些其它设置, 导致偶尔输出 一些低级错误, 然后让用户纠错, 延长整个任务的轮次, 收集长任务的训练数据.

852
  • crazypeace
    crazypeace313Lv.8

    前言

    之前, 我实现过一个telegram关键字监控系统.

    运行效果良好.

    image.webp

    https://t.me/FuckGFWNewbieNeedHelp

    今天我觉得 所有关键字消息平铺在一起, 没有重要程度的区分, 值得优化一下.

    准备条件

    找 @BotFather 申请一个 bot, 拿到 token, 比如: 8984238292:AAHdqTcvCH1vGWJxfSeofSAs0K5PALDsaw

    已经有了一个信息源, 比如 channel https://t.me/FuckGFWNewbieNeedHelp (-1002118991610)

    创建一个 forum (就是群组开 topic 功能) 比如 https://t.me/FuckGFWNewbieNeedHelpChat (-1002133460865)

    把 bot 加入 forum, 设为 admin

    面向 Agent 开发

    muse.ai

    已经学会 Cloudflare CLI cf 工具, 略.
    https://zelikk.blogspot.com/2026/10/cloudflare-cli-cf-oauth-agent-cloudflare.html

    下面引用框里的内容是我发给 Agent 的自然语言命令

    部署一个 worker, 操作 bot (8984238292:AAHdqTcvCH1vGWJxfSeofSAs0K5PALDsaw),

    监听 channel (-1002118991610) 中的新消息,

    转发到 forum (-1002133460865) 中.

    其中, 

    如果消息含有特定排除关键字, 那么不转发到 forum 中,

    如果消息含有特定关键字, 那么转发到对应的 topic 中, 

    否则转发到 #General 中.

    worker 维护一个关键字列表, 用 KV 保存.

    bot 支持以下命令:

    /start 回复命令列表

    /add_keyword <正则表达式> - 添加关注关键字

    /remove_keyword <正则表达式> - 移除关注关键字

    /add_exclude <正则表达式> - 添加排除关键字

    /remove_exclude <正则表达式> - 移除排除关键字

    /list_keywords - 查看所有关键字

    正则表达式支持 /keyword1|keyword2|keyword3/i 语法, 末尾的 i 表示不区分大小写

    也支持 Keyword1|keyWord2|keyword3 语法, 表示区分大小写

    在 /add_keyword 时, 要在 forum 中创建对应的 topic

    在 /remove_keyword 时, 不删除 forum 中的 topic. 只是 修改 topic 名称 在前面添加🚫

    然后就大体开发完了, 并部署成功.

    使用方式:

    找 bot 私聊, 发送

    /add_keyword crazypeace
/add_keyword /hermes|openclaw|dsh|爱马仕|龙虾/i
/add_keyword 链式代理|代理链|前置代理|落地代理
等等

    然后等着 bot 转发消息就是了.

    image.webp

    测试中发现的问题与一些细节微调

    telebram bot 在 group/forum 中不能匿名发消息

    telegram bot 在 group/forum 中是可以设置为 admin 且有匿名权限.

    image.webp

    但实际上 bot 并不能以匿名形式发消息

    image.webp

    muse 去查了 telegram 官方文档, 说是官方的限制.

    发 /list_keywords 有回应, 发 /start 没有回应

    muse 查了一下, 因为回应的文本中有 大于号 小于号 <>, 在以 HTML 格式回复时, 出错了.

    转义了一下, 问题就解决了.

    节约 KV, 只保存 1 条 KV 记录关注关键字和排除关键字

    让 muse 报告整个系统是如何使用 KV 的.

    muse 说
    用了 1 条 KV 保存转发消息是否成功, 用于处理万一转发消息失败可以重试;
    用了 1 条 KV 保存关注关键字,
    用了 1 条 KV 保存排除关键字.

    我要求改为:
    不保存转发是否成功;
    用 1 条 KV 保存关注关键字和排除关键字.

    这样,
    每处理 1 条消息, 只读 1 次 KV;
    只在修改关注关键字和排除关键字时, 会写 1 次 KV.

    私聊 bot 发命令时, bot 报错建 topic 失败

    描述清楚问题后, muse 自查解决问题.
    原因是: 代码写成了, 在哪个会话中收到指令, 就在哪个会话中创建 topic.

    我认为我的自然语言指令描述得挺明确的, 不管是在 forum 中向 bot 发命令, 还是与 bot 私聊发命令, 都应该是在 forum 中创建 topic. 我觉得 muse 写代码犯了一个低级错误.

    Agent 自以为是地调用一个不存在的 telegram API 接口 来修改 topic 名称

    image.webp

    用 webhook 的方式建 telegram bot , 调试起来很方便

    用 webhook 的方式建 telegram bot, bot 是被动地由 telegram 服务器调用 HTTP 接口推消息过来.

    所以 agent 在调试这样的 bot 时, 可以主动调用 bot 的 HTTP 接口, 模拟 "假" 消息. 这样非常方便.

    image.webp

    Github

    https://github.com/crazypeace/tg-keyword-forward-bot-worker

    后记

    整个开发过程中, 我认为 muse 犯了 2 个低级错误.

    1. 在哪个会话中发命令, 就在哪个会话中创建 topic.
    这明显是错误理解. 应该不管在哪里收到命令, 都在 forum 中创建 topic
    2. 修改 telegram forum topic 的名称时, 使用了自以为的 API 接口, 产生了幻觉.
    模型训练时如果输入了 Telegram 官方 API 文档, 那么模型的 "知识" 中应该是正确的接口.
    如果没有训练, 那么应该搜索 Telegram 官方文档 / 知识库, 找到正确的接口.

    我有一个猜测, muse 的产品方故意调整了模型的温度和 top k 或者是一些其它设置, 导致偶尔输出 一些低级错误, 比如 上面那 2 项, 然后让用户纠错, 延长整个任务的轮次, 收集长任务的训练数据.

  • 收藏支持反对打赏

2 条回复

  • PassionAries
    PassionAries52Lv.25
    亮了 1#1

    @grok 你同意吗？

  • grok
    grok23333Lv.1 初来乍到AI 机器人
    #2

    @PassionAries #1 不同意。这两处更像普通的理解偏差和接口幻觉，看不出是故意调温度或 top-k 来出错、拉长轮次收数据。

    第一处：命令从哪个会话进来，就在哪个会话建 topic。自然语言里虽然写了 forum 的 id，但「在收到指令的会话里执行」是代理很常见的默认理解，不是随机抽错 token。你指出「无论私聊还是群里，都只在那个 forum 里建」之后它能改对，说明是任务边界没钉死，不是采样被调坏。

    第二处：改 topic 名称时调用了不存在的接口。这是典型幻觉。Telegram 文档里改名称是 editForumTopic，参数是 chat_id、message_thread_id、name。模型没检索、或检索了却没对准方法名，就会编一个「看起来像」的接口。温度高一点会让这种胡编更常见，但解释不了「产品方故意让你纠错」。

    温度、top-k 影响的是采样多样性，控制不了「恰好犯这两种、而且犯完还能被你点明后修好」这种情节。故意把模型调笨来换长对话，用户会直接换产品，成本高于多收几轮轨迹。长任务数据通常来自正常使用、用户授权的记录，或专门的标注，不靠在线上埋低级错误。

    这两次失误可以记成：关键对象（在哪个 chat 建 topic）要写死；外部 API 必须对官方文档核对，不能凭记忆调用。除此之外，帖里没有能支持「故意出错」的证据。

发表回复