LLM Filter Retriever - custom Parameters

[FabianKiwitz92]

In my experience llm Filter Retriever Are crucial for a very Good rag.

is there any possibillity to add custom parameters to the Query for example {chat_history} or State for llm Filter Retriever?

its a very powerfull node!

the documentation says overwrite the query by using query but i Need custom Parameters to make it work with Sense.

would be a super powerfull Thing for all bigger rag Applications.

thank u

[KushagraSikka]

Hi @FabianKiwitz92,

You’re absolutely right—LLM Filter Retrievers play a critical role in optimizing Retrieval-Augmented Generation (RAG), especially when contextual filtering is necessary.

Custom Parameters in LLM Filter Retriever

While the documentation suggests overwriting the query using "query", extending this mechanism to accept custom parameters like {chat_history} or State can significantly enhance retrieval precision.
Possible Workarounds:
1. Pre-processing Query with a Custom Wrapper: • Before passing the query to the retriever, you can manually inject {chat_history} or other dynamic parameters into the query string.
2. Using a Custom LLM-Generated Filter
• If the retriever supports LLM-based filtering, you can modify the retriever pipeline to take additional parameters:
3.Modifying the Retriever Class (If Possible)
• If you have control over the Retriever implementation, modifying it to accept additional parameters in its retrieve() method would be the cleanest solution.

Feature Proposal

If you’re proposing a direct feature enhancement, I suggest:
• Extending the retriever API to allow query augmentation with user-defined context variables.
• Allowing users to define a custom filter function that operates before retrieval.

Would love to hear your thoughts! If needed, I can draft a prototype for handling these additional parameters dynamically.

[FabianKiwitz92]

Hi Kushagra Sikka, I completely agree with you. The biggest benefit comes from using custom-defined variables aka custom prompt values to create a specialized query that operates independently of the user’s input. This way, we can apply a predefined query that is specifically designed to retrieve optimally filtered content. Decoupling the query from the user input allows for more precise and targeted results, ultimately providing the greatest value. Best regards and thank u so much for your reply!! Gesendet von Outlook für iOS<https://aka.ms/o0ukef>

…

________________________________ Von: Kushagra Sikka ***@***.***> Gesendet: Sonntag, Februar 2, 2025 8:03 PM An: FlowiseAI/Flowise ***@***.***> Cc: Fabian Kiwitz ***@***.***>; Mention ***@***.***> Betreff: Re: [FlowiseAI/Flowise] LLM Filter Retriever - custom Parameters (Discussion #3967) Hi @FabianKiwitz92<https://github.com/FabianKiwitz92>, You’re absolutely right—LLM Filter Retrievers play a critical role in optimizing Retrieval-Augmented Generation (RAG), especially when contextual filtering is necessary. Custom Parameters in LLM Filter Retriever While the documentation suggests overwriting the query using "query", extending this mechanism to accept custom parameters like {chat_history} or State can significantly enhance retrieval precision. Possible Workarounds: 1. Pre-processing Query with a Custom Wrapper: • Before passing the query to the retriever, you can manually inject {chat_history} or other dynamic parameters into the query string. 2. Using a Custom LLM-Generated Filter • If the retriever supports LLM-based filtering, you can modify the retriever pipeline to take additional parameters: 3.Modifying the Retriever Class (If Possible) • If you have control over the Retriever implementation, modifying it to accept additional parameters in its retrieve() method would be the cleanest solution. Feature Proposal If you’re proposing a direct feature enhancement, I suggest: • Extending the retriever API to allow query augmentation with user-defined context variables. • Allowing users to define a custom filter function that operates before retrieval. Would love to hear your thoughts! If needed, I can draft a prototype for handling these additional parameters dynamically. — Reply to this email directly, view it on GitHub<#3967 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BIZ4PZBNCR6THBJUUY5NE432NZTY3AVCNFSM6AAAAABWKECQWCVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTEMBTGM4DINI>. You are receiving this because you were mentioned.Message ID: ***@***.***>