GH-4232 Introduce the ValidationMode property to RewriteQueryTransformer

[sunyuhan1998]

As described in the issue, the current RewriteQueryTransformer allows users to customize templates via the constructor, but enforces strict validation of placeholders in the template—this can be overly restrictive in certain scenarios. This PR introduces a new ValidationMode property to RewriteQueryTransformer, supporting three modes: THROW, WARN, and NONE. The default mode is THROW, which preserves the original behavior. If set to WARN, the system will perform validation as usual, but when a required variable is missing from the template, it will only log a warning instead of throwing an exception. If set to NONE, validation is completely skipped.

Changes included in this PR:

1. Added the ValidationMode property to RewriteQueryTransformer to enable flexible control over placeholder validation;
2. Implemented corresponding unit tests to ensure correctness across all validation modes.

Fixes #4232

[sunyuhan1998]

Hi @markpollack @sobychacko , What do you think about this? Could you please help review this PR? Thank you.

[ThomasVitale]

@sunyuhan1998 thanks for raising this issue! The validation that is currently done in the RewriteQueryTransformer (but also in other RAG components) is very permissive and high-level. I wonder If we could remove it altogether and come up with a different way to validate the prompts.

The current logic only checks for the presence of words in a prompt template that match the variables expected by the component. But it doesn't really check if they are available as placeholders. Since the introduction of the modular RAG components, we introduced the TemplateRenderer API and extended the PromptTemplate API. I'm wondering if there's something we could do there to solve this problem so that the same solution can be adopted by any type of component that offers prompt template customization. Something more robust than the current PromptAssert that validates the actual placeholders in the template and not just a String occurrence. What do you think?

Besides that, I'm curious about the use cases where it should be ok not to validate the prompt placeholders. Could you elaborate on that? For example, in this case, the prompt should include a query placeholder to ask for a rewrite. If the placeholder is not there, wouldn't that mean the operation won't work? For special cases or additional flexibility, it might be better to implement a custom QueryTransformer directly and have full flexibility.

[ThomasVitale]

Just noticed the original issue. If target is problematic, I would suggest removing the validation for the target placeholder directly, so to still guarantee the core functionality of the component. Or maybe even update the default prompt to remove the target part altogether and have a more generic prompt. If more tailored prompts are needed for specific scenarios, a custom PromptTemplate can be provided. It would be a simpler solution. Thoughts?

[sunyuhan1998]

Just noticed the original issue. If target is problematic, I would suggest removing the validation for the target placeholder directly, so to still guarantee the core functionality of the component. Or maybe even update the default prompt to remove the target part altogether and have a more generic prompt. If more tailored prompts are needed for specific scenarios, a custom PromptTemplate can be provided. It would be a simpler solution. Thoughts?

Actually, my initial idea was: it would be ideal if we could ensure that all variables corresponding to the placeholders in the prompt have been provided by the user. However, currently TemplateRenderer doesn't have the capability to extract all placeholders from a prompt. That's why I submitted this PR (#4252). If this PR gets merged, the issue we're discussing in the current PR would be naturally resolved. What do you think?