Custom GPT vs Gem vs RAG vs a Skill.

Retrieval as suggestion, not instruction.

When you attach a knowledge file to a Custom GPT, ChatGPT runs a retrieval step before generating the answer. It converts your query into a vector, finds the closest chunks in your file, and prepends them to the prompt. In theory, the model should then answer from those chunks. In practice, two things undermine this consistently.

First, the retrieval step is probabilistic. If the chunk that actually contains your answer scores lower than the model's prior training data on the same topic, the model ignores the retrieved chunks entirely. The model has read the internet. If your document covers a topic the model already "knows," it will often answer from that prior knowledge and not from your file — even if your file has a different, more specific, or contradictory answer.

Second, knowledge files in Custom GPTs are chunked and indexed at upload time using a fixed chunking strategy designed for general retrieval. It was not designed for domain-expert knowledge where the answer to question B is meaningful only in the context of framework A, defined six sections earlier. The retrieval surfaces B without A, and the answer loses its grounding.

The result is the experience almost everyone who has tried Custom GPTs for knowledge work describes: the model answers confidently, often correctly in a generic way, and entirely from training data rather than from your file. You uploaded the knowledge. The AI thanked you for it and then ignored it.

Gemini Gems have the same underlying architecture. The symptoms are identical. Uploading your brand guide or your methodology to a Gem does not guarantee the Gem will use it — retrieval is treated as a hint, not a constraint.

The RAG tax: chunking, embedding, and eval.

A RAG pipeline has three components that each require ongoing attention. Chunking is the process of splitting your source documents into pieces small enough to fit in a retrieval query but large enough to contain meaningful context. Getting this wrong — chunks too small, and answers lose context; too large, and retrieval becomes imprecise — is the most common reason RAG systems answer from the wrong passage.

Embedding is the conversion of each chunk into a vector representation. Different embedding models produce different vector spaces; the one that works well for your domain may not be the default. You need to evaluate whether the embeddings actually represent semantic similarity for your content type, not just for the generic English-language text the model was trained on.

Evaluation is the part nobody talks about when pitching RAG. Once the pipeline is built, you need to test whether retrieval actually surfaces the right chunks for a representative set of queries. This means building a test set, running it, measuring precision and recall, and fixing the cases where it fails. When your source document changes, you re-embed, re-chunk, and re-evaluate.

For a large, living corpus maintained by an engineering team — a company knowledge base, a codebase, a continuously updated documentation set — RAG is the right tool. The infrastructure cost is justified by the scale and the ongoing value.

For an expert who owns a methodology and wants their AI to know it: RAG is a weekend project that turns into a second job. The source is fixed. The domain is specific. The knowledge doesn't change every day. For this use case, a structured skill file is the right scope of solution.

Where RAG genuinely wins.

We want to be clear about this: RAG is not a bad choice. It is the correct choice for:

• Large corpora — thousands of documents or more
• Living corpora — content that changes daily or weekly
• Engineering teams who can maintain infrastructure
• Applications requiring real-time data integration

If that describes your situation, you probably don't need SkillPill. We'll say so directly at the bottom of this page.

Engineered index, not a blob.

The core architectural difference is that a skill is not a flat document dump. It is a structured pack built to the open SKILL.md standard: an index the AI reads first, chapters the AI loads only when the question requires them, a glossary for every domain-specific term, a cheatsheet for fast decisions, and a patterns file for recurring techniques.

The index does something that retrieval cannot: it tells the AI what is in the skill and when to use it. Before the AI answers, it reads the index and decides whether to load Chapter 3 or Chapter 7 based on what the question is actually asking. This is not probabilistic. The chapter either exists or it doesn't. The AI either loads it or it doesn't.

The result is that the knowledge in a skill is actually used. Not sometimes. Not when the retrieval score happens to be high. Every time.

On-demand chapters.

A Custom GPT or a Gem loads your entire knowledge file into the context window at once, every time, regardless of whether the query needs it. This is expensive (context tokens are limited and costly), imprecise (the relevant signal is buried in noise), and unreliable (the model loses focus in long contexts).

A skill loads only the chapter that matches the question. For a 300-page book turned into a skill, a question about Chapter 4's framework loads Chapter 4 — not the whole book. The signal-to-noise ratio is vastly higher. The AI's attention is not divided across 300 pages of material, most of which is irrelevant to this question.

QA-traced citations.

Before a skill ships, every claim is traced back to a specific passage in your source. If a claim cannot be verified, it doesn't go in. This is the QA step — not spell-checking, not a vibes-based review, but a systematic pass where each fact, quote, and reference is cross-checked against the original material.

The practical implication: when your AI cites your page number, that citation is real. It came from your source. It was verified before the skill was delivered. This is the answer to the question that custom GPT users always end up asking: "Is this answer from my file, or did you make it up?" With a skill, you already know. The QA said so.