What is a RAG system? The concept of retrieval-augmented generation and why it emerged <\/strong><\/h2>\n\n<\/div>\n\nRAG (retrieval-augmented generation) is a technique that searches external documents and uses them as evidence before an LLM answers, introduced to address the limits of training data and the hallucination problem.<\/p>\n\n
RAG concept and definition<\/strong><\/h3>\n\nRAG is a technique in which an LLM first retrieves relevant information from reliable external knowledge sources before generating an answer, then produces the answer grounded in that information. As the name suggests, it refers to a structure that combines three actions in order: Retrieval + Augmented + Generation. <\/p>\n\n
When documents run to thousands of pages, you can\u2019t feed them into an LLM all at once\u2014RAG retrieves only the necessary parts and provides them as evidence. The paper on general-purpose fine-tuning methods for RAG<\/a> also reports that combining an external retrieval index makes answers more specific and closer to factual.<\/p>\n\n<\/div>\n\n![\"Image](\"https:\/\/blog.hancom.com\/wp-content\/uploads\/2026\/08\/rag-system-build-concept-retrieval-augmented-generation-1024x576.png\")
<\/figure>\n\n<\/div>\n\nLimitations of using an LLM alone and the hallucination problem<\/strong><\/h3>\n\nBecause an LLM does not know information after its training point or domain knowledge it was never trained on, hallucinations can occur\u2014where it makes up unknown content as if it were fact.<\/p>\n\n
There are two causes: the knowledge cutoff, which prevents it from knowing information after training ends, and a lack of domain knowledge for internal policies or specialized documents it never learned. IBM<\/a> also explains that hallucinations are more likely when a model cannot learn new data. <\/p>\n\nWhy RAG is needed<\/strong><\/h3>\n\nBecause RAG retrieves external data and uses it as evidence for answers, it can reflect up-to-date information and reduce hallucinations without retraining the model.<\/p>\n\n
Fine-tuning requires retraining the model, but RAG can reflect the latest information by updating only the external index. It can also present the documents used for retrieval, making it easier to verify the basis for an answer. Reflecting current information without retraining costs\u2014and being able to check sources\u2014are key reasons teams choose RAG. <\/p>\n\n
<\/div>\n\nRAG system diagram: seven core components<\/strong><\/h2>\n\n<\/div>\n\nRAG system diagram: from document extraction to LLM answers<\/strong><\/h3>\n\nA RAG system works in the order: document extraction \u2192 parsing \u2192 chunking \u2192 embedding \u2192 vector DB storage \u2192 retrieval \u2192 LLM answer. Even though it looks like many steps, it becomes easier to understand when you group them into two parts. <\/p>\n\n
\n- Document extraction \u2013 pulls content from the original document<\/li>\n\n\n\n
- Parsing \u2013 extracts text and structural information<\/li>\n\n\n\n
- Chunking \u2013 splits the document into smaller units<\/li>\n\n\n\n
- Embedding \u2013 converts the split text into numeric vectors<\/li>\n\n\n\n
- Vector DB storage \u2013 loads the converted vectors into a retrieval store<\/li>\n\n\n\n
- Retrieval \u2013 finds the content most similar to the question<\/li>\n\n\n\n
- LLM answer \u2013 generates an answer grounded in the retrieved content<\/li>\n<\/ol>\n\n
The first five steps are the indexing process that prepares data in advance, while the last two steps (retrieval and LLM answering) run each time a question comes in.<\/p>\n\n
The AWS guide<\/a> also notes that embedding storage is a one-time step, while retrieval, augmentation, and generation repeat for every question. This distinction between one-time preparation and repeated execution becomes a key lens for understanding the implementation methods covered later. <\/p>\n\nDocument parsing: the first step in RAG and the baseline for quality<\/strong><\/h3>\n\nDocument parsing is the step that extracts text and structural information from original documents in formats such as HWP, HWPX, and PDF, and it determines the quality of subsequent chunking, embedding, and retrieval.<\/p>\n\n
If structural information is damaged at this stage, every subsequent step inherits data with that structure already lost. <\/strong>As described in Unstructured\u2019s open source<\/a>, the core of parsing is splitting a document into elements such as Title, NarrativeText, and Table\u2014but in the Korean environment, the difficulty rises further with HWP and HWPX, which are optimized for local use. Hancom Data Loader directly parses these HWP\/HWPX files from the original binary without converting them to PDF, preserving table structures, footnotes, and metadata. <\/p>\n\nThe roles of chunking and embeddings<\/strong><\/h3>\n\nChunking is the process of splitting a document into smaller units, and embedding is the process of converting those split texts into numeric vectors that capture meaning.<\/p>\n\n
If chunks are too large, different topics get mixed together and retrieval becomes inaccurate; if they\u2019re too small, context breaks and meaning becomes hard to interpret. Traditional approaches that cut text only by character count fail to reflect document structure such as titles and paragraphs. The study on RAG chunks and frameworks<\/a> points out that this approach cannot produce chunks with sufficient meaning. <\/p>\n\nVector databases and Top-K retrieval<\/strong><\/h3>\n\nA vector database is a retrieval-focused store that saves embedded vectors and quickly finds the vectors most similar to a user\u2019s question. Common vector databases include FAISS and Chroma. <\/p>\n\n
Top-K is the value that determines how many high-similarity items to return from retrieval results. If K is too large, low-relevance information may be pulled in; if it\u2019s too small, needed information can be missed\u2014so choosing an appropriate value matters. <\/p>\n\n
The LLM answer generation stage<\/strong><\/h3>\n\nThe LLM takes the retrieved document chunks as context and generates the final answer based on a prompt that combines them with the user\u2019s question.<\/p>\n\n
A prompt is the combination of retrieved document content and the user\u2019s question. Because the model answers based on retrieved evidence rather than its own memory, how accurately the earlier stages retrieve the right materials largely determines answer quality. <\/p>\n\n
<\/div>\n\n![\"Image](\"https:\/\/blog.hancom.com\/wp-content\/uploads\/2026\/08\/rag-system-build-search-flow-1024x576.png\")
<\/figure>\n\n<\/div>\n\nHow to build a RAG system: from preprocessing to answer generation<\/strong><\/h2>\n\n<\/div>\n\nBuilding a RAG system can be divided into a preprocessing domain that extracts and structures documents, and a retrieval\/generation domain that handles everything from chunking to answer generation\u2014then connecting the two domains with the right solutions.<\/p>\n\n
Building a RAG system: documents<\/strong><\/h3>\n\nThe RAG system build process is divided into a preprocessing domain that extracts and structures documents and a retrieval\/generation domain that handles everything from chunking to answer generation\u2014then connecting each domain with the right solutions.<\/p>\n\n
Step 1: Document structure analysis and RAG document preprocessing<\/strong><\/h4>\n\nIn the document preprocessing stage, you analyze the original document\u2019s layout, tables, and paragraph hierarchy and convert them into structured data. The quality of this output determines chunking accuracy later.<\/p>\n\n
The core of this process is DLA (Document Layout Analysis), which distinguishes text, images, tables, and graphics and identifies their positions and relationships. The results are organized into a standard structure, like the Document objects produced by LangChain<\/a>\u2019s DocumentLoader. However, because you must account for formats, table structures, and Korean-language document characteristics, teams often place a specialized preprocessing solution at the front to handle this stage. <\/p>\n\nStep 2: Chunking, embedding, and vector DB storage<\/strong><\/h4>\n\nPreprocessed data is chunked, vectorized via an embedding model, and stored in a vector database for later retrieval.<\/p>\n\n
This is the indexing stage that prepares retrieval data in advance before questions arrive, and RAG frameworks typically handle chunking, embedding, and vector database storage.<\/p>\n\n
Step 3: Retrieval and LLM answer generation<\/strong><\/h4>\n\nWhen a user question comes in, it is vectorized with the same embedding model, similarity search is performed, and the retrieved documents are passed to the LLM to generate the final answer.<\/p>\n\n
This RAG retrieval process converts the question into an embedding, extracts relevant chunks via similarity search in the vector DB, assembles them into a prompt, and has the LLM answer. The question must be vectorized in the same way as stored documents to correctly find semantically similar content. <\/p>\n\n
<\/div>\n\n![\"Image](\"https:\/\/blog.hancom.com\/wp-content\/uploads\/2026\/08\/rag-system-build-data-structuring-process-1024x576.png\")
<\/figure>\n\n<\/div>\n\nHow to implement RAG: LangChain vs. LlamaIndex<\/strong><\/h2>\n\n<\/div>\n\nRAG can be implemented with frameworks such as LangChain and LlamaIndex, and each framework differs in how it composes components from document loading through retrieval and generation.<\/p>\n\n
How to implement RAG with LangChain<\/strong><\/h3>\n\nLangChain<\/a> is a framework that builds a RAG pipeline by combining components such as DocumentLoader, Text Splitter, Retriever, and Chains.<\/p>\n\nThe implementation flow is: load documents with a DocumentLoader, split them with a Text Splitter, embed and store them in a vector store, retrieve results with a Retriever, connect them via a Chain, and call the LLM. Because it\u2019s a modular, component-assembly structure, it can flexibly support complex workflows. <\/p>\n\n
How to implement RAG with LlamaIndex<\/strong><\/h3>\n\nLlamaIndex<\/a> is a framework specialized in indexing diverse data sources, with strengths in connecting documents and building indexes.<\/p>\n\nThe core is a data connector that converts content from multiple sources into Document objects and builds them into an index. The official LlamaIndex documentation<\/a> describes this loading process as a flow of loading, transforming, indexing, and storing. Even within RAG, if LangChain emphasizes chain\/agent composition, LlamaIndex\u2019s strengths lie in data indexing and retrieval optimization. <\/p>\n\nCriteria for choosing RAG document preprocessing tools<\/strong><\/h3>\n\nThe right RAG document preprocessing tool depends on the document formats you need to handle and the complexity of their structure. Plain text and PDFs are often fine with basic document loaders, but complex tables or Korean domestic formats typically require separate preprocessing.<\/p>\n\n
LangChain and LlamaIndex document loaders handle pipeline wiring\u2014such as chunking, retrieval, and chain composition\u2014well, but because they\u2019re optimized mainly for PDFs and text, they may struggle to preserve structure for tables with merged cells or domestic formats like HWP and HWPX.<\/p>\n\n
According to reporting by AI Times<\/a>, Hancom Data Loader is a solution that extracts text and various objects from PDFs and Office documents and preprocesses them into data for AI training. It later expanded support to structured data extraction across HWP, HWPX, PDF, and OOXML overall, based on DLA and OCR (Optical Character Recognition) and TSR (Table Structure Recognition). <\/p>\n\n\ud83d\udca1 If table structures or HWP\/HWPX parsing are bottlenecks in your RAG pipeline, you can upload real documents in the Hancom Data Loader live demo and check the extraction results directly.<\/p>\n\n
\ud83d\udc49 Go to Hancom Data Loader Live Demo<\/a><\/p>\n\nLangChain vs. LlamaIndex: what\u2019s different?<\/strong><\/h3>\n\nLangChain is strong at composing diverse LLM chains and agents, while LlamaIndex excels at indexing large document sets and optimizing retrieval\u2014so the right choice depends on your project goals.<\/p>\n\n
IBM<\/a> distinguishes LangChain as an orchestration framework for LLM applications and LlamaIndex as a data orchestration framework.<\/p>\n\nComparison of strengths and best-fit use cases for LangChain and LlamaIndex<\/strong><\/h4>\n\n
RAG (retrieval-augmented generation) is a technique that searches external documents and uses them as evidence before an LLM answers, introduced to address the limits of training data and the hallucination problem.<\/p>\n\n
RAG concept and definition<\/strong><\/h3>\n\nRAG is a technique in which an LLM first retrieves relevant information from reliable external knowledge sources before generating an answer, then produces the answer grounded in that information. As the name suggests, it refers to a structure that combines three actions in order: Retrieval + Augmented + Generation. <\/p>\n\n
When documents run to thousands of pages, you can\u2019t feed them into an LLM all at once\u2014RAG retrieves only the necessary parts and provides them as evidence. The paper on general-purpose fine-tuning methods for RAG<\/a> also reports that combining an external retrieval index makes answers more specific and closer to factual.<\/p>\n\n<\/div>\n\n<\/figure>\n\n<\/div>\n\nLimitations of using an LLM alone and the hallucination problem<\/strong><\/h3>\n\nBecause an LLM does not know information after its training point or domain knowledge it was never trained on, hallucinations can occur\u2014where it makes up unknown content as if it were fact.<\/p>\n\n
There are two causes: the knowledge cutoff, which prevents it from knowing information after training ends, and a lack of domain knowledge for internal policies or specialized documents it never learned. IBM<\/a> also explains that hallucinations are more likely when a model cannot learn new data. <\/p>\n\nWhy RAG is needed<\/strong><\/h3>\n\nBecause RAG retrieves external data and uses it as evidence for answers, it can reflect up-to-date information and reduce hallucinations without retraining the model.<\/p>\n\n
Fine-tuning requires retraining the model, but RAG can reflect the latest information by updating only the external index. It can also present the documents used for retrieval, making it easier to verify the basis for an answer. Reflecting current information without retraining costs\u2014and being able to check sources\u2014are key reasons teams choose RAG. <\/p>\n\n
<\/div>\n\nRAG system diagram: seven core components<\/strong><\/h2>\n\n<\/div>\n\nRAG system diagram: from document extraction to LLM answers<\/strong><\/h3>\n\nA RAG system works in the order: document extraction \u2192 parsing \u2192 chunking \u2192 embedding \u2192 vector DB storage \u2192 retrieval \u2192 LLM answer. Even though it looks like many steps, it becomes easier to understand when you group them into two parts. <\/p>\n\n
\n- Document extraction \u2013 pulls content from the original document<\/li>\n\n\n\n
- Parsing \u2013 extracts text and structural information<\/li>\n\n\n\n
- Chunking \u2013 splits the document into smaller units<\/li>\n\n\n\n
- Embedding \u2013 converts the split text into numeric vectors<\/li>\n\n\n\n
- Vector DB storage \u2013 loads the converted vectors into a retrieval store<\/li>\n\n\n\n
- Retrieval \u2013 finds the content most similar to the question<\/li>\n\n\n\n
- LLM answer \u2013 generates an answer grounded in the retrieved content<\/li>\n<\/ol>\n\n
The first five steps are the indexing process that prepares data in advance, while the last two steps (retrieval and LLM answering) run each time a question comes in.<\/p>\n\n
The AWS guide<\/a> also notes that embedding storage is a one-time step, while retrieval, augmentation, and generation repeat for every question. This distinction between one-time preparation and repeated execution becomes a key lens for understanding the implementation methods covered later. <\/p>\n\nDocument parsing: the first step in RAG and the baseline for quality<\/strong><\/h3>\n\nDocument parsing is the step that extracts text and structural information from original documents in formats such as HWP, HWPX, and PDF, and it determines the quality of subsequent chunking, embedding, and retrieval.<\/p>\n\n
If structural information is damaged at this stage, every subsequent step inherits data with that structure already lost. <\/strong>As described in Unstructured\u2019s open source<\/a>, the core of parsing is splitting a document into elements such as Title, NarrativeText, and Table\u2014but in the Korean environment, the difficulty rises further with HWP and HWPX, which are optimized for local use. Hancom Data Loader directly parses these HWP\/HWPX files from the original binary without converting them to PDF, preserving table structures, footnotes, and metadata. <\/p>\n\nThe roles of chunking and embeddings<\/strong><\/h3>\n\nChunking is the process of splitting a document into smaller units, and embedding is the process of converting those split texts into numeric vectors that capture meaning.<\/p>\n\n
If chunks are too large, different topics get mixed together and retrieval becomes inaccurate; if they\u2019re too small, context breaks and meaning becomes hard to interpret. Traditional approaches that cut text only by character count fail to reflect document structure such as titles and paragraphs. The study on RAG chunks and frameworks<\/a> points out that this approach cannot produce chunks with sufficient meaning. <\/p>\n\nVector databases and Top-K retrieval<\/strong><\/h3>\n\nA vector database is a retrieval-focused store that saves embedded vectors and quickly finds the vectors most similar to a user\u2019s question. Common vector databases include FAISS and Chroma. <\/p>\n\n
Top-K is the value that determines how many high-similarity items to return from retrieval results. If K is too large, low-relevance information may be pulled in; if it\u2019s too small, needed information can be missed\u2014so choosing an appropriate value matters. <\/p>\n\n
The LLM answer generation stage<\/strong><\/h3>\n\nThe LLM takes the retrieved document chunks as context and generates the final answer based on a prompt that combines them with the user\u2019s question.<\/p>\n\n
A prompt is the combination of retrieved document content and the user\u2019s question. Because the model answers based on retrieved evidence rather than its own memory, how accurately the earlier stages retrieve the right materials largely determines answer quality. <\/p>\n\n
<\/div>\n\n<\/figure>\n\n<\/div>\n\nHow to build a RAG system: from preprocessing to answer generation<\/strong><\/h2>\n\n<\/div>\n\nBuilding a RAG system can be divided into a preprocessing domain that extracts and structures documents, and a retrieval\/generation domain that handles everything from chunking to answer generation\u2014then connecting the two domains with the right solutions.<\/p>\n\n
Building a RAG system: documents<\/strong><\/h3>\n\nThe RAG system build process is divided into a preprocessing domain that extracts and structures documents and a retrieval\/generation domain that handles everything from chunking to answer generation\u2014then connecting each domain with the right solutions.<\/p>\n\n
Step 1: Document structure analysis and RAG document preprocessing<\/strong><\/h4>\n\nIn the document preprocessing stage, you analyze the original document\u2019s layout, tables, and paragraph hierarchy and convert them into structured data. The quality of this output determines chunking accuracy later.<\/p>\n\n
The core of this process is DLA (Document Layout Analysis), which distinguishes text, images, tables, and graphics and identifies their positions and relationships. The results are organized into a standard structure, like the Document objects produced by LangChain<\/a>\u2019s DocumentLoader. However, because you must account for formats, table structures, and Korean-language document characteristics, teams often place a specialized preprocessing solution at the front to handle this stage. <\/p>\n\nStep 2: Chunking, embedding, and vector DB storage<\/strong><\/h4>\n\nPreprocessed data is chunked, vectorized via an embedding model, and stored in a vector database for later retrieval.<\/p>\n\n
This is the indexing stage that prepares retrieval data in advance before questions arrive, and RAG frameworks typically handle chunking, embedding, and vector database storage.<\/p>\n\n
Step 3: Retrieval and LLM answer generation<\/strong><\/h4>\n\nWhen a user question comes in, it is vectorized with the same embedding model, similarity search is performed, and the retrieved documents are passed to the LLM to generate the final answer.<\/p>\n\n
This RAG retrieval process converts the question into an embedding, extracts relevant chunks via similarity search in the vector DB, assembles them into a prompt, and has the LLM answer. The question must be vectorized in the same way as stored documents to correctly find semantically similar content. <\/p>\n\n
<\/div>\n\n<\/figure>\n\n<\/div>\n\nHow to implement RAG: LangChain vs. LlamaIndex<\/strong><\/h2>\n\n<\/div>\n\nRAG can be implemented with frameworks such as LangChain and LlamaIndex, and each framework differs in how it composes components from document loading through retrieval and generation.<\/p>\n\n
How to implement RAG with LangChain<\/strong><\/h3>\n\nLangChain<\/a> is a framework that builds a RAG pipeline by combining components such as DocumentLoader, Text Splitter, Retriever, and Chains.<\/p>\n\nThe implementation flow is: load documents with a DocumentLoader, split them with a Text Splitter, embed and store them in a vector store, retrieve results with a Retriever, connect them via a Chain, and call the LLM. Because it\u2019s a modular, component-assembly structure, it can flexibly support complex workflows. <\/p>\n\n
How to implement RAG with LlamaIndex<\/strong><\/h3>\n\nLlamaIndex<\/a> is a framework specialized in indexing diverse data sources, with strengths in connecting documents and building indexes.<\/p>\n\nThe core is a data connector that converts content from multiple sources into Document objects and builds them into an index. The official LlamaIndex documentation<\/a> describes this loading process as a flow of loading, transforming, indexing, and storing. Even within RAG, if LangChain emphasizes chain\/agent composition, LlamaIndex\u2019s strengths lie in data indexing and retrieval optimization. <\/p>\n\nCriteria for choosing RAG document preprocessing tools<\/strong><\/h3>\n\nThe right RAG document preprocessing tool depends on the document formats you need to handle and the complexity of their structure. Plain text and PDFs are often fine with basic document loaders, but complex tables or Korean domestic formats typically require separate preprocessing.<\/p>\n\n
LangChain and LlamaIndex document loaders handle pipeline wiring\u2014such as chunking, retrieval, and chain composition\u2014well, but because they\u2019re optimized mainly for PDFs and text, they may struggle to preserve structure for tables with merged cells or domestic formats like HWP and HWPX.<\/p>\n\n
According to reporting by AI Times<\/a>, Hancom Data Loader is a solution that extracts text and various objects from PDFs and Office documents and preprocesses them into data for AI training. It later expanded support to structured data extraction across HWP, HWPX, PDF, and OOXML overall, based on DLA and OCR (Optical Character Recognition) and TSR (Table Structure Recognition). <\/p>\n\n\ud83d\udca1 If table structures or HWP\/HWPX parsing are bottlenecks in your RAG pipeline, you can upload real documents in the Hancom Data Loader live demo and check the extraction results directly.<\/p>\n\n
\ud83d\udc49 Go to Hancom Data Loader Live Demo<\/a><\/p>\n\nLangChain vs. LlamaIndex: what\u2019s different?<\/strong><\/h3>\n\nLangChain is strong at composing diverse LLM chains and agents, while LlamaIndex excels at indexing large document sets and optimizing retrieval\u2014so the right choice depends on your project goals.<\/p>\n\n
IBM<\/a> distinguishes LangChain as an orchestration framework for LLM applications and LlamaIndex as a data orchestration framework.<\/p>\n\nComparison of strengths and best-fit use cases for LangChain and LlamaIndex<\/strong><\/h4>\n\n
<\/figure>\n\nLimitations of using an LLM alone and the hallucination problem<\/strong><\/h3>\n\nBecause an LLM does not know information after its training point or domain knowledge it was never trained on, hallucinations can occur\u2014where it makes up unknown content as if it were fact.<\/p>\n\n
There are two causes: the knowledge cutoff, which prevents it from knowing information after training ends, and a lack of domain knowledge for internal policies or specialized documents it never learned. IBM<\/a> also explains that hallucinations are more likely when a model cannot learn new data. <\/p>\n\nWhy RAG is needed<\/strong><\/h3>\n\nBecause RAG retrieves external data and uses it as evidence for answers, it can reflect up-to-date information and reduce hallucinations without retraining the model.<\/p>\n\n
Fine-tuning requires retraining the model, but RAG can reflect the latest information by updating only the external index. It can also present the documents used for retrieval, making it easier to verify the basis for an answer. Reflecting current information without retraining costs\u2014and being able to check sources\u2014are key reasons teams choose RAG. <\/p>\n\n
<\/div>\n\nRAG system diagram: seven core components<\/strong><\/h2>\n\n<\/div>\n\nRAG system diagram: from document extraction to LLM answers<\/strong><\/h3>\n\nA RAG system works in the order: document extraction \u2192 parsing \u2192 chunking \u2192 embedding \u2192 vector DB storage \u2192 retrieval \u2192 LLM answer. Even though it looks like many steps, it becomes easier to understand when you group them into two parts. <\/p>\n\n
\n- Document extraction \u2013 pulls content from the original document<\/li>\n\n\n\n
- Parsing \u2013 extracts text and structural information<\/li>\n\n\n\n
- Chunking \u2013 splits the document into smaller units<\/li>\n\n\n\n
- Embedding \u2013 converts the split text into numeric vectors<\/li>\n\n\n\n
- Vector DB storage \u2013 loads the converted vectors into a retrieval store<\/li>\n\n\n\n
- Retrieval \u2013 finds the content most similar to the question<\/li>\n\n\n\n
- LLM answer \u2013 generates an answer grounded in the retrieved content<\/li>\n<\/ol>\n\n
The first five steps are the indexing process that prepares data in advance, while the last two steps (retrieval and LLM answering) run each time a question comes in.<\/p>\n\n
The AWS guide<\/a> also notes that embedding storage is a one-time step, while retrieval, augmentation, and generation repeat for every question. This distinction between one-time preparation and repeated execution becomes a key lens for understanding the implementation methods covered later. <\/p>\n\nDocument parsing: the first step in RAG and the baseline for quality<\/strong><\/h3>\n\nDocument parsing is the step that extracts text and structural information from original documents in formats such as HWP, HWPX, and PDF, and it determines the quality of subsequent chunking, embedding, and retrieval.<\/p>\n\n
If structural information is damaged at this stage, every subsequent step inherits data with that structure already lost. <\/strong>As described in Unstructured\u2019s open source<\/a>, the core of parsing is splitting a document into elements such as Title, NarrativeText, and Table\u2014but in the Korean environment, the difficulty rises further with HWP and HWPX, which are optimized for local use. Hancom Data Loader directly parses these HWP\/HWPX files from the original binary without converting them to PDF, preserving table structures, footnotes, and metadata. <\/p>\n\nThe roles of chunking and embeddings<\/strong><\/h3>\n\nChunking is the process of splitting a document into smaller units, and embedding is the process of converting those split texts into numeric vectors that capture meaning.<\/p>\n\n
If chunks are too large, different topics get mixed together and retrieval becomes inaccurate; if they\u2019re too small, context breaks and meaning becomes hard to interpret. Traditional approaches that cut text only by character count fail to reflect document structure such as titles and paragraphs. The study on RAG chunks and frameworks<\/a> points out that this approach cannot produce chunks with sufficient meaning. <\/p>\n\nVector databases and Top-K retrieval<\/strong><\/h3>\n\nA vector database is a retrieval-focused store that saves embedded vectors and quickly finds the vectors most similar to a user\u2019s question. Common vector databases include FAISS and Chroma. <\/p>\n\n
Top-K is the value that determines how many high-similarity items to return from retrieval results. If K is too large, low-relevance information may be pulled in; if it\u2019s too small, needed information can be missed\u2014so choosing an appropriate value matters. <\/p>\n\n
The LLM answer generation stage<\/strong><\/h3>\n\nThe LLM takes the retrieved document chunks as context and generates the final answer based on a prompt that combines them with the user\u2019s question.<\/p>\n\n
A prompt is the combination of retrieved document content and the user\u2019s question. Because the model answers based on retrieved evidence rather than its own memory, how accurately the earlier stages retrieve the right materials largely determines answer quality. <\/p>\n\n
<\/div>\n\n<\/figure>\n\n<\/div>\n\nHow to build a RAG system: from preprocessing to answer generation<\/strong><\/h2>\n\n<\/div>\n\nBuilding a RAG system can be divided into a preprocessing domain that extracts and structures documents, and a retrieval\/generation domain that handles everything from chunking to answer generation\u2014then connecting the two domains with the right solutions.<\/p>\n\n
Building a RAG system: documents<\/strong><\/h3>\n\nThe RAG system build process is divided into a preprocessing domain that extracts and structures documents and a retrieval\/generation domain that handles everything from chunking to answer generation\u2014then connecting each domain with the right solutions.<\/p>\n\n
Step 1: Document structure analysis and RAG document preprocessing<\/strong><\/h4>\n\nIn the document preprocessing stage, you analyze the original document\u2019s layout, tables, and paragraph hierarchy and convert them into structured data. The quality of this output determines chunking accuracy later.<\/p>\n\n
The core of this process is DLA (Document Layout Analysis), which distinguishes text, images, tables, and graphics and identifies their positions and relationships. The results are organized into a standard structure, like the Document objects produced by LangChain<\/a>\u2019s DocumentLoader. However, because you must account for formats, table structures, and Korean-language document characteristics, teams often place a specialized preprocessing solution at the front to handle this stage. <\/p>\n\nStep 2: Chunking, embedding, and vector DB storage<\/strong><\/h4>\n\nPreprocessed data is chunked, vectorized via an embedding model, and stored in a vector database for later retrieval.<\/p>\n\n
This is the indexing stage that prepares retrieval data in advance before questions arrive, and RAG frameworks typically handle chunking, embedding, and vector database storage.<\/p>\n\n
Step 3: Retrieval and LLM answer generation<\/strong><\/h4>\n\nWhen a user question comes in, it is vectorized with the same embedding model, similarity search is performed, and the retrieved documents are passed to the LLM to generate the final answer.<\/p>\n\n
This RAG retrieval process converts the question into an embedding, extracts relevant chunks via similarity search in the vector DB, assembles them into a prompt, and has the LLM answer. The question must be vectorized in the same way as stored documents to correctly find semantically similar content. <\/p>\n\n
<\/div>\n\n<\/figure>\n\n<\/div>\n\nHow to implement RAG: LangChain vs. LlamaIndex<\/strong><\/h2>\n\n<\/div>\n\nRAG can be implemented with frameworks such as LangChain and LlamaIndex, and each framework differs in how it composes components from document loading through retrieval and generation.<\/p>\n\n
How to implement RAG with LangChain<\/strong><\/h3>\n\nLangChain<\/a> is a framework that builds a RAG pipeline by combining components such as DocumentLoader, Text Splitter, Retriever, and Chains.<\/p>\n\nThe implementation flow is: load documents with a DocumentLoader, split them with a Text Splitter, embed and store them in a vector store, retrieve results with a Retriever, connect them via a Chain, and call the LLM. Because it\u2019s a modular, component-assembly structure, it can flexibly support complex workflows. <\/p>\n\n
How to implement RAG with LlamaIndex<\/strong><\/h3>\n\nLlamaIndex<\/a> is a framework specialized in indexing diverse data sources, with strengths in connecting documents and building indexes.<\/p>\n\nThe core is a data connector that converts content from multiple sources into Document objects and builds them into an index. The official LlamaIndex documentation<\/a> describes this loading process as a flow of loading, transforming, indexing, and storing. Even within RAG, if LangChain emphasizes chain\/agent composition, LlamaIndex\u2019s strengths lie in data indexing and retrieval optimization. <\/p>\n\nCriteria for choosing RAG document preprocessing tools<\/strong><\/h3>\n\nThe right RAG document preprocessing tool depends on the document formats you need to handle and the complexity of their structure. Plain text and PDFs are often fine with basic document loaders, but complex tables or Korean domestic formats typically require separate preprocessing.<\/p>\n\n
LangChain and LlamaIndex document loaders handle pipeline wiring\u2014such as chunking, retrieval, and chain composition\u2014well, but because they\u2019re optimized mainly for PDFs and text, they may struggle to preserve structure for tables with merged cells or domestic formats like HWP and HWPX.<\/p>\n\n
According to reporting by AI Times<\/a>, Hancom Data Loader is a solution that extracts text and various objects from PDFs and Office documents and preprocesses them into data for AI training. It later expanded support to structured data extraction across HWP, HWPX, PDF, and OOXML overall, based on DLA and OCR (Optical Character Recognition) and TSR (Table Structure Recognition). <\/p>\n\n\ud83d\udca1 If table structures or HWP\/HWPX parsing are bottlenecks in your RAG pipeline, you can upload real documents in the Hancom Data Loader live demo and check the extraction results directly.<\/p>\n\n
\ud83d\udc49 Go to Hancom Data Loader Live Demo<\/a><\/p>\n\nLangChain vs. LlamaIndex: what\u2019s different?<\/strong><\/h3>\n\nLangChain is strong at composing diverse LLM chains and agents, while LlamaIndex excels at indexing large document sets and optimizing retrieval\u2014so the right choice depends on your project goals.<\/p>\n\n
IBM<\/a> distinguishes LangChain as an orchestration framework for LLM applications and LlamaIndex as a data orchestration framework.<\/p>\n\nComparison of strengths and best-fit use cases for LangChain and LlamaIndex<\/strong><\/h4>\n\n
Why RAG is needed<\/strong><\/h3>\n\nBecause RAG retrieves external data and uses it as evidence for answers, it can reflect up-to-date information and reduce hallucinations without retraining the model.<\/p>\n\n
Fine-tuning requires retraining the model, but RAG can reflect the latest information by updating only the external index. It can also present the documents used for retrieval, making it easier to verify the basis for an answer. Reflecting current information without retraining costs\u2014and being able to check sources\u2014are key reasons teams choose RAG. <\/p>\n\n
<\/div>\n\nRAG system diagram: seven core components<\/strong><\/h2>\n\n<\/div>\n\nRAG system diagram: from document extraction to LLM answers<\/strong><\/h3>\n\nA RAG system works in the order: document extraction \u2192 parsing \u2192 chunking \u2192 embedding \u2192 vector DB storage \u2192 retrieval \u2192 LLM answer. Even though it looks like many steps, it becomes easier to understand when you group them into two parts. <\/p>\n\n
\n- Document extraction \u2013 pulls content from the original document<\/li>\n\n\n\n
- Parsing \u2013 extracts text and structural information<\/li>\n\n\n\n
- Chunking \u2013 splits the document into smaller units<\/li>\n\n\n\n
- Embedding \u2013 converts the split text into numeric vectors<\/li>\n\n\n\n
- Vector DB storage \u2013 loads the converted vectors into a retrieval store<\/li>\n\n\n\n
- Retrieval \u2013 finds the content most similar to the question<\/li>\n\n\n\n
- LLM answer \u2013 generates an answer grounded in the retrieved content<\/li>\n<\/ol>\n\n
The first five steps are the indexing process that prepares data in advance, while the last two steps (retrieval and LLM answering) run each time a question comes in.<\/p>\n\n
The AWS guide<\/a> also notes that embedding storage is a one-time step, while retrieval, augmentation, and generation repeat for every question. This distinction between one-time preparation and repeated execution becomes a key lens for understanding the implementation methods covered later. <\/p>\n\nDocument parsing: the first step in RAG and the baseline for quality<\/strong><\/h3>\n\nDocument parsing is the step that extracts text and structural information from original documents in formats such as HWP, HWPX, and PDF, and it determines the quality of subsequent chunking, embedding, and retrieval.<\/p>\n\n
If structural information is damaged at this stage, every subsequent step inherits data with that structure already lost. <\/strong>As described in Unstructured\u2019s open source<\/a>, the core of parsing is splitting a document into elements such as Title, NarrativeText, and Table\u2014but in the Korean environment, the difficulty rises further with HWP and HWPX, which are optimized for local use. Hancom Data Loader directly parses these HWP\/HWPX files from the original binary without converting them to PDF, preserving table structures, footnotes, and metadata. <\/p>\n\nThe roles of chunking and embeddings<\/strong><\/h3>\n\nChunking is the process of splitting a document into smaller units, and embedding is the process of converting those split texts into numeric vectors that capture meaning.<\/p>\n\n
If chunks are too large, different topics get mixed together and retrieval becomes inaccurate; if they\u2019re too small, context breaks and meaning becomes hard to interpret. Traditional approaches that cut text only by character count fail to reflect document structure such as titles and paragraphs. The study on RAG chunks and frameworks<\/a> points out that this approach cannot produce chunks with sufficient meaning. <\/p>\n\nVector databases and Top-K retrieval<\/strong><\/h3>\n\nA vector database is a retrieval-focused store that saves embedded vectors and quickly finds the vectors most similar to a user\u2019s question. Common vector databases include FAISS and Chroma. <\/p>\n\n
Top-K is the value that determines how many high-similarity items to return from retrieval results. If K is too large, low-relevance information may be pulled in; if it\u2019s too small, needed information can be missed\u2014so choosing an appropriate value matters. <\/p>\n\n
The LLM answer generation stage<\/strong><\/h3>\n\nThe LLM takes the retrieved document chunks as context and generates the final answer based on a prompt that combines them with the user\u2019s question.<\/p>\n\n
A prompt is the combination of retrieved document content and the user\u2019s question. Because the model answers based on retrieved evidence rather than its own memory, how accurately the earlier stages retrieve the right materials largely determines answer quality. <\/p>\n\n
<\/div>\n\n<\/figure>\n\n<\/div>\n\nHow to build a RAG system: from preprocessing to answer generation<\/strong><\/h2>\n\n<\/div>\n\nBuilding a RAG system can be divided into a preprocessing domain that extracts and structures documents, and a retrieval\/generation domain that handles everything from chunking to answer generation\u2014then connecting the two domains with the right solutions.<\/p>\n\n
Building a RAG system: documents<\/strong><\/h3>\n\nThe RAG system build process is divided into a preprocessing domain that extracts and structures documents and a retrieval\/generation domain that handles everything from chunking to answer generation\u2014then connecting each domain with the right solutions.<\/p>\n\n
Step 1: Document structure analysis and RAG document preprocessing<\/strong><\/h4>\n\nIn the document preprocessing stage, you analyze the original document\u2019s layout, tables, and paragraph hierarchy and convert them into structured data. The quality of this output determines chunking accuracy later.<\/p>\n\n
The core of this process is DLA (Document Layout Analysis), which distinguishes text, images, tables, and graphics and identifies their positions and relationships. The results are organized into a standard structure, like the Document objects produced by LangChain<\/a>\u2019s DocumentLoader. However, because you must account for formats, table structures, and Korean-language document characteristics, teams often place a specialized preprocessing solution at the front to handle this stage. <\/p>\n\nStep 2: Chunking, embedding, and vector DB storage<\/strong><\/h4>\n\nPreprocessed data is chunked, vectorized via an embedding model, and stored in a vector database for later retrieval.<\/p>\n\n
This is the indexing stage that prepares retrieval data in advance before questions arrive, and RAG frameworks typically handle chunking, embedding, and vector database storage.<\/p>\n\n
Step 3: Retrieval and LLM answer generation<\/strong><\/h4>\n\nWhen a user question comes in, it is vectorized with the same embedding model, similarity search is performed, and the retrieved documents are passed to the LLM to generate the final answer.<\/p>\n\n
This RAG retrieval process converts the question into an embedding, extracts relevant chunks via similarity search in the vector DB, assembles them into a prompt, and has the LLM answer. The question must be vectorized in the same way as stored documents to correctly find semantically similar content. <\/p>\n\n
<\/div>\n\n<\/figure>\n\n<\/div>\n\nHow to implement RAG: LangChain vs. LlamaIndex<\/strong><\/h2>\n\n<\/div>\n\nRAG can be implemented with frameworks such as LangChain and LlamaIndex, and each framework differs in how it composes components from document loading through retrieval and generation.<\/p>\n\n
How to implement RAG with LangChain<\/strong><\/h3>\n\nLangChain<\/a> is a framework that builds a RAG pipeline by combining components such as DocumentLoader, Text Splitter, Retriever, and Chains.<\/p>\n\nThe implementation flow is: load documents with a DocumentLoader, split them with a Text Splitter, embed and store them in a vector store, retrieve results with a Retriever, connect them via a Chain, and call the LLM. Because it\u2019s a modular, component-assembly structure, it can flexibly support complex workflows. <\/p>\n\n
How to implement RAG with LlamaIndex<\/strong><\/h3>\n\nLlamaIndex<\/a> is a framework specialized in indexing diverse data sources, with strengths in connecting documents and building indexes.<\/p>\n\nThe core is a data connector that converts content from multiple sources into Document objects and builds them into an index. The official LlamaIndex documentation<\/a> describes this loading process as a flow of loading, transforming, indexing, and storing. Even within RAG, if LangChain emphasizes chain\/agent composition, LlamaIndex\u2019s strengths lie in data indexing and retrieval optimization. <\/p>\n\nCriteria for choosing RAG document preprocessing tools<\/strong><\/h3>\n\nThe right RAG document preprocessing tool depends on the document formats you need to handle and the complexity of their structure. Plain text and PDFs are often fine with basic document loaders, but complex tables or Korean domestic formats typically require separate preprocessing.<\/p>\n\n
LangChain and LlamaIndex document loaders handle pipeline wiring\u2014such as chunking, retrieval, and chain composition\u2014well, but because they\u2019re optimized mainly for PDFs and text, they may struggle to preserve structure for tables with merged cells or domestic formats like HWP and HWPX.<\/p>\n\n
According to reporting by AI Times<\/a>, Hancom Data Loader is a solution that extracts text and various objects from PDFs and Office documents and preprocesses them into data for AI training. It later expanded support to structured data extraction across HWP, HWPX, PDF, and OOXML overall, based on DLA and OCR (Optical Character Recognition) and TSR (Table Structure Recognition). <\/p>\n\n\ud83d\udca1 If table structures or HWP\/HWPX parsing are bottlenecks in your RAG pipeline, you can upload real documents in the Hancom Data Loader live demo and check the extraction results directly.<\/p>\n\n
\ud83d\udc49 Go to Hancom Data Loader Live Demo<\/a><\/p>\n\nLangChain vs. LlamaIndex: what\u2019s different?<\/strong><\/h3>\n\nLangChain is strong at composing diverse LLM chains and agents, while LlamaIndex excels at indexing large document sets and optimizing retrieval\u2014so the right choice depends on your project goals.<\/p>\n\n
IBM<\/a> distinguishes LangChain as an orchestration framework for LLM applications and LlamaIndex as a data orchestration framework.<\/p>\n\nComparison of strengths and best-fit use cases for LangChain and LlamaIndex<\/strong><\/h4>\n\n
RAG system diagram: seven core components<\/strong><\/h2>\n\n<\/div>\n\nRAG system diagram: from document extraction to LLM answers<\/strong><\/h3>\n\nA RAG system works in the order: document extraction \u2192 parsing \u2192 chunking \u2192 embedding \u2192 vector DB storage \u2192 retrieval \u2192 LLM answer. Even though it looks like many steps, it becomes easier to understand when you group them into two parts. <\/p>\n\n
\n- Document extraction \u2013 pulls content from the original document<\/li>\n\n\n\n
- Parsing \u2013 extracts text and structural information<\/li>\n\n\n\n
- Chunking \u2013 splits the document into smaller units<\/li>\n\n\n\n
- Embedding \u2013 converts the split text into numeric vectors<\/li>\n\n\n\n
- Vector DB storage \u2013 loads the converted vectors into a retrieval store<\/li>\n\n\n\n
- Retrieval \u2013 finds the content most similar to the question<\/li>\n\n\n\n
- LLM answer \u2013 generates an answer grounded in the retrieved content<\/li>\n<\/ol>\n\n
The first five steps are the indexing process that prepares data in advance, while the last two steps (retrieval and LLM answering) run each time a question comes in.<\/p>\n\n
The AWS guide<\/a> also notes that embedding storage is a one-time step, while retrieval, augmentation, and generation repeat for every question. This distinction between one-time preparation and repeated execution becomes a key lens for understanding the implementation methods covered later. <\/p>\n\nDocument parsing: the first step in RAG and the baseline for quality<\/strong><\/h3>\n\nDocument parsing is the step that extracts text and structural information from original documents in formats such as HWP, HWPX, and PDF, and it determines the quality of subsequent chunking, embedding, and retrieval.<\/p>\n\n
If structural information is damaged at this stage, every subsequent step inherits data with that structure already lost. <\/strong>As described in Unstructured\u2019s open source<\/a>, the core of parsing is splitting a document into elements such as Title, NarrativeText, and Table\u2014but in the Korean environment, the difficulty rises further with HWP and HWPX, which are optimized for local use. Hancom Data Loader directly parses these HWP\/HWPX files from the original binary without converting them to PDF, preserving table structures, footnotes, and metadata. <\/p>\n\nThe roles of chunking and embeddings<\/strong><\/h3>\n\nChunking is the process of splitting a document into smaller units, and embedding is the process of converting those split texts into numeric vectors that capture meaning.<\/p>\n\n
If chunks are too large, different topics get mixed together and retrieval becomes inaccurate; if they\u2019re too small, context breaks and meaning becomes hard to interpret. Traditional approaches that cut text only by character count fail to reflect document structure such as titles and paragraphs. The study on RAG chunks and frameworks<\/a> points out that this approach cannot produce chunks with sufficient meaning. <\/p>\n\nVector databases and Top-K retrieval<\/strong><\/h3>\n\nA vector database is a retrieval-focused store that saves embedded vectors and quickly finds the vectors most similar to a user\u2019s question. Common vector databases include FAISS and Chroma. <\/p>\n\n
Top-K is the value that determines how many high-similarity items to return from retrieval results. If K is too large, low-relevance information may be pulled in; if it\u2019s too small, needed information can be missed\u2014so choosing an appropriate value matters. <\/p>\n\n
The LLM answer generation stage<\/strong><\/h3>\n\nThe LLM takes the retrieved document chunks as context and generates the final answer based on a prompt that combines them with the user\u2019s question.<\/p>\n\n
A prompt is the combination of retrieved document content and the user\u2019s question. Because the model answers based on retrieved evidence rather than its own memory, how accurately the earlier stages retrieve the right materials largely determines answer quality. <\/p>\n\n
<\/div>\n\n<\/figure>\n\n<\/div>\n\nHow to build a RAG system: from preprocessing to answer generation<\/strong><\/h2>\n\n<\/div>\n\nBuilding a RAG system can be divided into a preprocessing domain that extracts and structures documents, and a retrieval\/generation domain that handles everything from chunking to answer generation\u2014then connecting the two domains with the right solutions.<\/p>\n\n
Building a RAG system: documents<\/strong><\/h3>\n\nThe RAG system build process is divided into a preprocessing domain that extracts and structures documents and a retrieval\/generation domain that handles everything from chunking to answer generation\u2014then connecting each domain with the right solutions.<\/p>\n\n
Step 1: Document structure analysis and RAG document preprocessing<\/strong><\/h4>\n\nIn the document preprocessing stage, you analyze the original document\u2019s layout, tables, and paragraph hierarchy and convert them into structured data. The quality of this output determines chunking accuracy later.<\/p>\n\n
The core of this process is DLA (Document Layout Analysis), which distinguishes text, images, tables, and graphics and identifies their positions and relationships. The results are organized into a standard structure, like the Document objects produced by LangChain<\/a>\u2019s DocumentLoader. However, because you must account for formats, table structures, and Korean-language document characteristics, teams often place a specialized preprocessing solution at the front to handle this stage. <\/p>\n\nStep 2: Chunking, embedding, and vector DB storage<\/strong><\/h4>\n\nPreprocessed data is chunked, vectorized via an embedding model, and stored in a vector database for later retrieval.<\/p>\n\n
This is the indexing stage that prepares retrieval data in advance before questions arrive, and RAG frameworks typically handle chunking, embedding, and vector database storage.<\/p>\n\n
Step 3: Retrieval and LLM answer generation<\/strong><\/h4>\n\nWhen a user question comes in, it is vectorized with the same embedding model, similarity search is performed, and the retrieved documents are passed to the LLM to generate the final answer.<\/p>\n\n
This RAG retrieval process converts the question into an embedding, extracts relevant chunks via similarity search in the vector DB, assembles them into a prompt, and has the LLM answer. The question must be vectorized in the same way as stored documents to correctly find semantically similar content. <\/p>\n\n
<\/div>\n\n<\/figure>\n\n<\/div>\n\nHow to implement RAG: LangChain vs. LlamaIndex<\/strong><\/h2>\n\n<\/div>\n\nRAG can be implemented with frameworks such as LangChain and LlamaIndex, and each framework differs in how it composes components from document loading through retrieval and generation.<\/p>\n\n
How to implement RAG with LangChain<\/strong><\/h3>\n\nLangChain<\/a> is a framework that builds a RAG pipeline by combining components such as DocumentLoader, Text Splitter, Retriever, and Chains.<\/p>\n\nThe implementation flow is: load documents with a DocumentLoader, split them with a Text Splitter, embed and store them in a vector store, retrieve results with a Retriever, connect them via a Chain, and call the LLM. Because it\u2019s a modular, component-assembly structure, it can flexibly support complex workflows. <\/p>\n\n
How to implement RAG with LlamaIndex<\/strong><\/h3>\n\nLlamaIndex<\/a> is a framework specialized in indexing diverse data sources, with strengths in connecting documents and building indexes.<\/p>\n\nThe core is a data connector that converts content from multiple sources into Document objects and builds them into an index. The official LlamaIndex documentation<\/a> describes this loading process as a flow of loading, transforming, indexing, and storing. Even within RAG, if LangChain emphasizes chain\/agent composition, LlamaIndex\u2019s strengths lie in data indexing and retrieval optimization. <\/p>\n\nCriteria for choosing RAG document preprocessing tools<\/strong><\/h3>\n\nThe right RAG document preprocessing tool depends on the document formats you need to handle and the complexity of their structure. Plain text and PDFs are often fine with basic document loaders, but complex tables or Korean domestic formats typically require separate preprocessing.<\/p>\n\n
LangChain and LlamaIndex document loaders handle pipeline wiring\u2014such as chunking, retrieval, and chain composition\u2014well, but because they\u2019re optimized mainly for PDFs and text, they may struggle to preserve structure for tables with merged cells or domestic formats like HWP and HWPX.<\/p>\n\n
According to reporting by AI Times<\/a>, Hancom Data Loader is a solution that extracts text and various objects from PDFs and Office documents and preprocesses them into data for AI training. It later expanded support to structured data extraction across HWP, HWPX, PDF, and OOXML overall, based on DLA and OCR (Optical Character Recognition) and TSR (Table Structure Recognition). <\/p>\n\n\ud83d\udca1 If table structures or HWP\/HWPX parsing are bottlenecks in your RAG pipeline, you can upload real documents in the Hancom Data Loader live demo and check the extraction results directly.<\/p>\n\n
\ud83d\udc49 Go to Hancom Data Loader Live Demo<\/a><\/p>\n\nLangChain vs. LlamaIndex: what\u2019s different?<\/strong><\/h3>\n\nLangChain is strong at composing diverse LLM chains and agents, while LlamaIndex excels at indexing large document sets and optimizing retrieval\u2014so the right choice depends on your project goals.<\/p>\n\n
IBM<\/a> distinguishes LangChain as an orchestration framework for LLM applications and LlamaIndex as a data orchestration framework.<\/p>\n\nComparison of strengths and best-fit use cases for LangChain and LlamaIndex<\/strong><\/h4>\n\n
RAG system diagram: from document extraction to LLM answers<\/strong><\/h3>\n\nA RAG system works in the order: document extraction \u2192 parsing \u2192 chunking \u2192 embedding \u2192 vector DB storage \u2192 retrieval \u2192 LLM answer. Even though it looks like many steps, it becomes easier to understand when you group them into two parts. <\/p>\n\n
\n- Document extraction \u2013 pulls content from the original document<\/li>\n\n\n\n
- Parsing \u2013 extracts text and structural information<\/li>\n\n\n\n
- Chunking \u2013 splits the document into smaller units<\/li>\n\n\n\n
- Embedding \u2013 converts the split text into numeric vectors<\/li>\n\n\n\n
- Vector DB storage \u2013 loads the converted vectors into a retrieval store<\/li>\n\n\n\n
- Retrieval \u2013 finds the content most similar to the question<\/li>\n\n\n\n
- LLM answer \u2013 generates an answer grounded in the retrieved content<\/li>\n<\/ol>\n\n
The first five steps are the indexing process that prepares data in advance, while the last two steps (retrieval and LLM answering) run each time a question comes in.<\/p>\n\n
The AWS guide<\/a> also notes that embedding storage is a one-time step, while retrieval, augmentation, and generation repeat for every question. This distinction between one-time preparation and repeated execution becomes a key lens for understanding the implementation methods covered later. <\/p>\n\nDocument parsing: the first step in RAG and the baseline for quality<\/strong><\/h3>\n\nDocument parsing is the step that extracts text and structural information from original documents in formats such as HWP, HWPX, and PDF, and it determines the quality of subsequent chunking, embedding, and retrieval.<\/p>\n\n
If structural information is damaged at this stage, every subsequent step inherits data with that structure already lost. <\/strong>As described in Unstructured\u2019s open source<\/a>, the core of parsing is splitting a document into elements such as Title, NarrativeText, and Table\u2014but in the Korean environment, the difficulty rises further with HWP and HWPX, which are optimized for local use. Hancom Data Loader directly parses these HWP\/HWPX files from the original binary without converting them to PDF, preserving table structures, footnotes, and metadata. <\/p>\n\nThe roles of chunking and embeddings<\/strong><\/h3>\n\nChunking is the process of splitting a document into smaller units, and embedding is the process of converting those split texts into numeric vectors that capture meaning.<\/p>\n\n
If chunks are too large, different topics get mixed together and retrieval becomes inaccurate; if they\u2019re too small, context breaks and meaning becomes hard to interpret. Traditional approaches that cut text only by character count fail to reflect document structure such as titles and paragraphs. The study on RAG chunks and frameworks<\/a> points out that this approach cannot produce chunks with sufficient meaning. <\/p>\n\nVector databases and Top-K retrieval<\/strong><\/h3>\n\nA vector database is a retrieval-focused store that saves embedded vectors and quickly finds the vectors most similar to a user\u2019s question. Common vector databases include FAISS and Chroma. <\/p>\n\n
Top-K is the value that determines how many high-similarity items to return from retrieval results. If K is too large, low-relevance information may be pulled in; if it\u2019s too small, needed information can be missed\u2014so choosing an appropriate value matters. <\/p>\n\n
The LLM answer generation stage<\/strong><\/h3>\n\nThe LLM takes the retrieved document chunks as context and generates the final answer based on a prompt that combines them with the user\u2019s question.<\/p>\n\n
A prompt is the combination of retrieved document content and the user\u2019s question. Because the model answers based on retrieved evidence rather than its own memory, how accurately the earlier stages retrieve the right materials largely determines answer quality. <\/p>\n\n
<\/div>\n\n<\/figure>\n\n<\/div>\n\nHow to build a RAG system: from preprocessing to answer generation<\/strong><\/h2>\n\n<\/div>\n\nBuilding a RAG system can be divided into a preprocessing domain that extracts and structures documents, and a retrieval\/generation domain that handles everything from chunking to answer generation\u2014then connecting the two domains with the right solutions.<\/p>\n\n
Building a RAG system: documents<\/strong><\/h3>\n\nThe RAG system build process is divided into a preprocessing domain that extracts and structures documents and a retrieval\/generation domain that handles everything from chunking to answer generation\u2014then connecting each domain with the right solutions.<\/p>\n\n
Step 1: Document structure analysis and RAG document preprocessing<\/strong><\/h4>\n\nIn the document preprocessing stage, you analyze the original document\u2019s layout, tables, and paragraph hierarchy and convert them into structured data. The quality of this output determines chunking accuracy later.<\/p>\n\n
The core of this process is DLA (Document Layout Analysis), which distinguishes text, images, tables, and graphics and identifies their positions and relationships. The results are organized into a standard structure, like the Document objects produced by LangChain<\/a>\u2019s DocumentLoader. However, because you must account for formats, table structures, and Korean-language document characteristics, teams often place a specialized preprocessing solution at the front to handle this stage. <\/p>\n\nStep 2: Chunking, embedding, and vector DB storage<\/strong><\/h4>\n\nPreprocessed data is chunked, vectorized via an embedding model, and stored in a vector database for later retrieval.<\/p>\n\n
This is the indexing stage that prepares retrieval data in advance before questions arrive, and RAG frameworks typically handle chunking, embedding, and vector database storage.<\/p>\n\n
Step 3: Retrieval and LLM answer generation<\/strong><\/h4>\n\nWhen a user question comes in, it is vectorized with the same embedding model, similarity search is performed, and the retrieved documents are passed to the LLM to generate the final answer.<\/p>\n\n
This RAG retrieval process converts the question into an embedding, extracts relevant chunks via similarity search in the vector DB, assembles them into a prompt, and has the LLM answer. The question must be vectorized in the same way as stored documents to correctly find semantically similar content. <\/p>\n\n
<\/div>\n\n<\/figure>\n\n<\/div>\n\nHow to implement RAG: LangChain vs. LlamaIndex<\/strong><\/h2>\n\n<\/div>\n\nRAG can be implemented with frameworks such as LangChain and LlamaIndex, and each framework differs in how it composes components from document loading through retrieval and generation.<\/p>\n\n
How to implement RAG with LangChain<\/strong><\/h3>\n\nLangChain<\/a> is a framework that builds a RAG pipeline by combining components such as DocumentLoader, Text Splitter, Retriever, and Chains.<\/p>\n\nThe implementation flow is: load documents with a DocumentLoader, split them with a Text Splitter, embed and store them in a vector store, retrieve results with a Retriever, connect them via a Chain, and call the LLM. Because it\u2019s a modular, component-assembly structure, it can flexibly support complex workflows. <\/p>\n\n
How to implement RAG with LlamaIndex<\/strong><\/h3>\n\nLlamaIndex<\/a> is a framework specialized in indexing diverse data sources, with strengths in connecting documents and building indexes.<\/p>\n\nThe core is a data connector that converts content from multiple sources into Document objects and builds them into an index. The official LlamaIndex documentation<\/a> describes this loading process as a flow of loading, transforming, indexing, and storing. Even within RAG, if LangChain emphasizes chain\/agent composition, LlamaIndex\u2019s strengths lie in data indexing and retrieval optimization. <\/p>\n\nCriteria for choosing RAG document preprocessing tools<\/strong><\/h3>\n\nThe right RAG document preprocessing tool depends on the document formats you need to handle and the complexity of their structure. Plain text and PDFs are often fine with basic document loaders, but complex tables or Korean domestic formats typically require separate preprocessing.<\/p>\n\n
LangChain and LlamaIndex document loaders handle pipeline wiring\u2014such as chunking, retrieval, and chain composition\u2014well, but because they\u2019re optimized mainly for PDFs and text, they may struggle to preserve structure for tables with merged cells or domestic formats like HWP and HWPX.<\/p>\n\n
According to reporting by AI Times<\/a>, Hancom Data Loader is a solution that extracts text and various objects from PDFs and Office documents and preprocesses them into data for AI training. It later expanded support to structured data extraction across HWP, HWPX, PDF, and OOXML overall, based on DLA and OCR (Optical Character Recognition) and TSR (Table Structure Recognition). <\/p>\n\n\ud83d\udca1 If table structures or HWP\/HWPX parsing are bottlenecks in your RAG pipeline, you can upload real documents in the Hancom Data Loader live demo and check the extraction results directly.<\/p>\n\n
\ud83d\udc49 Go to Hancom Data Loader Live Demo<\/a><\/p>\n\nLangChain vs. LlamaIndex: what\u2019s different?<\/strong><\/h3>\n\nLangChain is strong at composing diverse LLM chains and agents, while LlamaIndex excels at indexing large document sets and optimizing retrieval\u2014so the right choice depends on your project goals.<\/p>\n\n
IBM<\/a> distinguishes LangChain as an orchestration framework for LLM applications and LlamaIndex as a data orchestration framework.<\/p>\n\nComparison of strengths and best-fit use cases for LangChain and LlamaIndex<\/strong><\/h4>\n\n
The first five steps are the indexing process that prepares data in advance, while the last two steps (retrieval and LLM answering) run each time a question comes in.<\/p>\n\n
The AWS guide<\/a> also notes that embedding storage is a one-time step, while retrieval, augmentation, and generation repeat for every question. This distinction between one-time preparation and repeated execution becomes a key lens for understanding the implementation methods covered later. <\/p>\n\n Document parsing is the step that extracts text and structural information from original documents in formats such as HWP, HWPX, and PDF, and it determines the quality of subsequent chunking, embedding, and retrieval.<\/p>\n\n If structural information is damaged at this stage, every subsequent step inherits data with that structure already lost. <\/strong>As described in Unstructured\u2019s open source<\/a>, the core of parsing is splitting a document into elements such as Title, NarrativeText, and Table\u2014but in the Korean environment, the difficulty rises further with HWP and HWPX, which are optimized for local use. Hancom Data Loader directly parses these HWP\/HWPX files from the original binary without converting them to PDF, preserving table structures, footnotes, and metadata. <\/p>\n\n Chunking is the process of splitting a document into smaller units, and embedding is the process of converting those split texts into numeric vectors that capture meaning.<\/p>\n\n If chunks are too large, different topics get mixed together and retrieval becomes inaccurate; if they\u2019re too small, context breaks and meaning becomes hard to interpret. Traditional approaches that cut text only by character count fail to reflect document structure such as titles and paragraphs. The study on RAG chunks and frameworks<\/a> points out that this approach cannot produce chunks with sufficient meaning. <\/p>\n\n A vector database is a retrieval-focused store that saves embedded vectors and quickly finds the vectors most similar to a user\u2019s question. Common vector databases include FAISS and Chroma. <\/p>\n\n Top-K is the value that determines how many high-similarity items to return from retrieval results. If K is too large, low-relevance information may be pulled in; if it\u2019s too small, needed information can be missed\u2014so choosing an appropriate value matters. <\/p>\n\n The LLM takes the retrieved document chunks as context and generates the final answer based on a prompt that combines them with the user\u2019s question.<\/p>\n\n A prompt is the combination of retrieved document content and the user\u2019s question. Because the model answers based on retrieved evidence rather than its own memory, how accurately the earlier stages retrieve the right materials largely determines answer quality. <\/p>\n\n Building a RAG system can be divided into a preprocessing domain that extracts and structures documents, and a retrieval\/generation domain that handles everything from chunking to answer generation\u2014then connecting the two domains with the right solutions.<\/p>\n\n The RAG system build process is divided into a preprocessing domain that extracts and structures documents and a retrieval\/generation domain that handles everything from chunking to answer generation\u2014then connecting each domain with the right solutions.<\/p>\n\n In the document preprocessing stage, you analyze the original document\u2019s layout, tables, and paragraph hierarchy and convert them into structured data. The quality of this output determines chunking accuracy later.<\/p>\n\n The core of this process is DLA (Document Layout Analysis), which distinguishes text, images, tables, and graphics and identifies their positions and relationships. The results are organized into a standard structure, like the Document objects produced by LangChain<\/a>\u2019s DocumentLoader. However, because you must account for formats, table structures, and Korean-language document characteristics, teams often place a specialized preprocessing solution at the front to handle this stage. <\/p>\n\n Preprocessed data is chunked, vectorized via an embedding model, and stored in a vector database for later retrieval.<\/p>\n\n This is the indexing stage that prepares retrieval data in advance before questions arrive, and RAG frameworks typically handle chunking, embedding, and vector database storage.<\/p>\n\n When a user question comes in, it is vectorized with the same embedding model, similarity search is performed, and the retrieved documents are passed to the LLM to generate the final answer.<\/p>\n\n This RAG retrieval process converts the question into an embedding, extracts relevant chunks via similarity search in the vector DB, assembles them into a prompt, and has the LLM answer. The question must be vectorized in the same way as stored documents to correctly find semantically similar content. <\/p>\n\n RAG can be implemented with frameworks such as LangChain and LlamaIndex, and each framework differs in how it composes components from document loading through retrieval and generation.<\/p>\n\n LangChain<\/a> is a framework that builds a RAG pipeline by combining components such as DocumentLoader, Text Splitter, Retriever, and Chains.<\/p>\n\n The implementation flow is: load documents with a DocumentLoader, split them with a Text Splitter, embed and store them in a vector store, retrieve results with a Retriever, connect them via a Chain, and call the LLM. Because it\u2019s a modular, component-assembly structure, it can flexibly support complex workflows. <\/p>\n\n LlamaIndex<\/a> is a framework specialized in indexing diverse data sources, with strengths in connecting documents and building indexes.<\/p>\n\n The core is a data connector that converts content from multiple sources into Document objects and builds them into an index. The official LlamaIndex documentation<\/a> describes this loading process as a flow of loading, transforming, indexing, and storing. Even within RAG, if LangChain emphasizes chain\/agent composition, LlamaIndex\u2019s strengths lie in data indexing and retrieval optimization. <\/p>\n\n The right RAG document preprocessing tool depends on the document formats you need to handle and the complexity of their structure. Plain text and PDFs are often fine with basic document loaders, but complex tables or Korean domestic formats typically require separate preprocessing.<\/p>\n\n LangChain and LlamaIndex document loaders handle pipeline wiring\u2014such as chunking, retrieval, and chain composition\u2014well, but because they\u2019re optimized mainly for PDFs and text, they may struggle to preserve structure for tables with merged cells or domestic formats like HWP and HWPX.<\/p>\n\n According to reporting by AI Times<\/a>, Hancom Data Loader is a solution that extracts text and various objects from PDFs and Office documents and preprocesses them into data for AI training. It later expanded support to structured data extraction across HWP, HWPX, PDF, and OOXML overall, based on DLA and OCR (Optical Character Recognition) and TSR (Table Structure Recognition). <\/p>\n\n \ud83d\udca1 If table structures or HWP\/HWPX parsing are bottlenecks in your RAG pipeline, you can upload real documents in the Hancom Data Loader live demo and check the extraction results directly.<\/p>\n\n \ud83d\udc49 Go to Hancom Data Loader Live Demo<\/a><\/p>\n\n LangChain is strong at composing diverse LLM chains and agents, while LlamaIndex excels at indexing large document sets and optimizing retrieval\u2014so the right choice depends on your project goals.<\/p>\n\n IBM<\/a> distinguishes LangChain as an orchestration framework for LLM applications and LlamaIndex as a data orchestration framework.<\/p>\n\nDocument parsing: the first step in RAG and the baseline for quality<\/strong><\/h3>\n\n
The roles of chunking and embeddings<\/strong><\/h3>\n\n
Vector databases and Top-K retrieval<\/strong><\/h3>\n\n
The LLM answer generation stage<\/strong><\/h3>\n\n
<\/figure>\n\nHow to build a RAG system: from preprocessing to answer generation<\/strong><\/h2>\n\n
Building a RAG system: documents<\/strong><\/h3>\n\n
Step 1: Document structure analysis and RAG document preprocessing<\/strong><\/h4>\n\n
Step 2: Chunking, embedding, and vector DB storage<\/strong><\/h4>\n\n
Step 3: Retrieval and LLM answer generation<\/strong><\/h4>\n\n
<\/figure>\n\nHow to implement RAG: LangChain vs. LlamaIndex<\/strong><\/h2>\n\n
How to implement RAG with LangChain<\/strong><\/h3>\n\n
How to implement RAG with LlamaIndex<\/strong><\/h3>\n\n
Criteria for choosing RAG document preprocessing tools<\/strong><\/h3>\n\n
LangChain vs. LlamaIndex: what\u2019s different?<\/strong><\/h3>\n\n
Comparison of strengths and best-fit use cases for LangChain and LlamaIndex<\/strong><\/h4>\n\n
![\"Image](\"https:\/\/blog.hancom.com\/wp-content\/uploads\/2026\/08\/rag-system-build-ai-document-processing-flow-1024x576.png\")
<\/figure>\n\n![\"Image](\"https:\/\/blog.hancom.com\/wp-content\/uploads\/2026\/08\/hancom-data-loader-key-features-1024x576.png\")
<\/figure>\n\n