{"id":787,"date":"2026-07-14T08:00:00","date_gmt":"2026-07-13T23:00:00","guid":{"rendered":"https:\/\/blog.hancom.com\/rag-chunking-embedding-vectordb\/"},"modified":"2026-07-16T15:25:21","modified_gmt":"2026-07-16T06:25:21","slug":"rag-chunking-embedding-vectordb","status":"publish","type":"post","link":"https:\/\/blog.hancom.com\/en\/rag-chunking-embedding-vectordb\/","title":{"rendered":"What is RAG? A Pipeline Guide from Chunking and Embedding to Vector DB Storage"},"content":{"rendered":"\n

Have you ever asked ChatGPT a question only to receive a completely unrelated answer? This is known as AI hallucination. RAG (Retrieval-Augmented Generation) is a technology developed to structurally compensate for this limitation. <\/p>\n\n

<\/div>\n\n

What is RAG? Why It Emerged in the LLM Era <\/strong><\/h2>\n\n

Understanding RAG Meaning and Concepts Easily<\/strong><\/h3>\n\n

RAG (Retrieval-Augmented Generation) is an AI architecture that retrieves external documents and generates answers based on that content. Its key feature is the ability to reference the latest documents or internal corporate data in real time. <\/p>\n\n

<\/div>\n\n

Limitations of Existing LLMs and the Difference Between LLM and RAG<\/strong><\/h3>\n\n

LLMs (Large Language Models) have fixed training data, meaning they cannot access the latest information and may suffer from hallucinations, where they present non-existent information as fact.<\/strong> It is also difficult to utilize private information, such as internal corporate documents.<\/p>\n\n

RAG addresses both limitations simultaneously by searching external documents in real time and reflecting them in responses. As search evidence is provided, the risk of hallucination decreases, and internal materials can be utilized. <\/p>\n\n

Category<\/strong><\/td>LLM Alone<\/strong><\/td>RAG<\/strong><\/td><\/tr>
Information Scope<\/td>Up to the point of training<\/td>Real-time reference to external documents<\/td><\/tr>
Hallucination Risk<\/td>High<\/td>Low (based on search evidence)<\/td><\/tr>
Internal Data Utilization<\/td>Impossible<\/td>Possible<\/td><\/tr>
Reflecting Latest Information<\/td>Impossible<\/td>Possible<\/td><\/tr><\/tbody><\/table><\/figure>\n\n

So, how does RAG differ from fine-tuning? <\/p>\n\n

Fine-tuning is a method of retraining the model itself with specific domain data. It involves high training costs and requires retraining whenever new data is added. <\/p>\n\n

In contrast, RAG has lower maintenance costs because you only need to replace external documents without touching the model. If you need to reflect real-time information or utilize internal corporate documents, RAG is the practical choice. <\/p>\n\n

<\/div>\n\n

Understanding the Entire RAG Pipeline Structure<\/strong><\/h2>\n\n

How Does the RAG Pipeline Work?<\/strong><\/h3>\n\n

RAG operates in the following order: Document Upload \u2192 Parsing \u2192 Chunking \u2192 Embedding \u2192 Vector DB Storage \u2192 Retrieval \u2192 Answer Generation.<\/strong><\/p>\n\n

If the quality of the early stages is low, all subsequent stages are affected.<\/p>\n\n

In practice, when RAG quality is poor, the cause is often in the parsing and chunking stages rather than the LLM. Among these, document parsing is handled by the data loader, while processes after chunking are performed by a separate RAG system. Empirical experiments have confirmed that low PDF parsing quality directly degrades the performance of specialized knowledge-based QA. <\/p>\n\n

\ud83d\udca1 Stuck at the first step of the RAG pipeline?<\/strong> <\/p>\n\n

\ud83d\udc49 Explore Hancom Data Loader<\/a><\/p>\n\n

<\/div>\n\n
\"Image<\/figure>\n\n
<\/div>\n\n

RAG Search Accuracy: Why is Document Structure Important?<\/strong><\/h2>\n\n

What is Document Parsing?<\/strong><\/h3>\n\n

Document parsing is the process of converting unstructured documents such as PDF, HWP, HWPX, and PPT into structured data that AI can understand.<\/strong> Unlike simple text extraction, it meaningfully organizes the row and column relationships of tables and the hierarchical structure of headings and body text, outputting them in structured formats like JSON or HTML.<\/p>\n\n

The situation is different for HWP and HWPX, which are most commonly used in Korean public and corporate environments. Major global Document AI solutions such as AWS Textract<\/a>, Azure Document Intelligence<\/a>, and Google Document AI<\/a> only support general-purpose formats like PDF, JPEG, PNG, and TIFF, and do not support direct parsing of original HWP or HWPX files. This becomes the first bottleneck for organizations trying to connect Korean documents to RAG. <\/p>\n\n

<\/p>\n\n

What Happens in RAG if the Document Structure is Broken?<\/strong><\/h3>\n\n

If the document structure is lost, the AI generates incorrect answers based on the broken text.<\/strong><\/p>\n\n

If meeting minutes with a two-column layout are extracted as simple text, the reading order is reversed. The AI cannot properly distinguish the mixed text, so even if you ask about decisions made in the March meeting, it may answer by mixing in content from other agenda items. Documents containing tables are even more critical. If the row and column structure in a budget table collapses, the AI fails to understand the relationship that ‘Q1’ and ‘200 million KRW’ belong to the same item, leading to incorrect numerical answers. <\/p>\n\n

RAG systems with enhanced structural parsing were found to provide more accurate answers in approximately 47%<\/a> of questions compared to baseline systems. Document parsing quality is a key variable that determines the overall performance of RAG. <\/p>\n\n

<\/div>\n\n
\"Image<\/figure>\n\n
<\/div>\n\n

Why OCR Alone is Insufficient for RAG<\/strong><\/h2>\n\n

Difference Between OCR and Document Layout Analysis, and Why HWP\/HWPX Parsing is Difficult<\/strong><\/h3>\n\n

OCR (Optical Character Recognition) is a technology that converts characters into text, while DLA (Document Layout Analysis) is a technology that analyzes the position and meaning of elements within a document to identify its structure and relationships, such as headings, body text, tables, and images. <\/strong><\/p>\n\n

Even for the same ‘200 million KRW,’ the AI understands it completely differently depending on whether it is a value in a table or a description in the body text. <\/p>\n\n

OCR merely recognizes characters; DLA is required to determine the role and hierarchy of those characters within the document. According to SCAN research<\/a>, traditional layout analysis methods that simply break down headings, paragraphs, and tables into small units can break the context and actually reduce visual RAG accuracy by up to 40.5%. <\/p>\n\n

In contrast, experiments have confirmed that DLA techniques designed to preserve context can increase text RAG accuracy by up to 9.0% and visual RAG accuracy by up to 6.4%. <\/p>\n\n

Since HWP and HWPX are proprietary formats optimized for the Korean work environment, it is difficult for general tools to fully read their internal structures. Converting them to PDF for parsing results in the loss of key formatting such as footnotes and merged table cells. Without technology that directly accesses the HWP\/HWPX file structure, it is difficult to secure structured data at the RAG level. <\/p>\n\n

<\/div>\n\n

\ud83d\udca1 Wondering how to connect HWP originals to RAG while maintaining their structure?<\/strong><\/p>\n\n

Check out how to directly parse HWP originals without PDF conversion and preserve table and paragraph hierarchies through DLA and TSR. <\/p>\n\n

\ud83d\udc49 View Hancom Data Loader Live Demo<\/a><\/p>\n\n

<\/div>\n\n
\"Image<\/figure>\n\n
<\/div>\n\n

How Do Chunking, Embedding, Vector DB Storage, and RAG Retrieval Work?<\/strong><\/h2>\n\n

Chunking Meaning and Strategy Comparison<\/strong><\/h3>\n\n

Chunking is the process of dividing long documents into small semantic units that are easy for AI to search. The choice of chunking strategy directly impacts the reliability of the RAG system. <\/p>\n\n

Fixed-size Strategy<\/strong><\/h4>\n\n

Simple to implement, but sentences may be cut off in the middle. Used when processing speed is the priority. <\/p>\n\n

Semantic-based Strategy<\/strong><\/h4>\n\n

Cuts where the content changes. High accuracy, but processing costs are relatively high. <\/p>\n\n

Recursive Strategy<\/strong><\/h4>\n\n

Splits according to the hierarchy in the order of Heading \u2192 Paragraph \u2192 Sentence.<\/p>\n\n

RAG chunking and LLM chunking have different purposes. While LLM chunking is to fit within token limits, RAG chunking is to structure the data so that meaningful pieces are retrieved during search. <\/p>\n\n

Good chunking ultimately starts with good parsing. This is because semantic unit chunking is only possible when the document’s heading, paragraph, and table hierarchies are accurately extracted. <\/p>\n\n

<\/div>\n\n

Embedding, Vector DB Storage, and Causes of RAG Search Failure<\/strong><\/h3>\n\n

Embedding<\/strong> is a technology that converts text into numerical arrays, allowing AI to search based on meaning. Even if expressions differ, such as ‘automobile’ and ‘vehicle,’ they are recognized as the same context if the meanings are similar. Simply put, it is the process of representing the meaning of words and sentences as numbers so the AI can understand them, and connecting content with similar meanings closely together. <\/p>\n\n

A vector DB is a database that stores this converted data and quickly finds information most similar in meaning to a question. It is similar to how a librarian finds relevant materials based on the meaning of the content rather than just the book title. <\/p>\n\n

If there is incorrect chunking or loss of table structure, the meaning is already blurred at the embedding stage, limiting vector DB search accuracy no matter how good the LLM connected to it is. This is why the quality of the RAG data pre-processing stage determines the final answer quality. Hancom Data Loader handles the parsing stage, and the subsequent stages of chunking, embedding, vector DB storage, and retrieval can be configured in conjunction with Hancompedia. <\/p>\n\n

<\/div>\n\n
\"Image<\/figure>\n\n
<\/div>\n\n

RAG FAQ: Frequently Asked Questions<\/strong><\/h2>\n\n
<\/div>\n
\n
\n
\n

Q1. Why is chunking important in RAG? <\/strong><\/h3>\n
\n\n

If chunking is done incorrectly, the semantic units of the document are broken, leading to low embedding quality and a decrease in both search accuracy and answer quality. Chunking that maintains semantic units is a key variable for the overall performance of the RAG system. <\/p>\n\n<\/div>\n<\/div>\n

\n

Q2. Is it possible to build RAG without vector DB storage? <\/strong><\/strong><\/h3>\n
\n\n

It is possible, but a vector DB is practically necessary for stable semantic-based search in large-scale documents. As the number of documents increases, the role of vector DB storage becomes even more important. <\/p>\n\n<\/div>\n<\/div>\n

\n

Q3. Can HWP and HWPX files also be used for RAG? <\/strong><\/strong><\/strong><\/h3>\n
\n\n

Yes, it is possible. However, since HWP and HWPX use proprietary file structures, table structures or formatting information may be lost in general parsers. Hancom Data Loader analyzes the original HWP\/HWPX structure to minimize the loss of table structures and formatting information, unlike general parsers. <\/p>\n\n<\/div>\n<\/div>\n

\n

Q4. What tools can be used for RAG document pre-processing? <\/strong><\/h3>\n
\n\n

You can use Document Loaders built into frameworks like LangChain or LlamaIndex, but documents containing HWP\/HWPX or complex tables may suffer from structural loss. In such cases, connecting a specialized parsing solution based on DLA and TSR to the front end of the pipeline is effective. Hancom Data Loader supports direct parsing of HWP\/HWPX originals and on-premise installation, making it suitable for public, financial, and legal environments. <\/p>\n\n<\/div>\n<\/div>\n

\n

Q5. Which document format is advantageous for parsing quality when building RAG? <\/strong><\/strong><\/strong><\/strong><\/h3>\n
\n\n

Rather than the format itself, how accurately that format can be parsed is more important. In air-gapped environments, whether a solution can run on an internal server becomes a key selection criterion. <\/p>\n\n<\/div>\n<\/div>\n

\n

Q6. Is RAG document pre-processing possible in an air-gapped environment? <\/strong><\/h3>\n
\n\n

Cloud API-based solutions are difficult to use in network-isolated environments as they require an external network. Hancom Data Loader supports on-premise deployment using Docker-based REST APIs, and the SaaS API method can be integrated immediately without separate installation. In particular, it can be operated in air-gapped environments where it is installed directly on the client’s internal server, allowing for flexible response to environments with high security requirements such as public, financial, and legal sectors. <\/p>\n\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n

<\/div>\n\n
\"Introductory<\/a><\/figure>\n\n
<\/div>\n\n

How to Actually Solve HWP and HWPX Parsing in RAG Document Pre-processing?<\/strong><\/h2>\n\n

To connect HWP and HWPX documents to RAG without structural loss, an environment capable of directly parsing the original formats is required.<\/p>\n\n

External cloud APIs cannot be used in air-gapped networks, and there were virtually no parsing tools that fully supported the unique structure of HWP and HWPX. Hancom Data Loader solves this problem as follows: <\/p>\n\n

\u2705 The Only Solution Supporting HWP and HWPX in Korea<\/strong> <\/p>\n\n

Directly extracts data from original files without PDF conversion based on Hancom’s 30 years of core technology<\/p>\n\n

Recognizes over 20 types of layout elements, including track changes, footnotes, endnotes, formulas, and merged cells<\/p>\n\n

\u2705 Single Pipeline Combining Document Layout Analysis (DLA) + OCR + Table Structure Recognition (TSR) <\/strong><\/p>\n\n

Processes Document Layout Analysis (DLA), OCR, and Table Structure Recognition (TSR) in a single pipeline<\/p>\n\n

Recognizes borderless tables, merged cells, and nested tables <\/p>\n\n

\u2705 Level Inference-based Hierarchical Structure Extraction<\/strong> <\/p>\n\n

Automatically determines paragraph hierarchies such as headings, subheadings, and body text to output as structured data<\/p>\n\n

Contributes to improving RAG search accuracy in the subsequent chunking stage <\/p>\n\n

\u2705 Support for Various Formats<\/strong> <\/p>\n\n

Supports input of various document formats including HWP, HWPX, PDF, and OOXML (PPTX, DOCX, XLSX)<\/p>\n\n

Can extract into structured data such as JSON and HTML depending on format characteristics <\/p>\n\n

\u2705 Complete On-premise Internalization<\/strong> <\/p>\n\n

Internal server installation based on Docker REST API<\/p>\n\n

Responds to network-isolated and air-gapped environments without external document transmission<\/p>\n\n

\u2705 Hancom Data Loader Holds GS Certification<\/strong> <\/p>\n\n

Credibility based on public procurement and major corporate supply references<\/p>\n\n

Experience Hancom Data Loader right now!<\/p>\n\n

\ud83d\udc49 View Hancom Data Loader API Guide<\/a><\/p>\n\n

\ud83d\udc49 Inquire About Hancom Data Loader<\/a><\/p>\n\n

\n\n

References<\/strong><\/p>\n\n

    \n
  1. arXiv<\/strong><\/a>, “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks,” Lewis, P. et al., 2020<\/li>\n\n\n\n
  2. AWS<\/strong><\/a>, “What is Retrieval-Augmented Generation (RAG)?”<\/li>\n\n\n\n
  3. IBM<\/strong><\/a>, “What is RAG, Retrieval-Augmented Generation?”<\/li>\n\n\n\n
  4. Microsoft Azure<\/strong><\/a>, “RAG Chunking Stage”<\/li>\n\n\n\n
  5. IBM<\/strong><\/a>, “Implementing RAG Chunking Strategies Using LangChain and watsonx.ai”<\/li>\n\n\n\n
  6. Microsoft Azure<\/strong><\/a>, “RAG Embedding Generation Stage”<\/li>\n\n\n\n
  7. arXiv<\/strong><\/a>, “SCAN: Semantic Document Layout Analysis for Textual and Visual RAG,” Ueda et al., EACL 2026<\/li>\n\n\n\n
  8. arXiv<\/strong><\/a>, “Document Parsing Unveiled: Techniques, Challenges, and Prospects,” Lin, 2024<\/li>\n\n\n\n
  9. arXiv<\/strong><\/a>, “A Systematic Analysis of Chunking Strategies for Reliable Question Answering,” Bennani & Moslonka, 2026<\/li>\n\n\n\n
  10. NVIDIA<\/strong><\/a>, “Finding the Best Chunking Strategy for Accurate AI Responses,” 2025<\/li>\n\n\n\n
  11. arXiv<\/strong><\/a>, “Revolutionizing RAG with Enhanced PDF Structure Recognition,” Lin, 2024<\/li>\n\n\n\n
  12. AWS Textract<\/strong><\/a>, “Supported Document Formats”<\/li>\n\n\n\n
  13. Microsoft Azure<\/strong><\/a>, “Azure Document Intelligence Overview”<\/li>\n\n\n\n
  14. Google<\/strong><\/a>, “Document AI Supported File Types”<\/li>\n\n\n\n
  15. Korea Economic Daily<\/strong><\/a>, “Hancom Launches ‘Hancom Data Loader’ Globally,” 2024.04<\/li>\n\n\n\n
  16. Money Today<\/strong><\/a>, “HWP: Not for Phasing Out, but for ‘AI Raw Materialization’,” 2026.04<\/li>\n<\/ol>\n\n

    <\/p>\n","protected":false},"excerpt":{"rendered":"

    This is a core guide for non-developers covering everything from RAG (Retrieval-Augmented Generation) concepts to pipeline structure, chunking, embedding, and vector DB storage. Learn how to utilize HWP and HWPX documents for RAG. <\/p>\n","protected":false},"author":2,"featured_media":788,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[29],"tags":[],"class_list":["post-787","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ax-glossary"],"_links":{"self":[{"href":"https:\/\/blog.hancom.com\/en\/wp-json\/wp\/v2\/posts\/787","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.hancom.com\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.hancom.com\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.hancom.com\/en\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.hancom.com\/en\/wp-json\/wp\/v2\/comments?post=787"}],"version-history":[{"count":10,"href":"https:\/\/blog.hancom.com\/en\/wp-json\/wp\/v2\/posts\/787\/revisions"}],"predecessor-version":[{"id":915,"href":"https:\/\/blog.hancom.com\/en\/wp-json\/wp\/v2\/posts\/787\/revisions\/915"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.hancom.com\/en\/wp-json\/wp\/v2\/media\/788"}],"wp:attachment":[{"href":"https:\/\/blog.hancom.com\/en\/wp-json\/wp\/v2\/media?parent=787"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.hancom.com\/en\/wp-json\/wp\/v2\/categories?post=787"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.hancom.com\/en\/wp-json\/wp\/v2\/tags?post=787"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}