-
Notifications
You must be signed in to change notification settings - Fork 64
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
(EAI-179): Verified answers on server #348
Conversation
packages/mongodb-chatbot-server/src/processors/makeDefaultFindVerifiedAnswer.ts
Outdated
Show resolved
Hide resolved
packages/mongodb-chatbot-server/src/processors/makeVerifiedAnswerGenerateUserPrompt.ts
Show resolved
Hide resolved
packages/mongodb-chatbot-server/src/processors/makeVerifiedAnswerGenerateUserPrompt.ts
Show resolved
Hide resolved
deeedf2
to
88a05b9
Compare
ac1a9e3
to
3e87d36
Compare
packages/mongodb-chatbot-server/src/processors/makeVerifiedAnswerGenerateUserPrompt.ts
Outdated
Show resolved
Hide resolved
if (metadata) { | ||
dataStreamer.streamData({ | ||
type: "metadata", | ||
data: metadata, | ||
}); | ||
} |
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 think currently we'll only stream a metadata
event for verified answers, right? Do we need any conditional handling for delta streaming (immediately below this block) in the case of verified answers?
Or, is the idea that the metadata
event is used solely to indicate that any delta events until the next finished
event is a verified answer?
I ask because it looks like the metadata
payload will include the verified answer text in its entirety so we don't technically need to stream deltas on top of it.
If we were to use that though then I think a type like static
with a subtype of VerifiedAnswer
might be more direct.
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.
Yeah, I made it flexible because verified answers is only one of many possible 'meta info needed' type of responses.
I should put metadata response below, wasn't as clear exactly where/how to get it though (since the generate message is a bit more complicated). Will look into it.
I included the entire verified answer object for simplicity, but I wouldn't rely on it. I can strip it down to just the essential info.
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.
is mongodb-verified-answers
a package that we should publish? also nit on naming, think it should be mongodb-chatbot-verified-answers
for consistency w/ other package names
packages/mongodb-chatbot-server/src/processors/makeDefaultFindVerifiedAnswer.ts
Show resolved
Hide resolved
continuation: GenerateUserPromptFunc; | ||
} | ||
|
||
export const makeVerifiedAnswerGenerateUserPrompt = ({ |
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.
think a doc comment on top of the constructor function would be good too.
high level overview of what this GenerateUserPrompt func does. namely:
- try to find verified answer for user query
- if cannot find, proceed to use the other GenerateUserPrompt func
connectionUri, | ||
databaseName, | ||
}); | ||
const collection = db.collection<VerifiedAnswer>("verified_answers"); |
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 make the collection name an optional passable param w/ this as the default name?
i think we should move to that as the default pattern for these stores. we can add the same logic to the other stores as well.
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 great. nice addition. a few comments throughout, mostly docs related.
if you don't want to include the full documentation on the docs site in this PR b/c you're time limited, we can split it into a separate ticket/PR.
…ween metadata and customData
const VERIFIED_ANSWERS_CONNECTION_NAME = | ||
process.env.VERIFIED_ANSWERS_CONNECTION_NAME ?? "verified_answers"; |
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.
const VERIFIED_ANSWERS_CONNECTION_NAME = | |
process.env.VERIFIED_ANSWERS_CONNECTION_NAME ?? "verified_answers"; | |
const VERIFIED_ANSWERS_COLLECTION_NAME = | |
process.env.VERIFIED_ANSWERS_COLLECTION_NAME ?? "verified_answers"; |
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 don't think we should do the optionality here since it's our implementation. either it's provided or it isn't and we throw an err.
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.
also per below comment, i think we can include a default collection name in the MongoDBVerifiedAnswerStore.ts
file, removing the need for declaring collection name here.
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.
Whoops...
I see what you mean though, we can just not put it in the env then and hardcode it here.
collectionName, | ||
}: MakeMongoDbDatabaseConnectionParams & { | ||
collectionName: string; |
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.
collectionName, | |
}: MakeMongoDbDatabaseConnectionParams & { | |
collectionName: string; | |
collectionName = "verified_answers", | |
}: MakeMongoDbDatabaseConnectionParams & { | |
collectionName?: string; |
could we do default value here?
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.
One problem with optional arguments: developers forget to pass the variable down and just use the default...
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 % few small things about collection name in comments
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.
Do we need to add tests for the case where this route returns a verified answer?
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 effectively already do via existing static response ("no answer found") tests.
For sure though the tests could be improved if we want to set up fake verified_answers to work with in the test database. Can do as a follow-on later.
Jira: https://jira.mongodb.org/browse/EAI-179
Changes
TODO
Documentation/README updates🔜 https://jira.mongodb.org/browse/EAI-263