Add some useful planner processors #1327
Conversation
…essors Signed-off-by: Henry Lindeman <hmlindeman@yahoo.com>
Signed-off-by: Henry Lindeman <hmlindeman@yahoo.com>
Signed-off-by: Henry Lindeman <hmlindeman@yahoo.com>
| # LlmExtractEntity without anything after it is just slow | ||
| # TopK can sometimes fail if the LLM returns garbage and doesn't help with getting | ||
| # the list of documents -- we just have to ignore it | ||
| assert len(n.inputs) == 1, f"Trailing {n.node_type} node must have exactly one input" |
There was a problem hiding this comment.
you'll need to update dependencies here right?
There was a problem hiding this comment.
A more explicit way would be to choose which operators stay in vs out
There was a problem hiding this comment.
wdym update the dependencies? I delete the bad tail node and update the plan result_node to the one before it.
There was a problem hiding this comment.
I considered letting it be 'RemoveTailNodesByType' or some such. The only use-case I could come up with for it was this one though, so I decided to go with the less general thing as it's clearer why you want it.
There was a problem hiding this comment.
Talked offline figured it out
| return plan | ||
|
|
||
|
|
||
| class LogPlan(LogicalPlanProcessor): |
There was a problem hiding this comment.
is it better to just add a .print() method to the plan object? then the .print can be called by planner who is orchestrating the processors
There was a problem hiding this comment.
If I'm trying to assemble a strategy that does the right thing then my programming language is effectively the list of processors so one that prints the current state is useful.
Signed-off-by: Henry Lindeman <hmlindeman@yahoo.com>
From upstreaming