RAG Document Q&A Agent with n8n, Supabase and Gemini

Finding one specific fact in a long report can mean searching through dozens of pages. I built this project to retrieve relevant parts of an OECD report on AI and labour-market skills and use them to answer focused questions.

My goal was to restore the document Q&A workflow and confirm that it could retrieve relevant passages from the report and answer specific factual questions correctly

The workflow has two main parts.

The ingestion branch downloads the PDF from Google Drive, reads its content, splits it into chunks, creates Gemini embeddings, and stores the chunks in Supabase.

The chat branch connects a Gemini-powered agent to the Supabase vector store and conversation memory. The retrieval tool can return up to two matching chunks for each request. I used gemini-embedding-001 for both document and question embeddings so they stayed in the same vector space.

How it works

PDF → Text Chunks → Gemini Embeddings → Supabase → User Question → Vector Search → AI Answer

This workflow first converts the document into smaller text chunks and stores their embeddings in Supabase. When a question is asked, the workflow finds the most relevant chunks and uses them to generate a grounded answer.

When I returned to this project in September 2026, the original local environment was no longer available. I recovered the exported workflow in n8n Cloud, reconnected Google Drive, and resumed the existing Supabase project. Before making changes to the active vector store, I backed up and checked all 442 historical records.

The first fresh ingestion attempt failed with the error vector must have at least 1 dimension. I traced the problem to unusable embedding output, switched the workflow to gemini-embedding-001, and confirmed that it was producing 3,072-dimensional vectors.

The Supabase column was still configured as vector(768), so I migrated it to vector(3072). I then processed the 55-page PDF again and stored 212 fresh document chunks. The original 442-record backup was kept separately.

I also corrected the agent prompt so it matched the document actually being used: Artificial Intelligence and the Changing Demand for Skills in the Labour Market, OECD Artificial Intelligence Papers No. 14, published in April 2024.

For the chat side of the workflow, I restored direct Gemini API access and connected a Gemini Flash chat model. The chat model and embedding model remained separate

The restored workflow successfully completed document ingestion and a retrieval-backed question-answering test. A Supabase check confirmed 212 records in public.documents and an embedding column configured as vector(3072).

For one controlled test, I asked the agent to compare two skill categories in occupations with high AI exposure. It returned 72% for vacancies requiring at least one management skill and 67% for vacancies requiring at least one business processes skill. Both figures matched the OECD report, and the calculated difference of five percentage points was also correct.

The n8n execution view showed the retrieval components running during the request. For this test, the retrieval path worked and the final answer was correct. I do not treat this single result as an overall accuracy score for the system.

Limitations

I tested the restored workflow using a temporary n8n Cloud trial, so there is no permanent public deployment.

I also did not run a formal retrieval or answer-quality benchmark. Production monitoring, security hardening, and scalability testing were outside the scope of this version.

This recovery made the relationship between embeddings and the vector database much clearer to me. Changing the embedding model also meant checking the database dimensions and making sure question embeddings used the same setup as the stored documents.

I also learned that a successful database connection does not prove retrieval is actually working. Checking the stored records, vector dimensions, and n8n execution trace helped me verify each part separately.