-
Notifications
You must be signed in to change notification settings - Fork 129
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
[BUG] Conversational agent overwrites input from SearchIndexTool #2918
Comments
As far as I see, #2837 will fix it for
|
You are right. Feel free to raise a PR fixing it. |
@reuschling can you share your query when executing the agent? |
Hi @reuschling ! I guess you wish to somehow hardcode the search query for search index tool. Unfortunately, the tool Since you are already hardcoding the search query, I recommend you to try flow agent to first fetch the results from search index tool. You can then concatenate a ml model tool or connector tool to call the large language model. You can even specify your prompt in the ml model tool. |
I doubt whether the same fix would work. In conversational agent, we let LLM to generate input parameters and pass them into the tools. I will discuss with @jngz-es tomorrow to check whether this would introduce some breaking change. |
@reuschling Could you try my workaround? |
I want to use the conversational agent, but I want to have a tool (among others, e.g. one for hybrid search) which makes dedicated queries inside the index, such as counting documents for example. The conversational agent should give input for this, but this input should be inserted into a predefined query template, with an according parameter value reference inside. This is what the SearchIndexTool is made for. Using a flow agent instead is no solution for me. The SearchIndexTool should behave same, independent if it is used inside flow or conversational agents. Maybe then the use of the input variable for the query template definition is wrong. But I doubt it is not consistent or understandable if after merging #2837, all tools with some definitions inside the input variable will act differently dependent where they are used (flow or conversational). I.e. all tools (if there are others) with necessary input definitions currently don't work and won't work with conversational agent as these definitions will be overwritten. #2837 fixes this problem only for the flow agents. But not overwriting the input if there is already an input definition inside the tool specification would solve this also for the conversational agent. This is what #2837 do. Crucial is, that there is a possibility to get the formerly LLM generated action input inside a variable for referencing inside the query template. As |
We just have a discussion. The conclusion is that we would introduce a new field in tool settings like "configs", which works like hardcode parameters. |
This sounds promising, cleaner as some hidden input prioritization. I'm looking forward to it, the current status is a blocker for me. |
Cool, @reuschling thanks for reporting this issue. @jngz-es is working on this. Will publish PR soon |
It is straightforward and works of course when I define a SearchIndexTool inside a conversational flow agent, the question is inserted into the defined OpenSearch query, there will come search results.
Unfortunately, I can not manage this with a conversational agent.
This agent should always execute the same query:
I get always this error message:
Failed to run the tool SearchIndexTool with the error message Expected a com.google.gson.JsonObject but was com.google.gson.JsonPrimitive; at path $.
Independent from the specified tool input. It seems that the conversational agent overwrites theparameters.input
content with its generated, redefined query, wasting the query specification from the SearchIndexTool.Expected behavior is that you define the OpenSearch query inside the tool description, and that the output from the former step of the conversational search should be inserted into this query, e.g. like this:
Maybe the 'input' parameter for the query specification can be renamed or configured.
The text was updated successfully, but these errors were encountered: