Skip to content

Latest commit

 

History

1 Commit

Folders and files

NameName
Last commit message
Last commit date
 
 

Repository files navigation

SQL Server Natural Language Search — RAG vs MCP (POC)

Overview

This repository is a proof of concept (POC) exploring two architectural approaches for translating natural-language queries into searches over structured SQL Server data.

The goal is to understand the tradeoffs between:

  • RAG (Retrieval-Augmented Generation) — embedding records and retrieving via vector similarity
  • MCP / Tool-Driven Querying — using an LLM to reason over schema and generate structured SQL queries directly

This is a learning-focused POC using production-like data and realistic architecture patterns, without attempting to solve full-scale performance, security, or operational concerns.


Problem Statement

Users often think in natural language, while databases require precise, structured queries.

Example user intent:

“Find someone in NYC, hybrid role, healthcare data entry experience, placed within the last year.”

Much of this intent maps cleanly to structured fields (location, dates, tags, status), but the challenge is bridging intent → structure reliably.

This POC explores how best to make that translation.


Approaches Compared

1. MCP / LLM-to-SQL (Schema-Aware)

Flow

  • User query → LLM
  • LLM reasons over schema + constraints
  • Generates validated SQL
  • SQL Server executes query
  • Results returned directly

Strengths

  • Precise, deterministic filtering
  • Leverages existing indexes and constraints
  • Easier to audit and debug
  • Strong fit for well-structured data

Risks / Questions

  • Hallucinated or invalid SQL
  • Schema drift handling
  • Guardrails and query safety

2. RAG (Embeddings + Retrieval)

Flow

  • Records embedded into vectors
  • User query embedded
  • Vector search retrieves candidates
  • LLM summarizes and/or filters results

Strengths

  • Handles fuzzy language and vague intent
  • Good for unstructured or semi-structured fields
  • Flexible reasoning layer

Risks / Questions

  • Weaker precision for hard filters (dates, locations)
  • Additional infrastructure (embedding store, sync jobs)
  • Harder to explain why something matched

What This POC Focuses On

  • SQL Server as the source of truth
  • Realistic schemas and data shapes
  • Query correctness and explainability
  • Architectural clarity over optimization
  • Comparing accuracy, complexity, and developer experience

Explicit Non-Goals

  • Full production hardening
  • High-scale performance tuning
  • UI/UX polish
  • Multi-tenant security
  • Client-specific workflows

Key Questions This Repo Tries to Answer

  • When does LLM-to-SQL outperform RAG for structured data?
  • Where does RAG add value vs introduce noise?
  • How explainable are results in each approach?
  • Which architecture is simpler to maintain long-term?

Why This Exists

Before committing to a larger system, this repository exists to learn the shape of the problem and make informed architectural decisions—using real data patterns, not toy examples.

About

A comparative POC of Text-to-SQL vs. Vector RAG architectures for querying structured CRM data.

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Used by

Contributors