Introduce TemplateRenderer for prompt templating #2780
Conversation
ThomasVitale
force-pushed
the
prompt-template-strategy-part-1
branch
from
9af0036 to
7642277
Compare
| @@ -93,44 +92,6 @@ void newApiPlaygroundTests() { | |||
|
|
|||
| } | |||
|
|
|||
| @Test | |||
There was a problem hiding this comment.
The ST specific templating logic is now tested in StTemplateRendererTests.
| inputVariables.add(token.getText()); | ||
| } | ||
| } | ||
| throw new UnsupportedOperationException( |
There was a problem hiding this comment.
This is the only behavioural breaking change in this PR. What do you think?
This method was used internally for validation and testing (and it's still used that way, but inside StTemplateRenderer). This is very specific not only based on the template engine, but also on how it's configured, so I wouldn't expose this information here. If we need some additional introspection into the internals of the template engine, it should be the TemplateRenderer giving access to that.
|
|
||
| private static final ValidationMode DEFAULT_VALIDATION_MODE = ValidationMode.THROW; | ||
|
|
||
| private final char startDelimiterToken; |
ThomasVitale
force-pushed
the
prompt-template-strategy-part-1
branch
from
7642277 to
131beec
Compare
| } | ||
|
|
||
| PromptTemplate(String template, Map<String, Object> variables, TemplateRenderer renderer) { | ||
| Assert.hasText(template, "template cannot be null or empty"); |
There was a problem hiding this comment.
Currently, ST fails if the template is null or empty. This additional validation makes sure we fail already at construction time instead of render time, making it possible to catch possible errors sooner.
ThomasVitale
force-pushed
the
prompt-template-strategy-part-1
branch
from
131beec to
5628f05
Compare
| * @author Thomas Vitale | ||
| * @since 1.0.0 | ||
| */ | ||
| public interface TemplateRenderer extends BiFunction<String, Map<String, Object>, String> { |
There was a problem hiding this comment.
hard to know at this point, but wondering if this and the ST/Noop should go into spring-ai-commons It is more of an implementation detail vs. a core model design.
Also in the interest of separating out dependencies, we could move just the TemplateRenderer interface and ValdiatonModel interface into spring-ai-commons and the rest of the classes go into a new module spring-ai-template-st This way if we end up supporting some other common template engines, those can be optional modules pulled in by the user and it would look consistent? One could even exclude the st module in their app I suppose.
- Introduce new TemplateRenderer API providing the logic for rendering an input template. - Update the PromptTemplate API to accept a TemplateRenderer object at construction time. - Move ST logic to StTemplateRenderer implementation, used by default in PromptTemplate. Additionally, make start and end delimiter character configurable. Relates to spring-projectsgh-2655 Signed-off-by: Thomas Vitale <[email protected]>
ThomasVitale
force-pushed
the
prompt-template-strategy-part-1
branch
from
b7207a0 to
f4c1e76
Compare
Relates to gh-2655, gh-1687.
Second PR will follow to use TemplateRenderer in ChatClient. See usage examples here: https://github.com/ThomasVitale/spring-ai/pull/1/files#diff-38f2fe47de01515938c5201ff9af94a7fa869b2760c515e2472f83cb42271518R103