Retrieval Augmented Generation (RAG) grounds LLM responses in documents you control, rather than relying only on what the model learned during training. This example ships as
RagExampleWorkflow in app/launchpad/workflows/examples/pgvector_rag/.pgvector extension enabled.
Why pgvector?
- Simple setup — no additional vector database; the default PostgreSQL service already has pgvector available.
- Single source of truth — vectors live next to your relational data, so retrieval queries can join against business tables.
- Cost effective — no separate vector database to operate or pay for.
Components
The workflow is a two-node pipeline:RetrievalNode → GenerationNode.
Retrieval
Generation
Running the example
1
Start the stack
From
docker/, run ./start.sh to bring up the API, Celery worker, Redis, and PostgreSQL with pgvector. Supabase services and Caddy stay disabled unless you uncomment them in docker-compose.yml.2
Apply migrations
From
app/launchpad/, run ./migrate.sh so the pgvector extension and tables exist.3
Insert embeddings
Use
PgvectorRAGService directly to seed your collection:4
Run the workflow
Use the dedicated playground script to exercise the whole pipeline against a sample query:The script loads
app/launchpad/workflows/examples/pgvector_rag/request_examples/query.json, instantiates RagExampleWorkflow, and prints the generated answer with sources and confidence.Customization
- Swap embedding model — pass a different
embedding_modeltoPgvectorRAGService(defaulttext-embedding-3-small, 1536 dims). - Change retrieval — adjust
limit,measure, or metadata filters oncollection.query(...)inRetrievalNode. - Change generation model — update
model_provider/model_nameinGenerationNode.get_agent_config.