RAG vs. text-to-code vs. extract-score-generate: three patterns for AI projects

Say "AI project" to most students and the mental image is the same: a chatbot. Ask it a question, get an answer. That's a fine pattern for some problems and a genuinely bad fit for others — and understanding why is worth more than being able to build one more RAG chatbot that looks like everyone else's.

Here are three different architectures, each solving a different kind of problem, illustrated with real projects built around each one.

Pattern 1: Retrieval-Augmented Generation (RAG)

The problem it solves: answering questions grounded in a specific body of content — a PDF, a video transcript, a knowledge base — where the answer already exists somewhere in the source, and the job is to find it and phrase it clearly.

How it works: source content gets chunked and embedded into a vector index; a question gets matched against that index to retrieve the relevant passages; those passages get handed to a language model to generate the final answer, cited back to the source.

When it fits: the answer is a fact or explanation that exists in the source material, more or less as written. "What does section 3.2 say," "what did the speaker say about X," "summarize this document" — all genuinely retrieval problems.

When it doesn't fit: anything that requires computing something the source doesn't state directly. RAG can tell you what a document says about revenue; it can't tell you the month-over-month growth rate unless that exact number happens to be written down somewhere.

Pattern 2: Text-to-code

The problem it solves: open-ended analytical questions over structured data — spreadsheets, databases — where the answer has to be computed, not found. "What % of contribution is male vs. female this month" isn't sitting in any cell of a spreadsheet; it has to be calculated.

How it works: the model is given a summary of the data's schema — column names, types, a few sample rows — and writes actual code (commonly pandas and a charting library) to answer the specific question. That code runs in a restricted, sandboxed environment, and its output — a chart or a computed value — is the answer.

When it fits: genuinely open-ended questions over tabular data, where a fixed set of pre-built charts or queries can't anticipate every question a user might ask.

The catch: since a model is writing code you didn't write yourself, execution has to be sandboxed — no file access, no network access, only the approved libraries and the data in scope — and you need a retry path for when generated code fails on the first attempt, usually by referencing a column name slightly wrong.

Pattern 3: Extract, score, generate

The problem it solves: comparing two things against each other and producing an explainable judgment — not retrieving a fact, not computing an open-ended answer, but scoring a match and explaining why. A resume against a job description is the clearest example: is this a good fit, and specifically why or why not.

How it works: structured data gets extracted from both inputs first — skills, requirements, qualifications — converting unstructured text into comparable fields. Then an explicit, documented formula compares those structured fields and produces a score broken into named components, rather than asking a model to output one opaque number directly.

When it fits: any comparison task where the reason behind a judgment matters as much as the judgment itself — which is most real decision-support tools. A single black-box score a user can't interrogate is far less useful than a broken-down one they can actually act on.

Why not just ask a model for a score directly? You could — it's simpler to build — but it's far less explainable. A single number gives no way to know which requirement drove the score down, or what to actually change. Decomposing the score into named, weighted components makes it auditable, and lets you point to specific gaps rather than a vague verdict.

Picking the right pattern for your own project

The fastest way to pick wrong is to start from "I want to build an AI chatbot" and work backward. Start from the actual problem instead: is the answer sitting somewhere in existing content (RAG), does it need to be computed from structured data (text-to-code), or is it fundamentally a comparison that needs an explainable judgment (extract-score-generate)? The architecture should follow from that answer, not the other way around — and being able to explain why you picked the pattern you did is exactly the kind of question a viva panel is going to ask.