Blog post featured image

Introduction

In a recent series of Artificial Intelligence related blog posts, we have learned about the Camel Quarkus LangChain4j extension. It offers possibilities to implement new AI related scenarios like data extraction. The underlying implementation of Quarkus LangChain4j seems to offer interesting abstractions that, for instance make it possible to switch between Large Language Models quite simply. We have also started to see some improvements when it comes to invoking AI services thanks to camel bean binding and annotations. That’s a good start, still after experimentation, there is room for more improvement, especially when it comes to AI service resolution from Camel.

AI service resolution by interface

In the past we needed to manually inject the AI service as shown below:

@ApplicationScoped
public class MyRoutes extends RouteBuilder {

  @Inject
  MyAIService myAiService;

  @Override
  public void configure() {
    from("...")
      .bean(myAiService);
  }
}

Looking a bit more, is there really a great interest to manually inject the bean with @Inject? As you know, the community is oriented toward inverting the developer experience with tools like Camel JBang. This philosophy mandates to concentrate on the integration logic first and then deal with runtime intricacies later on, if ever needed.

And in the end, the code snippet seen above is kind of breaking this principle. So how could we improve the situation ? After some thought, it turns out that a more transparent injection could help in such a situation.

Indeed, if we could erase this explicit manual injection, chances are that the code would arguably be more:

  • Compact
  • Focused on the integration logic
  • Abstracted from the underlying runtime

Pushing the rationale further, the question should even be asked the opposite way. Like, how would a common camel user write such an integration route ? And actually, it could be done in a simpler way as follows:

@ApplicationScoped
public class MyRoutes extends RouteBuilder {

  @Override
  public void configure() {
    from("...")
      .bean(MyAIService.class);
  }
}

This time, we only mandate the expected AI service interface and let camel to do whatever is needed under the hood to resolve it. This looks a nice idea, however while experimenting this construct… It resulted in a cryptic error message.

People used to create Camel Quarkus extensions will have noticed quickly that the Quarkus bean removal mechanism would hit there. More precisely, with Quarkus, the dependency injection occurs at build time, once and for all. In this spirit, a bean that is not referenced at build time could be considered useless and literally removed.

And in the case at hand, Camel and Quarkus do not play well to the point of automatically detecting that situation. As always, there are manual workarounds that could be applied.

However, this kind of issues is best fixed in the Camel Quarkus LangChain4j extension itself. Indeed, this extension aims at solving as much as possible the intricacies of developing camel routes using high-level AI services. The good news is that the AI service resolution by interface has just been delivered with the recent Camel Quarkus 3.17.0 release.

Conclusion

Initially, I hesitated to create the Camel Quarkus LangChain4j extension, as the scope was too narrow. Still experimentation after experimentation, we discover some intricacies and user experience improvements that in the end amply justify the maintenance cost of this new extension. Being able to resolve AI services by interface is just one of those goodness. There are actually more coming in future versions. That should be a good subject for a next blog post. Meanwhile, I would encourage the community to test out the Camel Quarkus Langchain4j extension. And please, as usual, feel welcome to report any bugs and improvements here.

Avoiding model lock in while building an AI Camel route

 , by

Introduction In a previous blog post, we have seen how Camel parameter binding annotations could be used in conjunction with LangChain4J AI services to easily create Camel routes using Large Language Models. All this work is best reflected in a Camel Quarkus example. While building this example, poor care was taken about the choice of the LLM as this was not the initial priority. Thinking a bit more, this situation is a great opportunity to experience the switch of an LLM inside of a Camel application.

Continue reading ❯

CAMELAI

Using Camel annotations with LangChain4j high level api available in next Camel Quarkus release

 , by

Introduction In a previous blog post, we have seen how Camel could be used to transform raw unstructured text into structured Java objects. The shown example actually uses the LangChain4j high level API where a Java interface will handle the interactions needed with the underlying Large Language Model. However, at this time, a Quarkus LangChain4j issue prevented the usage of the Camel parameter binding annotations. This issue will be fixed in the next Camel Quarkus release, so let’s see how it will work.

Continue reading ❯

CAMELAI

Unstructured data extraction with Apache Camel Quarkus and LangChain4j

 , by

This blog post shows a concrete example of transforming raw unstructured text into structured Java objects with Camel Quarkus and Quarkus LangChain4j. Introduction Following previous experiments about unstructured data extraction, some directions were given about how a large language model could be setup to transform unstructured data into its structured counterpart. In this blog post, we will see a ready to use example that could serve as a starting point to create your own Camel route performing data extraction.

Continue reading ❯

CAMELAI

Experimenting extraction from unstructured data with Apache Camel and LangChain4j

 , by

This blog is based on experiments done about extracting structured data into its structured counterpart. More precisely, in this post, we’ll give directions about how to convert a conversation transcript into a Java object. Introduction Reading articles like this over the net, it seems that folks have a lot of unstructured data at the disposal while not being able to take advantage on it. So probably, in the future we might expect to deal more and more with unstructured data extraction in integration flow.

Continue reading ❯

CAMELAI

Unlocking Efficient Data Processing with the Chunking DSL

 , by

Chunking is a crucial aspect of data processing that can significantly impact retrieval quality, query latency, costs, and even the accuracy of Large Language Model (LLM) outputs. In this blog post, we’ll explore what chunking is, its importance, and how the new Chunking DSL in Apache Camel 4.8.0 improves data processing workflows. The Problem with Traditional Chunking Approaches Before Camel 4.8.0, applications using Camel would have to implement custom chunking logic or rely on external libraries.

Continue reading ❯

CAMELAI