RAG 논문 백엔드 관점으로 읽기

How will the service structure change if you combine search and creation?

In this article, we read the RAG original paper “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks” from the perspective of a back-end developer.

When people first encounter RAG, they usually understand it as “searching for vectors and putting them into LLM.” It's not wrong, but it's not enough to create an actual service. RAG is not a simple function, but an architecture that changes the storage location of knowledge.

The model not only uses the knowledge it has in internal parameters, but also searches an external document repository and reflects it in the answer. From a back-end perspective, the problem is “how to store, retrieve, and connect to evidence the knowledge that LLM does not know.”

Analysis base date: 2026-05-12 Practice reference environment: PostgreSQL, pgvector, embedding model, LLM API Main reference materials: RAG Paper, pgvector Docs, OpenAI Evals Docs

Key takeaways

• RAG is an approach that combines parametric memory and non-parametric memory.
• From a backend perspective, RAG is a combination of a document repository, searcher, generator, and evaluator.
• The core of RAG is not “I searched,” but “I reliably provide well-founded answers.”
• Search quality and generation quality should be assessed separately.
• Citation, authority, recency, and re-indexing are key issues in RAG operation.

1. Why you should watch RAG

LLMs have a lot of knowledge, but they don't know everything up to date. Your organization's internal documents, latest policies, product manuals, failure reports, and codebase documents may not be in your model's training data.

RAG is a representative structure for solving this problem.

1# This is an example.2user questions3to Search related documents4to Configure the searched documents into context5to LLM generates context-based answers6to Reply with source

2. Critical awareness of the paper

The RAG paper believes that large pre-trained models store factual knowledge in parameters, but have limitations in accurately accessing, updating, or providing sources of knowledge.

If we change it to a backend perspective, it looks like this.

1# This is an example.2With only knowledge inside the model,3- It is difficult to reflect the latest documents.4- It is difficult to provide sources.5- It is difficult to reflect knowledge by organization.6- Difficult to track wrong answers.

So we need an external knowledge repository.

3. Parametric Memory and Non-parametric Memory

In practice, non-parametric memory is very important. This is because if the document changes, the index can be updated rather than retraining the model.

4. retriever and Generator

RAG is a combination of a searcher and a generator.

1# This is an example.2retriever:3Find document chunks related to your question.4 5Generator:6An answer is generated based on the retrieved chunk.

It is not enough to like just one of the two. If the searcher retrieves the wrong document, the answer may be wrong no matter how good the generator is. Conversely, even if you import a good document, if the generator ignores the evidence, the quality deteriorates.

5. Interpreting with backend architecture

If we draw the RAG service as a backend structure, it looks like this:

1# This is an example.2Document Source3→ Ingestion Worker4→ Chunking5→ Embedding6→ Vector Store7→ Retrieval API8→ Prompt Builder9→ LLM10→ Response Validator11→ Citation Renderer12→ Eval Logger

The important operational points in this structure are:

6. Failure types of RAG

The most dangerous thing about RAG is when the answer is plausible but the evidence is wrong.

7. Evaluate search quality and answer quality

RAG evaluation should be divided into two steps.

Example metrics:

1# This is an example.2retrieval_precision@k3retrieval_recall@k4answer_correctness5citation_accuracy6groundedness

Directions for improvement can only be seen by separating whether search or creation failed.

8. Practical application checklist

1# This is an example.2[ ] Do you save the document source and version?3[ ] Is chunk_id connected to citation?4[ ] Is there a plan for re-indexing when the embedding model changes?5[ ] Is metadata filter applied to vector search?6[ ] Are user rights enforced during the retrieval step?7[ ] Are search quality and answer quality evaluated separately?8[ ] Can the stale index be detected?9[ ] Are RAG failure cases accumulated as an eval dataset?

9. Q&A

Q1. Does RAG replace fine-tuning?

This isn't always the case. If providing up-to-date external knowledge, internal organization documentation, and sources is important, RAG is beneficial. Fine-tuning may be more appropriate for learning a specific style or task pattern.

Q2. Is it enough to just use vector search?

This may be sufficient initially. However, if the keyword contains many important documents, numbers, codes, or proper nouns, a hybrid search may be necessary.

Q3. How do I increase RAG quality?

We need to improve search queries, chunking, embedding, metadata filter, reranking, prompt, and eval together. If you only change one thing, it's easy to miss the cause.

10. References and uncertainty

References

• RAG Paper:https://arxiv.org/abs/2005.11401
• pgvector:https://github.com/pgvector/pgvector
• OpenAI Evals:https://platform.openai.com/docs/guides/evals

uncertainty

• The structure of the RAG paper and the current production RAG implementation may differ.
• The optimal combination of chunking, embedding, and reranking varies from dataset to dataset.

Backend application example: Replacing RAG paper terminology with service components

The explanation directly addressed by the paper is the distinction between parametric memory and non-parametric memory.

This is the explanation in the paper. Moving to a backend service requires separation of roles. The model generates the answer, the document store and retriever pick the evidence, and the API layer is responsible for permissions and traces.

A failure case is to understand RAG only as a “chatbot with vector search”. The explanation in the paper is that it combines search and generation to place the knowledge source outside the model.

The service interpretation of this article is that the source must be left as document version, chunk id, authority, and citation. That way, if the answer is wrong, you can not only correct the prompt, but also determine which of the search candidates, chunk policy, reranker, and evaluation data is the problem.

This distinction is also necessary in operational retrospectives. The structure mentioned in the paper does not directly determine a specific DB schema. Schema, permissions, trace, and eval dataset are implementation interpretations for which the service team is responsible. So, rather than mixing thesis facts and product design decisions in the same paragraph, you should write the rationale and application separately.