AI机器人在上次更新后停止响应

[aas]

Discourse 版本：v3.3.0.beta6
AI 版本：9d887ad4

• 与机器人开始对话时，我选择哪个模型都无所谓
• 我可以在 ai_api_audit_logs 表中看到成功的请求。
  • 当用户开始对话时，唯一进行的 LLM 调用是 title bot 调用（“你是 titlebot。给定一个主题，你将想出一个标题。\n你永远只会回应 7 个词的主题标题。”）
  • 机器人更新标题但没有响应
• 对我们提供商的请求运行正常 - Discourse AI 根本没有尝试进行调用

这是对话的截图：

请注意机器人响应为空。

从日志中可以看到，只有一个 bot_title 调用，而没有 bot 日志。

这是角色的设置

[Falco]

当您转到 /admin/plugins/discourse-ai/ai-llms 并在此 LLM 上点击 Test 时会发生什么？

[aas]

如果您指的是点击某个 LLM旁边的 Edit，然后向下滚动并点击 Run Test，那么对于所有启用的 LLM（anthropic 和 openai），我都会收到成功消息。

[sam (Sam Saffron)]

/logs 中有什么吗？

[aas]

哎呀，确实有！Job exception: DiscourseAi::Completions::Llm::UNKNOWN_MODEL

Message (30 copies reported)

Job exception: DiscourseAi::Completions::Llm::UNKNOWN_MODEL

Backtrace

/var/www/discourse/plugins/discourse-ai/lib/completions/llm.rb:129:in `proxy'
/var/www/discourse/plugins/discourse-ai/lib/ai_bot/personas/persona.rb:155:in `craft_prompt'
/var/www/discourse/plugins/discourse-ai/lib/ai_bot/bot.rb:54:in `reply'
/var/www/discourse/plugins/discourse-ai/lib/ai_bot/playground.rb:426:in `reply_to'
/var/www/discourse/app/jobs/regular/create_ai_reply.rb:18:in `execute'
/var/www/discourse/app/jobs/base.rb:305:in `block (2 levels) in perform'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rails_multisite-6.0.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.0.0/lib/rails_multisite/connection_management.rb:21:in `with_connection'
/var/www/discourse/app/jobs/base.rb:292:in `block in perform'
/var/www/discourse/app/jobs/base.rb:288:in `each'
/var/www/discourse/app/jobs/base.rb:288: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'

env:

hostname	forum-app
process_id	2575726
application_version	a4bfe8adb4aae3e8049ce5e7122ba01f4db1bdb5
current_db	default
current_hostname	community.ankihub.net
job	Jobs::CreateAiReply
problem_db	default
time	5:15 pm
opts	
post_id	334872
bot_user_id	-121
persona_id	1
current_site_id	default

[sam (Sam Saffron)]

尝试在 persona 中选择另一个默认 LLM，保存，重新加载，然后再次选择 Claude 3.5 Sonnet

这可能与迁移有关。

[aas]

我已将此角色的默认模型更改为 gpt-4o。我尝试与机器人开始私信，但不起作用。将默认模型切换回 claude 3.5 sonnet，但仍然不起作用。我还尝试禁用并重新启用该角色。

我尝试使用使用 claude 3.5 sonnet 的另一个角色进行私信，并且运行正常。这两个角色之间的一个区别是，那个不起作用的角色有一个关联的用户。另一个角色没有，并使用自动创建的 claude-3-5-sonnet 用户进行响应。

我想我应该删除并重新创建损坏的角色？但是，损坏的角色使用了上传的文档。如果我删除损坏的角色，与之关联的来自上传文档的嵌入是否会从 postgres 中删除？我不介意重新生成嵌入，因为这很便宜。

[aas]

我刚刚更新到 Discourse 3.4.0.beta1 和 Discourse AI 36ce88f3，但它仍然无法工作。我猜我会删除并重新创建损坏的 persona。

[aas]

对于任何偶然发现此信息的人，我可以确认删除并重新创建 persona 即可解决此问题。此外，删除一个人确实会删除 rag_document_fragments 和 ai_document_fragment_embeddings 表中相关的条目。