[
https://issues.apache.org/jira/browse/CAMEL-21916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zineb Bendhiba updated CAMEL-21916:
-----------------------------------
Description:
LangChain4j [AI Services|https://docs.langchain4j.dev/tutorials/ai-services/]
are the highest-level API of LangChain4j: one user-defined interface carrying
the full feature set.
h3. Why this matters
The motivation is a component that supports everything LangChain4j offers,
present and future, without wrapping it feature by feature. It also makes
custom AiService interfaces easy to use from Camel, compared to the
\{{camel-langchain4j-agent}} component, whose contract is fixed by the
component (an \{{AgentFactory}} hook allows customization, at the price of
extra complexity): here users bring their own domain interface, with their own
method names, parameters and return types, and a route calls it as-is.
The existing \{{camel-langchain4j-agent}} component builds the AI service
internally: model, memory, tools and guardrails are configured through Camel
options, so the component has to chase the \{{AiServices}} builder surface
option by option (see CAMEL-23950).
This feature inverts the ownership. The user defines the AiService the standard
LangChain4j way (plain \{{AiServices}} builder, or Quarkus
\{{@RegisterAiService}}), and LangChain4j deals with all the rest: the model,
the system and user messages, chat memory, RAG (retrieval augmentors), tools
and agentic behavior, guardrails, structured output. Whatever the user
configures on the AiService works, with no Camel option needed for any of it,
including LangChain4j features that do not exist yet. Camel just invokes it
from a route:
{code:java}
from("kafka:inbox")
.to("langchain4j-ai-service:myAssistant?method=chat")
.to("kafka:ai-responses");{code}
The route is the orchestrator: messages arrive through any of Camel's 300+
connectors, the AI Service reasons, the route pushes the result onward.
LangChain4j does the AI, Camel does the integration.
h3. Decision
A new dedicated component, \{{camel-langchain4j-ai-service}} (under
\{{components/camel-ai}}), rather than new options.
was:
In relation to CAMEL-21915, there's another way to support structured output
with LangChain4J, which is AI Services:
https://docs.langchain4j.dev/tutorials/ai-services/
Adding support for AI Services to Camel LangChain4j component set should give
users more flexibility to implement AI solution backed by structured output.
At this moment, it's not clear to me what's the best way to support it: whether
it should be a new component ({{camel-langchain4j-aiservices}}?) or just new
options to {{camel-langchain4j-chat}}.
> camel-langchain4j - Add support for AI Services
> -----------------------------------------------
>
> Key: CAMEL-21916
> URL: https://issues.apache.org/jira/browse/CAMEL-21916
> Project: Camel
> Issue Type: New Feature
> Components: camel-ai, camel-langchain4j
> Affects Versions: 4.11.0
> Reporter: Tadayoshi Sato
> Assignee: Zineb Bendhiba
> Priority: Major
>
> LangChain4j [AI Services|https://docs.langchain4j.dev/tutorials/ai-services/]
> are the highest-level API of LangChain4j: one user-defined interface carrying
> the full feature set.
>
> h3. Why this matters
> The motivation is a component that supports everything LangChain4j offers,
> present and future, without wrapping it feature by feature. It also makes
> custom AiService interfaces easy to use from Camel, compared to the
> \{{camel-langchain4j-agent}} component, whose contract is fixed by the
> component (an \{{AgentFactory}} hook allows customization, at the price of
> extra complexity): here users bring their own domain interface, with their
> own method names, parameters and return types, and a route calls it as-is.
> The existing \{{camel-langchain4j-agent}} component builds the AI service
> internally: model, memory, tools and guardrails are configured through Camel
> options, so the component has to chase the \{{AiServices}} builder surface
> option by option (see CAMEL-23950).
> This feature inverts the ownership. The user defines the AiService the
> standard LangChain4j way (plain \{{AiServices}} builder, or Quarkus
> \{{@RegisterAiService}}), and LangChain4j deals with all the rest: the model,
> the system and user messages, chat memory, RAG (retrieval augmentors), tools
> and agentic behavior, guardrails, structured output. Whatever the user
> configures on the AiService works, with no Camel option needed for any of it,
> including LangChain4j features that do not exist yet. Camel just invokes it
> from a route:
>
> {code:java}
> from("kafka:inbox")
> .to("langchain4j-ai-service:myAssistant?method=chat")
> .to("kafka:ai-responses");{code}
>
> The route is the orchestrator: messages arrive through any of Camel's 300+
> connectors, the AI Service reasons, the route pushes the result onward.
> LangChain4j does the AI, Camel does the integration.
> h3. Decision
> A new dedicated component, \{{camel-langchain4j-ai-service}} (under
> \{{components/camel-ai}}), rather than new options.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
