Built an AI real estate assistant using n8n + RAG + Supabase

[Patricia_F]

Hi n8n community

I wanted to share a project I recently built: Wo Fie AI — an AI-powered real estate knowledge assistant.

The problem:
Real estate teams often have property information spread across documents, messages, and different systems. Finding accurate information quickly can become time-consuming.

The idea:
Build an AI assistant that can retrieve relevant property information through natural language queries.

Workflow architecture:

n8n → workflow orchestration
Document processing → knowledge preparation
Supabase Vector Store → semantic search
Embeddings → information retrieval
LLM → generate contextual responses

The workflow:

1. Property information is processed and stored
2. User asks a question
3. Relevant information is retrieved from the knowledge base
4. The AI generates a response based on available data

Some things I focused on:

• keeping responses grounded in available information
• structuring workflows for scalability
• connecting AI agents with business operations

Still improving the system and would love feedback from the community.

Curious:
How are others handling memory, retrieval quality, and evaluation for RAG workflows built with n8n?

[nguyenthieutoan]

Nice setup, especially separating document processing from retrieval so the knowledge base stays clean as property data grows. For retrieval quality on real estate data specifically, adding metadata filters (property type, location, price range) alongside the vector search helps a lot since pure semantic similarity can surface outdated or irrelevant listings. For evaluation, I’d log query plus retrieved chunks plus final answer to a Postgres table and periodically review a sample manually, that catches hallucinated details before they reach a client-facing chat.

[shedrach]

Nice build! I recently faced similar challenges while building a RAG workflow in n8n, and a few things made a big difference:

• I switched from retrieving the top 10 chunks to the top 4–5 most relevant ones. That alone reduced hallucinations and made responses much more focused.
• I attach metadata like property location, price range, status (available/sold), and document type to every chunk, then filter on that before running the vector search.
• For memory, I don’t save every message. I only keep a short conversation summary and let the vector store handle factual retrieval. It keeps the context clean and reduces token usage.
• Whenever a property document is updated, I delete the old vectors and re-embed only the affected document instead of rebuilding the entire index.
• I also log questions where the AI responds with “I don’t know” or retrieves low-confidence results. Those logs help me identify missing documents or improve chunking.

One thing I’m curious about: how are you handling document chunking? Are you using a fixed token size (e.g., 500–800 tokens) or splitting by sections? I found that chunking by logical sections usually gives much better retrieval than fixed-size chunks.

[Patricia_F]

Thanks for the thoughtful feedback

You’re absolutely right about metadata filtering. The current workflow focuses on retrieval through the knowledge base, but adding structured filters like location, property type, and pricing would make the system much more reliable as the dataset grows.

I also like the idea of logging the retrieval process; query, retrieved context, and final response for evaluation and improving answer quality over time. That’s definitely something I’d consider as the system moves closer to a production environment.

I appreciate you sharing these insights

[Patricia_F]

Thanks for sharing these valuable insights

I agree that retrieval quality often comes down to the details beyond just connecting a vector database. The points around reducing retrieved chunks, metadata filtering, and maintaining cleaner context are especially useful for a domain like real estate where accuracy and freshness matter.

For document chunking, I’m currently using a more structured approach rather than relying purely on fixed-size splitting. Since property information usually follows predictable sections (location, pricing, features, availability, etc.), splitting based on logical structure makes a lot of sense for improving retrieval relevance.

I also like your approach of only storing conversation summaries for memory and keeping factual information in the vector store. It’s a cleaner architecture.

Thanks again for the suggestions. I’ll definitely look into these improvements as I continue refining the workflow.