This PR introduces GraalVM integration to enable local execution of
JavaScript and Python scripts by Langchain4j agents.
Major updates include:
- New langchain4j-graal module for encapsulating integration logic.
- Necessary infrastructure for invoking GraalVM and executing scripts.
- Unit tests to validate the integration.
# Changes
## Hugging Face
I introduced `HuggingFaceClientFactory` which can be used for
integrations to supply their own version of the Hugging Face HTTP
client.
The rationale is similar to what I have done in previous PRs
# Purpose
The idea here is that advanced integrations would be able to supply
their own version of `AiServices`. The use case I have
[implemented](https://github.com/geoand/quarkus-langchain4j/blob/master/core/runtime/src/main/java/io/quarkiverse/langchain4j/QuarkusAiServicesFactory.java)
using these SPIs allows Quarkus to do a lot of the work at build time
instead of runtime, while also using our preferred set of dependencies.
# Changes
## Json
Introduce and SPI that allows integrations to swap out a custom Json
implementation.
## ChatMessage Json SPI
Same idea as above but for the `ChatMessage` specifically
## InMemoryEmbeddingStore Json SPI
Same idea as above but for `InMemoryEmbeddingStore` specifically
## AiServices
This change builds on the previous two and is the actual meat of the
change. It makes the least possible changes to the project that will
allow for integrations to provide their own implementation of
AiServices.
Existing usages of AiServices via langchain4j see no change whatsoever.
### Note
The SPI is deliberately under specified as I prefer at this very early
stage to place an additional burden on integrators (me in this case :))
where various parts need to be reimplemented, rather than trying to make
the SPI to specific which could cause problems when and if new
integrations come in the future.
I believe that if interest for such an integration manifests, we can all
work together to define the exact methods and types that will be needed
by everyone thus allowing for maximum code reuse.
@langchain4j Hi! I make some progress to integrate with Ollama, see
#244. Using `retrofit` to define REST API in [Ollama
doc](https://github.com/jmorganca/ollama/blob/main/docs/api.md#generate-a-completion).
Local test need local deployment of `Ollama`. Looking forward to get
your code review!
---------
Co-authored-by: Heezer <33568148+Heezer@users.noreply.github.com>
By adding an optional dependency on the
spring-boot-configuration-processor, a
`META-INF/spring-configuration-metadata.json` file will be created for
all `@ConfigurationProperties`-annoted types to support autocompletion
within IDEs. Since nested beans are used, the bound fields for those
beans need to be annotated with `@NestedConfigurationProperty`. (purely
for this tool, this does not affect runtime behavior in any way)
# Summary
I use https://github.com/pgvector/pgvector-java/ to implement
`PgVectorEmbeddingStore`.
1. Insertion works as regular SQL as long as a table (with namespace as
table name) contains type `vector`.
2. Query is upon the enhanced SQL by vector extension. The SQL returned
results are the final result with passing `minScore` and `maxResults`.
# Caveat
* The implementation leaves responsibility of installing `vector`
extension to users.
* Only cosine similarity is used.
* Only ivfflat index is used.
see #217, it's a good way to manage artifacts.
Now users can use code below to import dependency:
```xml
<dependencyManagement>
<dependencies>
<dependency>
<groupId>dev.langchain4j</groupId>
<artifactId>langchain4j-bom</artifactId>
<version>${langchain4j.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
```
Adding two separate loaders that load a single document or multiple
documents from S3 respectively. They also contain different parameters
to support different configurations. However, the document type is
dependent on the current parsers that langchain4j supports, but I am
planning to help in adding more parsers in the future.
Add the Spring Boot Configuration Processor dependency to the Spring
Boot starter to generate metadata
about the LangChain4J custom properties.
Fixes gh-250
# Purpose
This purpose of this pull request is to make it possible for advanced
integrators to swap out some of the dependencies with others.
For a first iteration, I did not want to require current consumers of
this library to have to make any changes - for them this pull requests
changes nothing whatsoever.
This means that I did not do any sort of of changes to the structure or
name of the Maven modules. I believe that if we want to do that, if can
be done at a latter point.
# Changes
## Gson
All this change does is move Gson out of the model classes. This is
needed by integrations that plan to exclude Gson from the classpath, so
that the models can continue to be loaded without incurring ClassLoading
issues.
## Template SPI
I introduced `PromptTemplateFactory` which can be used for integrations
to supply their own version of the template engine.
Implementations are loaded using Java's ServiceLoader mechanism and if
none are found, the default `MustachePromptTemplateFactory` is used.
I have leveraged this SPI my Quarkus integration
[here](487711af4c/runtime/src/main/java/io/quarkiverse/langchain4j/QuarkusPromptTemplateFactory.java).
## Make OpenAiStreamingResponseBuilder thread-safe
This class needs to be thread safe because it is called when a streaming
result comes back
and there is no guarantee that this thread will be the same as the one
that initiated the request
LangChain4j