[
https://issues.apache.org/jira/browse/CAMEL-22510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Otavio Rodolfo Piske updated CAMEL-22510:
-----------------------------------------
Description:
Currently, using the {{camel-ai}} chat components (e.g.,
{{{}camel-langchain4j-agent{}}}) with common data types like {{InputStream}}
requires significant boilerplate from the end-user. Users are often forced to
use {{.convertBodyTo(String.class)}} or manually construct provider-specific
message objects (like LangChain's {{{}UserMessage{}}}), which is not intuitive
and hides the power of Camel's type conversion system.
As noted by [~davsclaus], _"convertBodyTo should not be commonly in use, and
not something end users would use when using different components. It's there
for some more advanced and specific use-cases."_
The AI components should be enhanced to work seamlessly with common message
payloads, especially {{{}InputStream{}}}, which is a frequent output from
components like {{{}camel-file{}}}, {{{}camel-ftp{}}}, {{{}camel-http{}}}, etc.
When using non-text, currently it requires the user to manipulate the data:
{code:java}
// User needs to know about convertBodyTo or internal classes
from("file:src/data/text")
.convertBodyTo(String.class)
.to("langchain-chat:myModel");
// Or even more complex for images
from("file:src/data/images?fileName=my-image.png")
.process(exchange -> {
// Complex, provider-specific logic to create an image message
byte[] imageData = exchange.getIn().getBody(byte[].class);
// ... create UserMessage with image content ...
exchange.getIn().setBody(complexImageMessageObject);
})
.to("langchain4j-agent:...");
{code}
Ideally, it should be:
{code:java}
// 1. Processing a text file seamlessly
from("file:src/data/text")
.to("langchain-chat:myModel"); // The component handles the InputStream
// 2. Processing an image file with the new option
from("file:src/data/images?fileName=my-image.png")
.to("langchain-chat:myModel?image=true");
{code}
was:
Currently, using the {{camel-ai}} chat components (e.g.,
{{{}camel-langchain4j-agent{}}}) with common data types like {{InputStream}}
requires significant boilerplate from the end-user. Users are often forced to
use {{.convertBodyTo(String.class)}} or manually construct provider-specific
message objects (like LangChain's {{{}UserMessage{}}}), which is not intuitive
and hides the power of Camel's type conversion system.
As noted by [~davsclaus], _"convertBodyTo should not be commonly in use, and
not something end users would use when using different components. It's there
for some more advanced and specific use-cases."_
The AI components should be enhanced to work seamlessly with common message
payloads, especially {{{}InputStream{}}}, which is a frequent output from
components like {{{}camel-file{}}}, {{{}camel-ftp{}}}, {{{}camel-http{}}}, etc.
When using non-text, currently it requires the user to manipulate the data:
{code:java}
// User needs to know about convertBodyTo or internal classes
from("file:src/data/text")
.convertBodyTo(String.class)
.to("langchain-chat:myModel");
// Or even more complex for images
from("file:src/data/images?fileName=my-image.png")
.process(exchange -> {
// Complex, provider-specific logic to create an image message
byte[] imageData = exchange.getIn().getBody(byte[].class);
// ... create UserMessage with image content ...
exchange.getIn().setBody(complexImageMessageObject);
})
.to("langchain4j-agent:...");
{code}
Ideally, it should be:
{code:java}
// 1. Processing a text file seamlessly
from("file:src/data/text")
.to("langchain-chat:myModel"); // The component handles the InputStream
// 2. Processing an image file with the new option
from("file:src/data/images?fileName=my-image.png")
.to("langchain-chat:myModel?image=true");
{code}
> camel-langchain4j-agent: avoid leaking internal data types
> ----------------------------------------------------------
>
> Key: CAMEL-22510
> URL: https://issues.apache.org/jira/browse/CAMEL-22510
> Project: Camel
> Issue Type: Improvement
> Components: camel-ai, camel-langchain4j-agent
> Affects Versions: 4.14.1, 4.15.0
> Reporter: Otavio Rodolfo Piske
> Priority: Major
> Labels: good-first-issue, help-wanted
>
> Currently, using the {{camel-ai}} chat components (e.g.,
> {{{}camel-langchain4j-agent{}}}) with common data types like {{InputStream}}
> requires significant boilerplate from the end-user. Users are often forced to
> use {{.convertBodyTo(String.class)}} or manually construct provider-specific
> message objects (like LangChain's {{{}UserMessage{}}}), which is not
> intuitive and hides the power of Camel's type conversion system.
> As noted by [~davsclaus], _"convertBodyTo should not be commonly in use, and
> not something end users would use when using different components. It's there
> for some more advanced and specific use-cases."_
> The AI components should be enhanced to work seamlessly with common message
> payloads, especially {{{}InputStream{}}}, which is a frequent output from
> components like {{{}camel-file{}}}, {{{}camel-ftp{}}}, {{{}camel-http{}}},
> etc.
> When using non-text, currently it requires the user to manipulate the data:
>
> {code:java}
> // User needs to know about convertBodyTo or internal classes
> from("file:src/data/text")
> .convertBodyTo(String.class)
> .to("langchain-chat:myModel");
> // Or even more complex for images
> from("file:src/data/images?fileName=my-image.png")
> .process(exchange -> {
> // Complex, provider-specific logic to create an image message
> byte[] imageData = exchange.getIn().getBody(byte[].class);
> // ... create UserMessage with image content ...
> exchange.getIn().setBody(complexImageMessageObject);
> })
> .to("langchain4j-agent:...");
> {code}
> Ideally, it should be:
> {code:java}
> // 1. Processing a text file seamlessly
> from("file:src/data/text")
> .to("langchain-chat:myModel"); // The component handles the InputStream
> // 2. Processing an image file with the new option
> from("file:src/data/images?fileName=my-image.png")
> .to("langchain-chat:myModel?image=true");
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
