{"id":1290,"date":"2026-08-07T09:00:00","date_gmt":"2026-08-07T00:00:00","guid":{"rendered":"https:\/\/blog.hancom.com\/rag-vs-fine-tuning-preprocessing-tool\/"},"modified":"2026-08-07T15:11:48","modified_gmt":"2026-08-07T06:11:48","slug":"rag-vs-fine-tuning-preprocessing-tool","status":"publish","type":"post","link":"https:\/\/blog.hancom.com\/en\/rag-vs-fine-tuning-preprocessing-tool\/","title":{"rendered":"From RAG vs. Fine-Tuning to Choosing a Preprocessing Tool | Where Should You Start with Internal Document AI?"},"content":{"rendered":"\n

When building internal document\u2013based AI for AI transformation (AX), the first decision is whether to train the model or to retrieve and use the documents you need.<\/p>\n\n

This is where the comparison between RAG and fine-tuning begins. RAG (Retrieval-Augmented Generation) retrieves documents outside the model and uses them as evidence for answers, while fine-tuning further trains the model itself to reflect specific knowledge or response styles. <\/p>\n\n

In this article, we compare the differences between RAG and fine-tuning, outline what you should decide first when building internal document AI, and\u2014if you choose RAG\u2014summarize what criteria to use when evaluating preprocessing tools.<\/p>\n\n

<\/div>\n\n

Why can\u2019t an LLM alone answer internal document questions accurately?<\/strong><\/h2>\n\n
<\/div>\n\n

The point in time up to which an LLM\u2019s training data reflects knowledge is called the knowledge cutoff. When asked about internal documents that are not in its training data, the model tends to fabricate plausible-sounding content rather than say \u201cI don\u2019t know.\u201d This phenomenon\u2014producing incorrect answers as if they were facts\u2014is called hallucination. <\/p>\n\n

That\u2019s why, when building internal document\u2013based AI, the question arises: \u201cHow do we connect our knowledge to the model?\u201d<\/p>\n\n

The answer broadly splits into two paths. One is fine-tuning, which retrains the model itself on your data. The other is RAG, which does not retrain the model, but retrieves the necessary documents and generates answers grounded in that content. In this article, we\u2019ll briefly compare how the two approaches differ in practice. <\/p>\n\n

<\/div>\n\n

Comparing the differences between RAG and fine-tuning<\/strong><\/h2>\n\n
<\/div>\n\n

RAG and fine-tuning are two ways to adapt an LLM to a specific task. According to Google Cloud\u2019s fine-tuning overview<\/a>, fine-tuning adjusts a model\u2019s parameters by further training a pre-trained LLM on task-specific datasets. By contrast, RAG doesn\u2019t retrain the model; instead, when a question comes in, it finds relevant content in an external document repository and includes it in the prompt for use. <\/p>\n\n

Put simply, RAG is like keeping an \u201cinternal document library\u201d next to the model and having it look things up as needed, while fine-tuning is closer to additional training so the model follows specific task knowledge or response styles more effectively.<\/p>\n\n

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

Comparing how RAG and fine-tuning work<\/strong><\/h3>\n\n

RAG<\/strong> is an approach that, rather than retraining the model itself, retrieves relevant content from an external document repository when a question comes in and includes it in the prompt. <\/p>\n\n

By contrast, fine-tuning<\/strong> further trains the model on task-specific data to embed knowledge or response styles for a particular domain into the model. The two approaches differ starting from what they change. <\/p>\n\n

In a comparative study by Microsoft researchers<\/a>, RAG is described as augmenting prompts with external data, while fine-tuning is described as integrating additional knowledge into the model itself. Even though both enhance knowledge, RAG differs in that it retrieves relevant documents and provides them as answer context, whereas fine-tuning further trains the model on task-specific data. <\/p>\n\n

Comparing how RAG and fine-tuning work<\/strong><\/h4>\n\n
Comparison criteria<\/strong><\/td>RAG<\/strong><\/td>Fine-tuning<\/strong><\/td><\/tr>
How knowledge is used<\/td>Finds the required information in documents outside the model and uses it together in the answer.<\/td>Further trains the model on task-specific data to tailor it to a specific task.<\/td><\/tr>
How the model is changed<\/td>Provides retrieval results as answer context without significantly changing the model itself.<\/td>Can adjust the model\u2019s weights or some parameters.<\/td><\/tr>
How new documents are reflected<\/td>Can incorporate new documents into the retrieval target to use up-to-date information.<\/td>To reflect new information in the model, you need to consider additional training or retraining.<\/td><\/tr>
Verifying answer evidence<\/td>If you present the retrieved documents together, it\u2019s easy to verify the basis for the answer.<\/td>Because the answer is generated inside the model, tracing evidence at the document level is relatively difficult.<\/td><\/tr>
Best-fit situations<\/td>Suitable when documents change frequently or when verifying sources is important.<\/td>Suitable when you need to align terminology, response formats, or classification criteria.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n

It\u2019s hard to say that either RAG or fine-tuning is always better. In Microsoft\u2019s comparative study<\/a>, applying fine-tuning and RAG together to a specific agriculture dataset further improved accuracy. In other words, the two are less competitors than complementary approaches that can be used separately or combined depending on the goal. If you need to quickly reflect the latest documents and verify answer sources, consider RAG first. If you need to adjust the tone or response format for a specific task, consider fine-tuning first. <\/p>\n\n

A domain-specialized model case: BloombergGPT<\/strong><\/h3>\n\n

Fine-tuning is useful for aligning a model to a specific task\u2019s tone or response format. However, the more you aim to reflect a domain\u2019s knowledge more broadly and deeply within the model itself, the greater the burden of data preparation and training infrastructure. BloombergGPT is a representative example. <\/p>\n\n

According to the BloombergGPT paper<\/a>, BloombergGPT is a finance-specialized LLM with 50 billion parameters, trained from scratch using both financial data and general-purpose data. Rather than a typical fine-tuning case, it is closer to a large-scale pre-training case where the model itself was designed and trained for the finance domain. <\/p>\n\n

Domain-specialized models like this can deliver high expertise, but they also require substantial training resources. In an HPCwire analysis<\/a>, BloombergGPT training reportedly used about 1.3 million GPU hours, with an estimated cost of around $3 million on AWS.<\/p>\n\n

Therefore, fine-tuning or building your own model can be a powerful option when your goals and budget are clear. However, for most public institutions and companies that are at the early stage of building internal document\u2013based AI, it\u2019s often more realistic to start by considering RAG, which retrieves external documents and uses them to generate answers rather than training a new model from scratch. <\/p>\n\n

<\/div>\n\n

RAG selection criteria: when is RAG the right fit?<\/strong><\/h2>\n\n
<\/div>\n\n

If documents change frequently, if you need to verify the evidence behind answers, or if it\u2019s difficult to send internal documents outside your organization, RAG is a strong first option to consider. These conditions are common in internal document\u2013based AI, which is why RAG often becomes a practical starting point. <\/p>\n\n

Criteria to consider when building RAG<\/strong><\/h3>\n\n

If documents change frequently, if you need to verify the basis for answers, or if it\u2019s difficult to send documents outside your organization, RAG is a strong first option to consider. That\u2019s because RAG doesn\u2019t retrain the model itself; it retrieves the necessary documents and uses them as answer context. <\/p>\n\n

For example, if you\u2019re dealing with documents that are continuously added or revised\u2014such as policy documents, work manuals, official notices, or legal\/financial materials\u2014retraining the model every time can create a heavy operational burden. RAG, on the other hand, can use the latest documents by parsing, chunking, and embedding new content and adding it to the retrieval target. <\/p>\n\n

RAG is also advantageous in areas like the public sector, finance, and legal work where you must verify answer sources. Presenting the retrieved original documents together makes it easier to confirm which documents the answer was based on. And if security constraints make it difficult to send documents to an external cloud, you can also consider an on-premises RAG setup with a document repository and retrieval pipeline inside your internal network. <\/p>\n\n

In summary, for internal document\u2013based AI where documents change frequently and source verification matters, RAG can be a practical starting point. Conversely, if you need to adjust the model\u2019s response behavior itself\u2014such as tone, response format, or classification criteria\u2014it\u2019s best to consider fine-tuning as well. <\/p>\n\n

*Reference content: <\/em>elastic<\/em><\/a>, \u201cRAG vs. Fine Tuning, a practical approach\u201d, 2025<\/em><\/p>\n\n

Why RAG preprocessing quality matters<\/strong><\/h3>\n\n

RAG answer quality is not determined by LLM performance alone. It also depends on how accurately you read documents and how well you preserve their structure when converting them into searchable data. Even with an excellent model, if documents are extracted incorrectly, the AI can generate answers based on incorrect evidence. <\/p>\n\n

The problem often occurs during the data extraction stage. For example, if a table title is extracted without being linked to its data, the AI may read the same numbers but struggle to tell which item those numbers belong to. If the relationships between table rows and columns, headings and body text, or captions and images break down, the retrieved document chunks themselves can become incomplete. <\/p>\n\n

That\u2019s why the starting point for RAG isn\u2019t only \u201cWhich LLM should we use?\u201d but also \u201cHow do we parse documents accurately?\u201d ChatDOC researchers<\/a> pointed out that low PDF parsing accuracy can affect the quality of expert knowledge\u2013based Q&A. In comparative experiments, they also showed that parsers that better recognize document structure can provide more accurate and complete retrieval results, which can lead to improved RAG answer quality. <\/p>\n\n

\ud83d\udcda Recommended reading<\/strong>RAG performance is determined not by AI, but by \u2018document preprocessing\u2019 | Hancom Data Loader<\/a><\/p>\n\n

<\/div>\n\n

What to check when choosing a RAG preprocessing tool<\/strong><\/h2>\n\n
<\/div>\n\n

When selecting a RAG preprocessing tool\u2014an LLM preprocessing tool that converts documents into data the AI can read\u2014you should evaluate whether it parses originals directly, recognizes table and document structure, extracts while preserving document hierarchy, and can be deployed on-premises.<\/p>\n\n

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

Whether it supports direct parsing of original files<\/strong><\/h3>\n\n

When choosing a preprocessing tool, first check whether it parses the original files directly without converting documents to PDF. Information can be lost during conversion. <\/p>\n\n

Some tools are labeled as \u201csupported\u201d but internally convert to PDF before processing. In such cases, HWP parsing errors are more likely to occur, breaking table structures or heading hierarchies. In particular, because HWP and HWPX are widely used in documents from Korean public institutions, it\u2019s important to verify whether the tool can parse the originals directly without conversion.<\/strong> <\/p>\n\n

Table structure recognition (TSR) and document layout analysis (DLA)<\/strong><\/h3>\n\n

When evaluating a RAG preprocessing tool, you should check both TSR (Table Structure Recognition) and DLA (Document Layout Analysis). Internal documents often contain tables with merged cells, multi-level headers, notes, and images. If you extract them as plain text only, the relationships between rows and columns can easily break. <\/p>\n\n

For example, if only the numbers in a table are extracted and they aren\u2019t linked to what items and periods they represent, the AI can produce incorrect answers even when looking at the same data. The technology needed here is TSR. TSR identifies relationships between cells to preserve row\/column structure and converts merged or complex tables into a form that is easier for AI to understand. <\/p>\n\n

Accurately reading tables alone is not enough. You also need to understand how headings, body text, tables, images, and captions are arranged in what order and relationship within the document. DLA distinguishes these document elements and restores the reading order, helping ensure that meaning units aren\u2019t broken during the subsequent chunking stage. <\/p>\n\n

Chunking quality and reflecting document hierarchy<\/strong><\/h3>\n\n

Because chunking that reflects a document\u2019s hierarchical structure determines retrieval accuracy, you should verify whether the preprocessing stage extracts content while preserving hierarchy information for headings and body text.<\/p>\n\n

To use long documents for retrieval, you go through a chunking process that splits them into appropriately sized pieces. Instead of mechanically cutting by character count, using a document chunking strategy that reflects the hierarchy and meaning of headings, subheadings, and body text\u2014i.e., semantic chunking\u2014keeps meaning grouped together and improves retrieval accuracy. Microsoft Azure\u2019s RAG chunking guide<\/a> also explains that document structure affects chunking methods. <\/p>\n\n

Chunking itself is a task at the RAG solution stage rather than the preprocessing tool stage, but the more accurately the preprocessing tool extracts hierarchy information, the better semantic chunking can operate later based on that information. In that sense, how well hierarchy is preserved during preprocessing is the starting point for chunking quality. <\/p>\n\n

Deployment options and security environment<\/strong><\/h3>\n\n

When choosing a RAG preprocessing tool, it\u2019s a good idea to check both on-premises deployment and SaaS API integration. For environments like financial networks, closed networks, or public institutions where it\u2019s difficult to send documents to the cloud, an on-premises approach that can be installed and operated directly inside the internal network is suitable. Because documents are not transmitted externally, it\u2019s a good fit to consider in high-security environments. <\/p>\n\n

Conversely, if you need rapid testing or a pilot rollout, you can also choose a SaaS API approach. With SaaS APIs, you can integrate without building separate servers, and because costs accrue based on usage with per-page billing, you can reduce upfront investment. It can also be used to verify parsing quality on real documents before moving to an on-premises build. <\/p>\n\n

\ud83d\udc49 Check parsing results instantly with your own documents (Live demo)<\/a><\/p>\n\n

<\/div>\n\n

RAG preprocessing tool adoption environments: public sector, finance, internal documents<\/strong><\/h2>\n\n
<\/div>\n\n

If HWP\/HWPX usage is high, or if you\u2019re in an environment like a closed network or financial network where it\u2019s difficult to transmit documents externally, choosing a RAG preprocessing tool becomes even more important. For documents with many tables, images, and hierarchical structures, simple text extraction can break meaning relationships\u2014so the key is whether the tool can parse original documents directly and preserve structure. <\/p>\n\n

RAG for public sector, finance, and legal documents<\/strong><\/h3>\n\n

In the public sector, finance, and legal domains, document security and verifying answer sources are critical. In these environments, many organizations prioritize considering an on-premises RAG setup that can process documents within the internal network rather than uploading documents to an external cloud. <\/p>\n\n

Also, in public-sector document environments, HWP\/HWPX and PDF are often used together. HWPX is an XML-based open format, which is advantageous for use as structured data, but in real-world settings where you must handle legacy HWP documents and PDFs together, you need a preprocessing tool that can reliably parse multiple formats. <\/p>\n\n

Building internal knowledge search and \uc5c5\ubb34 chatbots<\/strong><\/h3>\n\n

Internal manuals, reports, and guidelines often include many tables and hierarchical structures. If the relationships between headings and body text, table titles and data, or images and captions are broken during extraction, chatbot answer accuracy can also decline. <\/p>\n\n

Getting started with internal AI: Hancom Data Loader<\/strong><\/h3>\n\n

\ud83d\udda5\ufe0f<\/strong>Hancom Data Loader<\/strong><\/a><\/h3>\n\n

Internal documents are often a mix of HWP\/HWPX and PDF, so whether you can handle them with a single solution determines operational efficiency. There have already been reported adoption cases in the public and education sectors. In the Gyeonggi Provincial Office of Education\u2019s AI Digital Platform \uad6c\ucd95 project<\/a>, Hancom participated in an LG CNS-led consortium and was responsible for preprocessing that structures school websites, guidance materials, and guideline\/legal data while preserving hierarchy, coordinates, and complex tables across HWP, HWPX, and PDF. <\/p>\n\n

Internal document AI starts with choosing between fine-tuning and RAG, but in environments where documents change frequently and source verification is important, RAG can be a practical starting point. If you choose RAG, answer quality depends heavily on preprocessing quality\u2014so the criteria you use to select a preprocessing tool ultimately becomes the key. <\/p>\n\n

If you\u2019re considering adopting internal document AI, first upload real documents in the Hancom Data Loader live demo and check the parsing results. <\/p>\n\n

\ud83d\udc49 <\/strong>Check parsing results instantly with your own documents (Live demo)<\/strong><\/strong><\/a>\ud83d\udc49 <\/strong>Get implementation consulting tailored to your environment<\/strong><\/a><\/p>\n\n

Frequently asked questions (FAQ) about RAG preprocessing<\/strong><\/h3>\n
\n
\n
\n

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

RAG keeps the model as-is and injects answers by retrieving external documents, while fine-tuning retrains the model itself to imprint knowledge inside the model. RAG is advantageous for quickly reflecting new information and reducing costs, while fine-tuning is advantageous for internalizing domain tone and formats in the model. <\/p>\n\n<\/div>\n<\/div>\n

\n

When building a RAG pipeline, how should we handle document preprocessing?<\/strong><\/strong><\/strong><\/h3>\n
\n\n

To improve retrieval quality, you should parse documents while preserving the original structure\u2014keeping tables and heading hierarchy\u2014then chunk and embed while reflecting that hierarchy. Because preprocessing quality determines RAG answer accuracy, it\u2019s important to prevent structure from breaking during extraction. <\/p>\n\n<\/div>\n<\/div>\n

\n

What are the criteria for choosing a document preprocessing tool for RAG?<\/strong><\/strong><\/strong><\/h3>\n
\n\n

Choose based on four criteria: direct original parsing, table\/document structure recognition, extraction that preserves hierarchy information, and on-premises deployment. In closed-network environments, also verify whether it can be installed inside the internal network and operated without sending documents externally. <\/p>\n\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n

\n\n

References<\/strong><\/h2>\n\n
    \n
  1. Google Cloud<\/a>, \u201cFine-tuning LLMs and AI models\u201d<\/li>\n\n\n\n
  2. Arxiv<\/a>, \u201cRAG vs Fine-tuning: Pipelines, Tradeoffs, and a Case Study on Agriculture\u201d, 2024<\/li>\n\n\n\n
  3. Arxiv<\/a>, \u201cBloombergGPT: A Large Language Model for Finance\u201d, 2023<\/li>\n\n\n\n
  4. HPCwire<\/a>, \u201cBloomberg Uses 1.3 Million Hours of GPU Time for Homegrown Large Language Model\u201d, 2023<\/li>\n\n\n\n
  5. Arxiv<\/a>, \u201cRevolutionizing Retrieval-Augmented Generation with Enhanced PDF Structure Recognition\u201d, 2024<\/li>\n\n\n\n
  6. Elasticsearch Labs<\/a>, \u201cRAG vs. Fine Tuning, a practical approach\u201d, Elasticsearch Labs, 2025<\/li>\n\n\n\n
  7. Microsoft Learn<\/a>, \u201cDeveloping RAG Solutions \u2013 Chunking Stage\u201d<\/li>\n<\/ol>\n","protected":false},"excerpt":{"rendered":"

    Are you unsure whether to choose RAG or fine-tuning when building internal document AI? We compare the differences between the two approaches and the criteria for applying them. We also explain, in an easy-to-follow way, why RAG preprocessing quality determines answer accuracy\u2014and what to look for when choosing a document parsing solution. <\/p>\n","protected":false},"author":2,"featured_media":1476,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26,10],"tags":[],"class_list":["post-1290","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ax-insight","category-10"],"_links":{"self":[{"href":"https:\/\/blog.hancom.com\/en\/wp-json\/wp\/v2\/posts\/1290","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=1290"}],"version-history":[{"count":6,"href":"https:\/\/blog.hancom.com\/en\/wp-json\/wp\/v2\/posts\/1290\/revisions"}],"predecessor-version":[{"id":1480,"href":"https:\/\/blog.hancom.com\/en\/wp-json\/wp\/v2\/posts\/1290\/revisions\/1480"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.hancom.com\/en\/wp-json\/wp\/v2\/media\/1476"}],"wp:attachment":[{"href":"https:\/\/blog.hancom.com\/en\/wp-json\/wp\/v2\/media?parent=1290"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.hancom.com\/en\/wp-json\/wp\/v2\/categories?post=1290"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.hancom.com\/en\/wp-json\/wp\/v2\/tags?post=1290"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}