OPEA GenAIExamples: Microservice Reference Pipelines for RAG and Summarization

What GenAIExamples Actually Ships

This repository is a catalogue of runnable GenAI pipelines, not a library you import. The README lists the use cases by scenario: ChatQnA and VisualQnA for question answering, Text2Image for image generation, DocSum for summarization, CodeGen for code generation, DocIndexRetriever for retrieval, and InstructionTuning for fine-tuning. Each is a directory with its own deployment assets. The primary language is Shell, which tells you where the weight sits: the substance is orchestration scripts, compose files, and Helm charts that wire prebuilt services together, not application code you would vendor into your own project. The README describes the examples as "microservice-based samples that simplify the processes of deploying, testing, and scaling GenAI applications." That word, samples, is the honest framing. Nothing in the material suggests these directories are versioned as APIs, and the release cadence (v1.3 in May 2025, v1.4 in August 2025, v1.5 in December 2025) suggests each release is a snapshot rather than a long-term support line. If your goal is to understand how a RAG pipeline is assembled from separate embedding, retrieval, reranking, and LLM services, the layout is legible. If your goal is a dependency you can pin and forget, this is the wrong shape.

The Three-Repository Split and Why It Matters

The architecture section names two sibling repositories that do the real work. GenAIComps holds the microservice components: llm, embedding, reranking, and others. GenAIInfra is described as the containerization and cloud-native suite that enables deployment of the examples in the cloud. GenAIEval measures throughput, latency, and accuracy so users can compare performance across hardware configurations. GenAIExamples itself is the assembly layer that composes those components into named applications. This split has a practical consequence for anyone evaluating the project. When you clone GenAIExamples, you are not getting the service implementations. You are getting the wiring plus a reference to released docker images, and the README explicitly says deployment is "based on released docker images by default" and points to docker_images_list.md for detail. So the behaviour of any given example depends on image tags defined elsewhere in the tree, and the components themselves live in a repository you have not opened. That is a reasonable separation of concerns for a platform project. It is also a debugging hazard: a failure inside the embedding service is not something you fix by editing a file in this repository.

Deployment Paths: Python, Docker Compose, Kubernetes

The README states three primary deployment methods: Python startup, Docker Compose, and Kubernetes. Prerequisites are stated per path. For Docker Compose you need docker compose installed. For Kubernetes you need a cluster, and optionally Helm version 3.15 or later if you want to deploy with Helm charts, or GMC installed in the cluster if you want to try the microservices-connector path. The README links out to installation guides for Kubernetes and GMC rather than reproducing them. Hardware guidance is given as a reference table rather than a hard requirement. The Xeon row lists a model (Intel/neural-chat-7b-v3-3) and a configuration of 64 vCPUs, 365 GB disk, 100 GB RAM on Ubuntu 24.04. The Gaudi row lists the same model with 1 or 2 Gaudi cards, 16 vCPUs, the same disk and RAM, on the same OS. The Xeon-on-AWS row drops to 100 GB disk and 64 GB RAM and names c7i.16xlarge as an example instance. Those numbers are the project's own reference points, not measured results, and the README does not claim they are minimums. Treat them as a starting shape for capacity planning and expect to adjust. The README also states that all examples are compatible with both Docker and Kubernetes and support Gaudi, Xeon, AMD EPYC CPUs, AMD Instinct GPUs, and NVIDIA GPUs. That breadth is the strongest argument for the project's existence: the same example directory is meant to run across five hardware families, with GenAIEval as the tool for comparing them.

Where the Documentation Stops Being Documentation

The README is an index, and it says so. It points to a documentation site for architecture and deployment guides, and to docker_images_list.md for image details. What it does not contain is a single worked example of a deployment command, a config key, or an environment variable. This review therefore cannot give you a copy-pasteable command, because the supplied material does not contain one. That absence is itself the finding. A Shell-primary repository whose top-level README defers all operational detail to external pages means your first hour with GenAIExamples is spent in the docs site and in the individual example directories, not in the root. The per-example READMEs are the real entry points. The use case table marks ChatQnA, VisualQnA, and Text2Image with a symbol the README does not define in the text supplied, which suggests the marker distinguishes some subset of examples, possibly the more complete ones. If you are choosing where to start, that marker is the only signal the README gives you, and it is unexplained. Verify it against the docs site before you assume it means maturity.

The Case Against: Samples Rot

The clearest limitation is structural. GenAIExamples is a collection of samples in a fast-moving area, distributed across three repositories with a fourth moving part (released docker images) referenced by tag. Every release of the examples can shift the images underneath it, and the components can shift independently in GenAIComps. Nothing in the supplied material describes a compatibility matrix, a deprecation policy, or a supported upgrade path from v1.4 to v1.5. Three releases in roughly seven months is a healthy cadence for a project that is still settling, and an uncomfortable one for anyone who deployed v1.3 and wants to know what changed. The second limitation is scope. These are end-to-end applications with opinionated service boundaries. If your requirement is a single embedding service behind your own API, adopting ChatQnA means adopting the whole pipeline and its deployment machinery to get one component. The third is the hardware table itself. The reference configurations are substantial (100 GB RAM on the Xeon row), and the Gaudi row assumes you have Gaudi cards. A laptop evaluation is not what this repository is built for.

Alternatives: LangChain Templates and Plain Compose

The closest comparison is a framework-level toolkit such as LangChain or LlamaIndex, where you assemble a RAG chain in application code and own the deployment yourself. The difference is where the abstraction lives. GenAIExamples puts the pipeline in infrastructure: separate services for embedding, retrieval, reranking, and the LLM, wired by compose files and Helm charts, with the application boundary drawn between containers. A framework puts the pipeline in a Python process, with the service boundary drawn between function calls. The infrastructure approach gives you independent scaling and hardware placement per stage, which is why the README can claim support across Gaudi, Xeon, AMD, and NVIDIA in the same example. The framework approach gives you a single artifact to test and deploy, and no YAML to reconcile. A second alternative is writing your own compose file around vLLM or TGI plus a vector store. That is more work than copying an example and less work than understanding one you did not write. GenAIEval is the piece that is hardest to substitute: the README positions it as the way to compare throughput, latency, and accuracy across hardware, and a homegrown harness would need to reimplement that measurement layer to answer the same question.

Licence, Maintenance and What It Costs to Keep Running

The repository is Apache-2.0, which permits commercial use, modification, and redistribution with the usual notice and patent-grant terms. That covers the files in this repository. It does not automatically cover the container images the examples pull, the model weights they download, or the components in GenAIComps, each of which carries its own licence. Checking those separately is your responsibility, and this is not legal advice. On maintenance cost, the material supports a few concrete observations. The release notes are the only changelog surface named, and they are per-version documents rather than a cumulative upgrade guide. The image list file is the only named source of truth for what you are actually running. Helm 3.15 is stated as a floor for the chart path, so a cluster pinned to an older Helm needs a decision before deployment, not after. Kubernetes and GMC installation are both linked out, meaning the platform setup cost is real and external to this repository. Budget for reading the per-example directory before you budget for compute.

Editorial conclusion

Adopt GenAIExamples if you need a working RAG or summarization pipeline to evaluate on Xeon, Gaudi, AMD EPYC, AMD Instinct, or NVIDIA hardware, and you accept that the repository is a set of samples rather than a maintained application. Do not adopt it if you need a stable API surface, a documented upgrade path between releases, or a deployment that does not require you to read the per-example compose files. Before committing, verify three things: which docker image tag the example you picked actually references (the docs point to docker_images_list.md rather than pinning tags inline), whether your Kubernetes version satisfies the Helm >= 3.15 requirement stated in the README, and whether the example's own README documents a supported path from v1.4 to v1.5. If any of those three is unanswered, you are reading source, not documentation.

Official sources

1. License: Apache-2.0
2. opea-project/GenAIExamples on GitHub
3. Project website
4. README
5. Releases