How To Build A Production Ready RAG AI - My Full AI Coding Workflow

Overview

This video is a complete, production-focused build walkthrough for a production-ready RAG (Retrieval-Augmented Generation) search system. The system ingests the creator’s own content and lets users search it, returning the most relevant topics with a link to the exact location in the source articles/videos.

What the System Does (Product Behavior)

Ingests

• Blog articles from an RSS feed
• YouTube videos using the YouTube Data API plus subtitles/captions

Indexing Strategy for Retrieval

• Content is chunked:
  • Blog content is chunked based on its HTML structure
  • YouTube content is chunked using caption timing/segments
• Each chunk is embedded and stored in a vector database for similarity search

User Search Flow

1. Users log in (GitHub auth).
2. The search query is embedded.
3. The system performs a vector similarity query.
4. It returns high-relevance matches only using a threshold.
5. Instead of returning raw chunks, it returns content pages:
   • Articles: highlights matched text
   • Videos: generates a URL with a start time parameter to jump to the relevant moment

Production Pipeline

• Uses dev/prod separation via environment variables.
• Runs database migrations during deploy to keep the DB schema consistent with the app code.

Tools and Infrastructure Used

• Neon: Postgres database with branching support
  • Used for dev/prod DB URLs and vector storage
• Vercel Workflows: Durable long-running/queued ingestion tasks
  • Includes retries, batching, and long waits
• CodeRabbit: Code reviews for security and correctness
  • Includes automatic suggestions/fixes
• Next.js: App UI + server actions/routes
• Better Auth: Authentication system
  • GitHub OAuth via Better Auth
• Drizzle ORM (including Drizzle 1.0 RC)
  • Typed schema + migrations
• pgvector extension (vector type)
  • Required to store embeddings and run vector similarity queries
• Embedding models:
  • Local development: LM Studio + local embedding model (e.g., Quen / 1024 dims)
  • Production: OpenAI embeddings (1536 dims)
    • Requires a separate migration/schema change for dimensions

Production Safety / Engineering Practices Emphasized

• Start from an existing repo and scaffold normally (don’t ask AI to generate the entire project immediately).
• Deploy incrementally to catch issues early.
• Enforce branch protection:
  • Block direct pushes to main
  • Require PRs for merging
• Use AI for code generation, but always manually review:
  • CodeRabbit is used heavily, but AI-generated code is still reviewed cautiously
• Secure long-running workflow endpoints:
  • Added a cron secret check (must match an env var; rejects unauthorized callers)

Ingestion Workflows (Core RAG Indexing)

1) Blog Ingestion Workflow (RSS-based)

1. Fetch RSS feed, parse items, and compute which articles are not already ingested
   • Filter based on existing URLs in the DB
2. Process each new article in batches of 10:
   • Fetch HTML
   • Extract:
     • thumbnail image (OG image)
     • text content from the main article section
3. Chunking strategy:
   • Initially described as chunking by H2 headings (hierarchical context chunks)
   • Later simplified/refactored with extensive testing
4. Store chunk records and related content records

Testing

• Added chunking unit tests using Vitest (via vest)
• Added “real world” HTML test cases

2) YouTube Ingestion Workflow (API + Captions)

• Uses YouTube Data API v3:
  • Gets the channel’s uploads playlist
  • Retrieves playlist items with pagination
  • Filters for public videos
• Fetches captions/subtitles:
  • Uses OAuth scopes for captions (with redirect/refresh token setup)
  • Parses subtitles into timed segments
• Chunking strategy for videos:
  • Uses caption text segments with overlap
  • Stores chunk start position to build accurate timestamps later
• Batching and quotas:
  • Processes in batches of 10
  • Includes a very long delay (9 hours) between batches to avoid quota limits

Search Implementation (Query-time Retrieval)

• The search page uses a server action that:
  1. Embeds the user query
  2. Queries vector similarity from pgvector
  3. Joins chunks → content (returns content results)
  4. Applies a relevance threshold (e.g., > 0.5)
  5. Returns up to 20 results (after ranking, not before)
• Retrieval quality improvements:
  • Corrected cosine similarity expression usage
  • Added missing vector search index support
  • Cleaned ordering/dedup logic:
    • distinct on content ID
    • then sort by similarity

Rate Limiting (Production Cost Control)

• Added a rate limit system to the search action:
  • Limits number of searches per user per time window
  • Stores search history (user id, query, createdAt, results/content ids)
• Frontend behavior:
  • UI displays a “rate limit exceeded” message when triggered
• Code adjustments:
  • Fixed error handling so rate limit errors propagate properly and don’t crash UI logic

Code Quality & Review Outcomes (What CodeRabbit Caught)

Security/Privacy

• Pass secrets explicitly instead of relying on env fallback names
• Enforce minimum secret length (Better Auth requirements)

Correctness

• Fix schema/adapter compatibility (Better Auth + Drizzle v1 RC)
• Enforce authentication at the server action layer (not only by hiding UI)

Query Correctness

• Fix similarity ranking and result limiting order

Main Speakers/Sources

• Kyle — “WebDev Simplified” (primary narrator/instructor)