{"id":17484,"date":"2026-09-30T17:26:41","date_gmt":"2026-10-01T00:26:41","guid":{"rendered":"https:\/\/www.pingcap.com\/?post_type=article&p=17484"},"modified":"2026-09-30T17:30:44","modified_gmt":"2026-10-01T00:30:44","slug":"retrieval-augmented-generation-rag","status":"publish","type":"article","link":"https:\/\/www.pingcap.com\/ko\/article\/retrieval-augmented-generation-rag\/","title":{"rendered":"What Is RAG? Retrieval-Augmented Generation Explained"},"content":{"rendered":"

Ask a general-purpose language model about your company’s current pricing tiers or last week’s product changes, and it will either say it doesn’t know or, worse, confidently make something up. The model was trained on a fixed snapshot of data, so anything that happened after that snapshot, or anything private to your organization, is invisible to it. Retrieval-augmented generation (RAG) fixes this by retrieving relevant external data before the model generates a response, grounding the answer in real, current content instead of only what the model memorized during training.<\/p>\n\n\n\n

<\/span>Understanding Retrieval Augmented Generation (RAG)<\/strong><\/span><\/h2>\n\n\n\n

The Basics of RAG<\/strong><\/h3>\n\n\n\n

Retrieval Augmented Generation (RAG) is a framework that integrates two distinct yet complementary AI methodologies: retrieval-based models and generative models.<\/p>\n\n\n\n

    \n
  1. Retrieval-Based Models<\/strong>: These models excel in fetching relevant information from a large corpus of data. Given a query, a retrieval-based model searches through a database to find documents or passages that are most pertinent to the query.<\/li>\n\n\n\n
  2. Generative Models<\/strong>: These models, often based on transformer architectures like GPT-3, are designed to generate coherent and contextually appropriate text. They are capable of producing novel content based on the input they receive.<\/li>\n<\/ol>\n\n\n\n

    RAG combines these two approaches by first retrieving relevant documents or passages from a large dataset and then using this retrieved information to inform and enhance the generation of responses.<\/p>\n\n\n\n

    How RAG Works<\/strong><\/h3>\n\n\n\n

    The RAG framework typically involves the following steps:<\/p>\n\n\n\n

      \n
    1. Query Processing<\/strong>: When a query is received, the retrieval component of the RAG model searches a pre-indexed database to find the most relevant documents or passages.<\/li>\n\n\n\n
    2. Contextual Embedding<\/strong>: The retrieved documents are then converted into embeddings, which are vector representations that capture the semantic meaning of the text.<\/li>\n\n\n\n
    3. Response Generation<\/strong>: The generative model combines the original query with the embeddings of the retrieved documents to generate a response grounded in that retrieved content.<\/li>\n<\/ol>\n\n\n\n
      \"\"<\/figure>\n\n\n\n

      <\/span>Where RAG Pipelines Run Into a Routing Problem<\/strong><\/span><\/h2>\n\n\n\n

      A RAG pipeline that only searches unstructured documents works fine with a single vector store. Real applications rarely stay that simple. A support bot that needs to answer “What’s the status of order #48213 and does our return policy cover it?” has to pull a structured order record from one system and an unstructured policy document from another, then combine both in a single response.<\/p>\n\n\n\n

      Most teams solve this by running a vector database for embeddings alongside a separate relational database for structured records, then writing application code to query both and merge the results. Every new data source becomes a new system to provision, secure, and keep in sync.<\/p>\n\n\n\n

      <\/span>How TiDB Removes the Store-Per-Data-Type Decision<\/strong><\/span><\/h2>\n\n\n\n

      \ud2f0DB<\/a> stores structured relational data and vector embeddings in the same MySQL-compatible database, using a native VECTOR column type alongside ordinary SQL columns. A single query can filter on a structured field and rank by vector similarity in one statement:<\/p>\n\n\n\n

      SELECT order_id, status, description
      FROM support_docs
      WHERE order_id = 48213
      ORDER BY VEC_Cosine_Distance(description_vec, :query_embedding)
      LIMIT 5;<\/p>\n\n\n\n

      Because both the structured order record and the unstructured policy text live in the same schema, the routing decision from the previous section disappears. This is the same vector and transactional infrastructure that runs in production behind TiDB Cloud \uc2a4\ud0c0\ud130<\/a>-based AI agent platforms like Kimi’s agent hosting service<\/a>, which relies on the same underlying TiDB Cloud architecture at much larger scale than a typical RAG pipeline needs.<\/p>\n\n\n\n

      <\/span>\uc790\uc8fc \ubb3b\ub294 \uc9c8\ubb38<\/strong><\/span><\/h2>\n\n\n\n

      What is the difference between RAG and fine-tuning?<\/strong><\/p>\n\n\n\n