-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[A/B] Changes to the RAG functionality #630
Conversation
|
||
return { | ||
"size": env.ai.rag_k, | ||
"size": params["size"], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"size": params["size"], | |
"size": env.ai.rag_k or params["size"], |
or i f we arent using env.ai we should remove it (but i think its probably a good idea)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As discussed, these are added in the default params further down the function, so definitely still used and I think we should keep them for now.
{ | ||
"knn": { | ||
"field": "embedding", | ||
"query_vector": vector, | ||
"num_candidates": env.ai.rag_num_candidates, | ||
"filter": knn_filter, | ||
"num_candidates": params["num_candidates"], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
as above
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so below
{ | ||
"match": { | ||
"text": { | ||
"query": query["question"], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
not for now but we should think about aliases for summary/summarise etc
@@ -147,7 +147,19 @@ def get_routable_chains( | |||
ChatRoute.ability: build_static_response_chain(ABILITY_RESPONSE, ChatRoute.ability), | |||
ChatRoute.coach: build_static_response_chain(COACH_RESPONSE, ChatRoute.coach), | |||
ChatRoute.gratitude: build_static_response_chain("You're welcome!", ChatRoute.gratitude), | |||
ChatRoute.retrieval: retrieval_chain, | |||
ChatRoute.summarisation: summary_chain, | |||
ChatRoute.search: retrieval_chain, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These changes will need to be reflected in the Django app, in the ChatRoute
enum.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd like to remove this enum from the frontend and just hold it as a string. An advantage of keywords is we can quickly add and remove them to test stuff, and doing this as an enum in the front will mean a db migration every time this happens because keywords and routes are currently bound together.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We'll rue this one day, you mark my words. But if you must, you must.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like the migration has been put in to handle route as a string in Django? Is this thread resolved?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you rebase and run the integration tests? The looks good to me.
https://github.com/i-dot-ai/redbox-copilot/actions/runs/9659121995 this is working locally for me |
Context
We want to split test two paths for the RAG functionality:
@search
is the standard@supasearch
implements a higher k, similarity threshold and hybrid search with a boosted similarity weightNote I also change the keywords we use to make them a bit nicer for users, and remove the enum for keywords in the frontend.
Note I haven't put in a unit test because this is about lightweight experimentation.
Changes proposed in this pull request
@supasearch
route@summarisation
to@summarise
to enable people to say things like "@summarise the people in these docs"@retrieval
to@search
to enable people to say things like "@search which type of energy saw the largest spike in prices"Guidance to review
Relevant links
Things to check