如果作业队列很大，机器人响应可能会延迟。
我相信触发的作业也可能会延迟。
首先处理积压工作 :)。
我尝试了几次为您制定回复，但最终都失败了。如果此问题持续存在，请联系管理员，谢谢！
您需要查看原因。您的日志中应该有错误。
通过启用详细日志记录（最后一个设置）并将日志重定向到警告（在生产环境中您无法读取信息日志）来检查 AI 响应。
然后查看 /logs 中的这些内容。
这通常是因为您没有提供有效的密钥或账户余额不足，但也可能出于其他原因。
我认为我的 sidekiq 积压了很多任务。有什么方法可以增加 sidekiq 的容量以更快地处理任务吗？
这个插件的范围有点广 
结合以下几点：
- 迁移到拥有更多核心和内存的更强大的服务器。
- 增加电子邮件服务提供商的速率限制（可能）。
通常情况下，您的队列应该几乎是空的。
Chatbot: 出现了一个问题，但将重试直到达到限制：nil 无法强制转换为 Integer
这是我收到的错误
您是否：启用了聊天机器人嵌入？
想必您的机器人是RAG类型？（如果是，则必须启用上述选项）
您正在使用什么模型？
无 RAG。
gpt-4o-mini
您能在 /logs 中看到此错误的堆栈跟踪吗？
消息 (报告 4 份)
聊天机器人：出现了一个问题，但会重试直到达到限制：nil 无法强制转换为 Integer
回溯
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/broadcast_logger.rb:134:in `block in error'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/broadcast_logger.rb:231:in `block in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/broadcast_logger.rb:231:in `each'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/broadcast_logger.rb:231:in `dispatch'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/broadcast_logger.rb:134:in `error'
/var/www/discourse/plugins/discourse-chatbot/app/jobs/regular/chatbot_reply.rb:140:in `rescue in execute'
/var/www/discourse/plugins/discourse-chatbot/app/jobs/regular/chatbot_reply.rb:121:in `execute'
/var/www/discourse/app/jobs/base.rb:316:in `block (2 levels) in perform'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rails_multisite-6.1.0/lib/rails_multisite/connection_management/null_instance.rb:49:in `with_connection'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rails_multisite-6.1.0/lib/rails_multisite/connection_management.rb:21:in `with_connection'
/var/www/discourse/app/jobs/base.rb:303:in `block in perform'
/var/www/discourse/app/jobs/base.rb:299:in `each'
/var/www/discourse/app/jobs/base.rb:299:in `perform'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:202:in `execute_job'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:170:in `block (2 levels) in process'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/middleware/chain.rb:177:in `block in invoke'
/var/www/discourse/lib/sidekiq/pausable.rb:132:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/middleware/chain.rb:179:in `block in invoke'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/middleware/chain.rb:182:in `invoke'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:169:in `block in process'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:136:in `block (6 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/job_retry.rb:113:in `local'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:135:in `block (5 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq.rb:44:in `block in <module:Sidekiq>'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:131:in `block (4 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:263:in `stats'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:126:in `block (3 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/job_logger.rb:13:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:125:in `block (2 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/job_retry.rb:80:in `global'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:124:in `block in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/job_logger.rb:39:in `prepare'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:123:in `dispatch'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:168:in `process'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:78:in `process_one'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:68:in `run'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/component.rb:8:in `watchdog'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/component.rb:17:in `block in safe_thread'
结论（来自私人讨论）：配额重置作业仍未运行。
您必须先运行一次此作业，然后才能使用机器人。
目前，安装插件后，您可能需要手动触发一次。
我将尽快查看自动执行此一次性初始运行。
希望这能彻底解决问题。
3 个赞
DeepSeek 热潮 
快来加入聊天机器人 
您至少可以使用 基础 模式来访问 V3 和 R1。
我使用了：
（无联盟）
它托管了他们的模型。
设置如下：
请确保设置基础机器人模式并替换您的密钥。
但如果您能够直接访问 DeepSeek AI 网站进行注册，您或许可以直接使用 DeepSeek AI
基础 URL 将是“https://api.deepseek.com”。
4 个赞
请参阅上一篇文章，了解如何使用替代模型，特别是大型托管的开源模型。
你好 @merefield。
我的主题聊天机器人自动回复器现在会在主题中回复两次。所以当用户提问时，聊天机器人会回答，然后立即重复回答相同的问题两次。有什么办法能让它平静下来吗 
1 个赞
这很奇怪。
我刚刚在最新版本上进行了测试，每次只收到一个回复，即初始帖子 → 自动回复 → 回复 → 另一个机器人回复。
你能详细说明一下你的设置吗？因为我不确定现在是否能重现你的问题？
或者这就是你看到的行为吗？
请注意，机器人将继续响应，直到另一位用户在主题中发帖。因此，最初，当对话在用户和机器人之间进行时，机器人将始终最后发言（这已在 OP 中记录）。
有人曾打算资助对该功能进行改进，但从未支付发票，因此我们目前只能维持当前行为。
谢谢 Robert。我会尝试弄清楚一些事情。它并非总是发生。不确定这是否与回复机器人并同时提及 @bot 有关，或者是否是同一浏览器中登录和退出不同帐户的缓存问题。以为最近的更新可能出现了一些问题。我的设置也是最新的。如果我发现导致这种情况的具体情况，我会通知你。
我也测试过这个，没有触发双重回复。
帖子的评估只发生一次，如果被提及或回复，它会回复，但不应该重复。
它也不应该尝试回复自己，因为评估应该忽略机器人帖子。
如果您能提供更多关于具体情况的细节，请告诉我。
1 个赞
我找不到/看不到这个 Ai 机器人（在我的主页上显示为机器人图标）使用的是哪个 AI 模型：https://BathindaHelper.com/
也许我可以更改此机器人的 AI（模型）吗？还有哪些其他选项？
有时它会回复（说它不能回复）：
其他时候它会一直尝试回复，但从未成功：
