2023-05-11 09:03:03 -04:00
|
|
|
# frozen_string_literal: true
|
|
|
|
|
|
|
|
RSpec.describe DiscourseAi::AiBot::OpenAiBot do
|
|
|
|
describe "#bot_prompt_with_topic_context" do
|
|
|
|
fab!(:topic) { Fabricate(:topic) }
|
|
|
|
|
|
|
|
def post_body(post_number)
|
|
|
|
"This is post #{post_number}"
|
|
|
|
end
|
|
|
|
|
|
|
|
def bot_user
|
|
|
|
User.find(DiscourseAi::AiBot::EntryPoint::GPT4_ID)
|
|
|
|
end
|
|
|
|
|
|
|
|
subject { described_class.new(bot_user) }
|
|
|
|
|
2023-10-23 02:00:58 -04:00
|
|
|
before do
|
|
|
|
SiteSetting.ai_bot_enabled_chat_bots = "gpt-4"
|
|
|
|
SiteSetting.ai_bot_enabled = true
|
|
|
|
end
|
|
|
|
|
2023-06-20 01:44:03 -04:00
|
|
|
context "when cleaning usernames" do
|
|
|
|
it "can properly clean usernames so OpenAI allows it" do
|
2023-09-14 11:50:13 -04:00
|
|
|
expect(subject.clean_username("test test")).to eq("test_test")
|
|
|
|
expect(subject.clean_username("test.test")).to eq("test_test")
|
|
|
|
expect(subject.clean_username("test😀test")).to eq("test_test")
|
2023-06-20 01:44:03 -04:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2023-05-11 09:03:03 -04:00
|
|
|
context "when the topic has one post" do
|
|
|
|
fab!(:post_1) { Fabricate(:post, topic: topic, raw: post_body(1), post_number: 1) }
|
|
|
|
|
|
|
|
it "includes it in the prompt" do
|
FEATURE: UI to update ai personas on admin page (#290)
Introduces a UI to manage customizable personas (admin only feature)
Part of the change was some extensive internal refactoring:
- AIBot now has a persona set in the constructor, once set it never changes
- Command now takes in bot as a constructor param, so it has the correct persona and is not generating AIBot objects on the fly
- Added a .prettierignore file, due to the way ALE is configured in nvim it is a pre-req for prettier to work
- Adds a bunch of validations on the AIPersona model, system personas (artist/creative etc...) are all seeded. We now ensure
- name uniqueness, and only allow certain properties to be touched for system personas.
- (JS note) the client side design takes advantage of nested routes, the parent route for personas gets all the personas via this.store.findAll("ai-persona") then child routes simply reach into this model to find a particular persona.
- (JS note) data is sideloaded into the ai-persona model the meta property supplied from the controller, resultSetMeta
- This removes ai_bot_enabled_personas and ai_bot_enabled_chat_commands, both should be controlled from the UI on a per persona basis
- Fixes a long standing bug in token accounting ... we were doing to_json.length instead of to_json.to_s.length
- Amended it so {commands} are always inserted at the end unconditionally, no need to add it to the template of the system message as it just confuses things
- Adds a concept of required_commands to stock personas, these are commands that must be configured for this stock persona to show up.
- Refactored tests so we stop requiring inference_stubs, it was very confusing to need it, added to plugin.rb for now which at least is clearer
- Migrates the persona selector to gjs
---------
Co-authored-by: Joffrey JAFFEUX <j.jaffeux@gmail.com>
Co-authored-by: Martin Brennan <martin@discourse.org>
2023-11-21 00:56:43 -05:00
|
|
|
prompt_messages = subject.bot_prompt_with_topic_context(post_1, allow_commands: true)
|
2023-05-11 09:03:03 -04:00
|
|
|
|
2023-05-23 09:08:17 -04:00
|
|
|
post_1_message = prompt_messages[-1]
|
2023-05-11 09:03:03 -04:00
|
|
|
|
|
|
|
expect(post_1_message[:role]).to eq("user")
|
2023-06-20 01:44:03 -04:00
|
|
|
expect(post_1_message[:content]).to eq(post_body(1))
|
|
|
|
expect(post_1_message[:name]).to eq(post_1.user.username)
|
2023-05-11 09:03:03 -04:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
context "when prompt gets very long" do
|
|
|
|
fab!(:post_1) { Fabricate(:post, topic: topic, raw: "test " * 6000, post_number: 1) }
|
|
|
|
|
|
|
|
it "trims the prompt" do
|
FEATURE: UI to update ai personas on admin page (#290)
Introduces a UI to manage customizable personas (admin only feature)
Part of the change was some extensive internal refactoring:
- AIBot now has a persona set in the constructor, once set it never changes
- Command now takes in bot as a constructor param, so it has the correct persona and is not generating AIBot objects on the fly
- Added a .prettierignore file, due to the way ALE is configured in nvim it is a pre-req for prettier to work
- Adds a bunch of validations on the AIPersona model, system personas (artist/creative etc...) are all seeded. We now ensure
- name uniqueness, and only allow certain properties to be touched for system personas.
- (JS note) the client side design takes advantage of nested routes, the parent route for personas gets all the personas via this.store.findAll("ai-persona") then child routes simply reach into this model to find a particular persona.
- (JS note) data is sideloaded into the ai-persona model the meta property supplied from the controller, resultSetMeta
- This removes ai_bot_enabled_personas and ai_bot_enabled_chat_commands, both should be controlled from the UI on a per persona basis
- Fixes a long standing bug in token accounting ... we were doing to_json.length instead of to_json.to_s.length
- Amended it so {commands} are always inserted at the end unconditionally, no need to add it to the template of the system message as it just confuses things
- Adds a concept of required_commands to stock personas, these are commands that must be configured for this stock persona to show up.
- Refactored tests so we stop requiring inference_stubs, it was very confusing to need it, added to plugin.rb for now which at least is clearer
- Migrates the persona selector to gjs
---------
Co-authored-by: Joffrey JAFFEUX <j.jaffeux@gmail.com>
Co-authored-by: Martin Brennan <martin@discourse.org>
2023-11-21 00:56:43 -05:00
|
|
|
prompt_messages = subject.bot_prompt_with_topic_context(post_1, allow_commands: true)
|
2023-05-11 09:03:03 -04:00
|
|
|
|
2023-05-20 03:45:54 -04:00
|
|
|
# trimming is tricky... it needs to account for system message as
|
|
|
|
# well... just make sure we trim for now
|
2023-05-23 09:08:17 -04:00
|
|
|
expect(prompt_messages[-1][:content].length).to be < post_1.raw.length
|
2023-05-11 09:03:03 -04:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
context "when the topic has multiple posts" do
|
2023-10-23 02:00:58 -04:00
|
|
|
let!(:post_1) { Fabricate(:post, topic: topic, raw: post_body(1), post_number: 1) }
|
|
|
|
let!(:post_2) do
|
2023-05-11 09:03:03 -04:00
|
|
|
Fabricate(:post, topic: topic, user: bot_user, raw: post_body(2), post_number: 2)
|
|
|
|
end
|
2023-10-23 02:00:58 -04:00
|
|
|
let!(:post_3) { Fabricate(:post, topic: topic, raw: post_body(3), post_number: 3) }
|
2023-05-11 09:03:03 -04:00
|
|
|
|
|
|
|
it "includes them in the prompt respecting the post number order" do
|
FEATURE: UI to update ai personas on admin page (#290)
Introduces a UI to manage customizable personas (admin only feature)
Part of the change was some extensive internal refactoring:
- AIBot now has a persona set in the constructor, once set it never changes
- Command now takes in bot as a constructor param, so it has the correct persona and is not generating AIBot objects on the fly
- Added a .prettierignore file, due to the way ALE is configured in nvim it is a pre-req for prettier to work
- Adds a bunch of validations on the AIPersona model, system personas (artist/creative etc...) are all seeded. We now ensure
- name uniqueness, and only allow certain properties to be touched for system personas.
- (JS note) the client side design takes advantage of nested routes, the parent route for personas gets all the personas via this.store.findAll("ai-persona") then child routes simply reach into this model to find a particular persona.
- (JS note) data is sideloaded into the ai-persona model the meta property supplied from the controller, resultSetMeta
- This removes ai_bot_enabled_personas and ai_bot_enabled_chat_commands, both should be controlled from the UI on a per persona basis
- Fixes a long standing bug in token accounting ... we were doing to_json.length instead of to_json.to_s.length
- Amended it so {commands} are always inserted at the end unconditionally, no need to add it to the template of the system message as it just confuses things
- Adds a concept of required_commands to stock personas, these are commands that must be configured for this stock persona to show up.
- Refactored tests so we stop requiring inference_stubs, it was very confusing to need it, added to plugin.rb for now which at least is clearer
- Migrates the persona selector to gjs
---------
Co-authored-by: Joffrey JAFFEUX <j.jaffeux@gmail.com>
Co-authored-by: Martin Brennan <martin@discourse.org>
2023-11-21 00:56:43 -05:00
|
|
|
prompt_messages = subject.bot_prompt_with_topic_context(post_3, allow_commands: true)
|
2023-05-11 09:03:03 -04:00
|
|
|
|
2023-05-23 09:08:17 -04:00
|
|
|
# negative cause we may have grounding prompts
|
|
|
|
expect(prompt_messages[-3][:role]).to eq("user")
|
2023-06-20 01:44:03 -04:00
|
|
|
expect(prompt_messages[-3][:content]).to eq(post_body(1))
|
|
|
|
expect(prompt_messages[-3][:name]).to eq(post_1.username)
|
2023-05-11 09:03:03 -04:00
|
|
|
|
2023-05-23 09:08:17 -04:00
|
|
|
expect(prompt_messages[-2][:role]).to eq("assistant")
|
|
|
|
expect(prompt_messages[-2][:content]).to eq(post_body(2))
|
2023-05-11 09:03:03 -04:00
|
|
|
|
2023-05-23 09:08:17 -04:00
|
|
|
expect(prompt_messages[-1][:role]).to eq("user")
|
2023-06-20 01:44:03 -04:00
|
|
|
expect(prompt_messages[-1][:content]).to eq(post_body(3))
|
|
|
|
expect(prompt_messages[-1][:name]).to eq(post_3.username)
|
2023-05-11 09:03:03 -04:00
|
|
|
end
|
|
|
|
end
|
|
|
|
end
|
|
|
|
end
|