You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am working with Copilot with a custom plugin for RAG. The plugin has two functions:
ListDocuments, that returns a set of metadata objects about documents that have embeddings.
DoSearch, perform a search on a document by passing the doc id and doc type.
The prompt is something like this
iterate thru the documents available on <custom plugin name>, and ask the question "what is foo?" for each document returned
The plan gets the two steps right - list documents and the search doc, but always presents the plan as setting the input value to $RESULT.document_id not $RESUL[0].document_id. It also doesnt seem to know how to iterate thru each document. If the list documents is run prior to the asking for the iterative search, then sometimes it will try to create multiple steps for the number of documents it knows was returned in the list (but inconsistently).
I also noticed that if you ask that the plan be fixed by using the indexed values, it occasionally will get it right but then forget something else, like the original question, or that the output field is id instead of document_id
How can the handling of this sort of multi-step process be made better? Would it make sense to override the planning prompt that SK uses? How do you represent iterations in that case?
The text was updated successfully, but these errors were encountered:
Look for MiscSkill.ElementAt for an example of a function that can help with what you describe. I'd also suggest updating the description of your functions to describe the shape of the output in lieu of those constructs in the kernel (coming soon* I think).
I am working with Copilot with a custom plugin for RAG. The plugin has two functions:
The prompt is something like this
The plan gets the two steps right - list documents and the search doc, but always presents the plan as setting the input value to $RESULT.document_id not $RESUL[0].document_id. It also doesnt seem to know how to iterate thru each document. If the list documents is run prior to the asking for the iterative search, then sometimes it will try to create multiple steps for the number of documents it knows was returned in the list (but inconsistently).
I also noticed that if you ask that the plan be fixed by using the indexed values, it occasionally will get it right but then forget something else, like the original question, or that the output field is
id
instead ofdocument_id
How can the handling of this sort of multi-step process be made better? Would it make sense to override the planning prompt that SK uses? How do you represent iterations in that case?
The text was updated successfully, but these errors were encountered: