한컴으로부터 제품 이용 및 원고료를 지원받아 작성했습니다.

한컴 데이터 로더로 RAG 문서 전처리하기: LangChain 연동 실습

문서 기반 질의응답을 만들 때 모델과 임베딩부터 고르기 쉽습니다. 하지만 규정집이나 매뉴얼처럼 표, 각주, 제목과 본문이 함께 의미를 만드는 문서라면 그보다 앞단의 문서 전처리가 먼저입니다. 검색 단계에서 찾을 수 있는 텍스트 조각은 처음에 문서를 어떤 단위로 만들었는지에 따라 달라지기 때문입니다.

한컴 데이터 로더(Hancom Data Loader)로 문서를 구조화해 LangChain Document로 연결했습니다. 답변에 사용된 페이지와 문서 요소까지 다시 확인하는 RAG 파이프라인으로 구성했습니다.

RAG에서 문서 전처리가 먼저인 이유

RAG는 질문과 관련된 외부 문서를 검색한 뒤 그 결과를 언어 모델의 입력 맥락으로 전달하는 방식입니다. 이 과정은 보통 문서 준비, 분할, 임베딩, 벡터 저장소, 검색, 답변 생성으로 이어집니다. RAG 원 논문과 LangChain Retrieval 문서도 이 흐름을 설명합니다.

검색 단계에서는 원본 문서를 다시 열어 표의 구조나 제목·본문의 관계를 복원하지 않습니다. 앞 단계에서 만들어 둔 텍스트 조각과 메타데이터만 대상으로 질문과 관련된 내용을 찾습니다. 표의 열 제목과 행 값이 분리되거나 본문과 예외 조항이 서로 다른 청크로 떨어지면 모델은 불완전한 근거를 받게 됩니다. 질문에 필요한 수치와 조건이 함께 검색되지 않으면, 답변은 문서를 인용하고 있어도 원래 의미와 달라질 수 있습니다.

여기서 할루시네이션은 원문과 모순되거나 원문으로 뒷받침할 수 없는 내용을 답변에 덧붙이는 경우를 말합니다. RAG는 이 위험을 줄이는 방법이지만, 관련 근거를 찾지 못했거나 근거가 불완전할 때 생성 모델이 추측하지 않는다는 보장은 없습니다. Ji et al.은 원문과 모순되는 경우와 원문에 없는 내용을 더하는 경우를 구분해 설명하며, RAGTruth도 RAG 답변에서 근거와 답변의 관계를 별도로 평가합니다.

답변과 함께 아래 세 가지를 확인합니다.

질문에 필요한 제목, 조건, 수치, 예외가 같은 검색 맥락에 들어왔는지
검색된 조각이 원본의 어느 페이지와 문서 요소에서 왔는지
근거가 부족할 때 답변을 생성하지 않거나 보류할 수 있는지

한컴 데이터 로더란

한컴 데이터 로더는 RAG 솔루션 구축에 활용할 수 있도록 다양한 문서 서식을 데이터화하는 문서 데이터 추출 SDK입니다. 한컴의 제품 소개는 이 서비스를 RAG의 전처리 단계인 LOAD - SPLIT에 쓰는 기술로 설명합니다. 텍스트·표·그림 같은 문서 요소의 위치와 맥락을 인식해 구조화 데이터로 만들고, 문서 안의 데이터를 추출·분리하며, 의미 단위 구분에 활용할 메타데이터를 추출합니다. JSON·CSV 형식으로 후속 시스템에서 활용할 수 있도록 지원합니다. 한컴 데이터 로더 제품 소개

한컴 데이터 로더가 제공하는 결과

“구조화한다”는 말보다 실제 결과의 단위를 보는 편이 빠릅니다. 한컴 데이터 로더의 AIJSON 결과에는 문서 수준 정보, 페이지 크기, 그리고 문서를 이루는 요소 목록이 함께 들어 있습니다. 이 글에 사용한 공개 평가 샘플은 2쪽 PDF에서 제목, 문단, 표, 목록을 각각 요소로 구분해 반환합니다.

아래 JSON은 독자가 작성해 실행하는 코드가 아니라, 한컴 데이터 로더가 반환하는 응답 형식을 이해하기 위한 예시입니다.

문서 수준 AIJSON 응답 예시

{
  "runtime": 0,
  "version": "1.0.0",
  "metadata": {
    "engine": "PDF_AI_DL",
    "format": "PDF",
    "numOfPages": 2,
    "ocrMode": "FORCE",
    "status": "COMPLETED"
  },
  "pageSizes": [
    { "pageIndex": 0, "width": 612.0, "height": 792.0 }
  ]
}

검색에 사용할 텍스트와 요소 정보는 elements에 들어 있습니다. 같은 샘플의 표 요소를 보면 표의 분류, Markdown과 텍스트 표현, 위치, 페이지 정보를 함께 확인할 수 있습니다.

표 요소 AIJSON 응답 예시

{
  "id": "p0o3",
  "category": { "label": "Table", "type": "TABLE" },
  "confidence": 0.9999427795410156,
  "content": {
    "markdown": "|  |  |  |\n| --- | --- | --- |\n| Stage | Owner | Status |\n| Retrieval | Mina | Ready |\n| Generation | Jae | Review |",
    "text": "Stage\tOwner\tStatus\nRetrieval\tMina\tReady\nGeneration\tJae\tReview"
  },
  "bbox": { "left": 71.32195, "top": 231.97646, "width": 468.99588, "height": 90.05297 },
  "pageIndex": 0
}

한컴 데이터 로더 반환값에는 추출 텍스트 외에도 아래 정보가 들어 있습니다.

문서 정보: 처리 엔진, 파일 형식, 페이지 수, OCR 모드, 완료 상태
요소 정보: 요소 ID, 제목·문단·표·목록 등의 분류, 처리 결과 값
콘텐츠 표현: Markdown과 일반 텍스트
원문 연결 정보: 요소의 페이지 번호와 위치 좌표, 페이지 크기

다음 단계에서는 본문과 함께 페이지와 요소 출처도 다룹니다. 여기서는 응답 구조를 확인하는 데 필요한 문서 정보와 대표 요소 하나만 사용했습니다.

평문 추출과 구조화 결과의 차이

평문 추출은 문서 안의 글자를 빠르게 모을 수 있지만, 표의 열과 행, 적용 조건이 붙는 대상, 각주가 설명하는 본문 사이의 관계가 사라질 수 있습니다. 반면 한컴 데이터 로더의 구조화 결과는 표, 목록, 각주 같은 요소 유형과 페이지·위치 정보를 함께 제공합니다.

RAG 검색 단위를 만들 때는 이 차이가 그대로 드러납니다. 원문의 구조 정보가 남아 있으면 어떤 값이 표에 속하는지, 어떤 조건이나 각주가 함께 읽혀야 하는지 판단할 단서로 활용할 수 있기 때문입니다.

평문 추출은 글자를 남기는 데 초점이 있고, 구조화 결과는 문서 요소의 역할과 위치를 검색 단위에 함께 전달합니다.

한컴 데이터 로더는 RAG 파이프라인에서 원본 문서를 다음 단계가 사용할 수 있는 구조화 데이터로 준비합니다. 임베딩 생성, 검색 순위 계산, 답변 생성은 각각 임베딩 모델, VectorStore, 리트리버, 언어 모델이 담당합니다. 답변 근거를 확인하고 부족한 경우 보류하는 규칙은 애플리케이션에서 별도로 설계해야 합니다.

실습에 사용한 langchain-hancom-loader는 변환 API의 결과를 LangChain 형식으로 연결하는 패키지입니다. 한컴 변환 API가 돌려주는 구조화 결과를 개발자에게 익숙한 LangChain 흐름에서 바로 다루기 위해 만들었습니다.

변환 API의 응답을 그대로 사용하면, 응답 구조를 읽고 청킹·벡터 저장소·리트리버에 맞는 형식으로 바꾸는 코드를 애플리케이션마다 다시 작성해야 합니다. 이 패키지는 그 중간을 Document로 맞춥니다. API가 문서 구조를 추출하면 LangChain에서는 이미 쓰던 Text Splitter, VectorStore, Retriever와 모델 연결 방식을 그대로 씁니다. 별도의 RAG 도구를 대체하지 않고, 한컴 데이터 로더의 전처리 결과를 기존 LangChain 파이프라인에 넣는 어댑터 역할을 합니다.

이번에 만든 langchain-hancom-loader는 HWP, HWPX, PDF 입력을 대상으로 검증했습니다. 실제 지원 형식과 정책은 사용하는 계정과 엔드포인트 기준으로 공식 제품 페이지에서 다시 확인해야 합니다.

langchain-hancom-loader는 이 AIJSON 중 RAG 검색에 직접 필요한 요소 데이터를 LangChain이 다루는 Document로 바꿉니다. content.markdown을 우선 사용하고 없으면 content.text를 page_content에 넣습니다. id, 분류, confidence, pageIndex, 위치 좌표는 벡터 저장소에서 다룰 수 있는 메타데이터로 옮깁니다. 페이지 번호는 사람이 읽는 기준으로 1부터 다시 계산해 page에 저장하고, 원래 값은 page_index에 보존합니다.

반면 runtime, OCR 모드, 작업 상태, 페이지 전체 크기처럼 검색 청크마다 반복할 필요가 없는 값은 현재 Document.metadata에 넣지 않습니다. 이런 원본 작업 정보나 전체 AIJSON이 필요할 때는 save_aijson_to 옵션으로 별도 보관합니다. 한컴 데이터 로더가 제공한 문서 구조에서 이 패키지는 LangChain 검색과 근거 표시에 필요한 콘텐츠와 요소 메타데이터만 골라 연결합니다.

변환 API는 문서를 처리한 뒤 구조화된 결과를 돌려줍니다. langchain-hancom-loader는 이 결과를 LangChain Document로 바꿔 이후의 청킹과 검색 단계로 넘깁니다.

실습에 필요한 준비

작은 문서 집합으로 전체 흐름을 확인합니다.

한컴 SDK에서 발급받은 데이터 로더 API 키
권한과 공개 범위를 확인한 HWP, HWPX 또는 PDF 문서
Python 3.10 이상
임베딩과 답변 생성에 사용할 모델 제공자의 API 키
Docker Desktop 또는 Docker Engine

패키지를 설치합니다.

패키지 설치 명령

git clone https://github.com/sungreong/langchain-hancom-loader.git
cd langchain-hancom-loader

python -m venv .venv
# macOS/Linux: source .venv/bin/activate
# Windows PowerShell: .venv\Scripts\Activate.ps1

python -m pip install .
python -m pip install "langchain-openai>=0.3,<2.0"
python -m pip install "langchain-text-splitters>=0.3,<2.0"

최신 설치 방법과 API 범위는 GitHub 저장소를 기준으로 확인합니다. 이 글의 코드는 한컴 변환 API와 모델 제공자의 API를 실제로 호출하므로 각 서비스의 사용량과 권한을 먼저 확인해야 합니다.

로컬에서 webhook 주소 만들기

한컴 데이터 로더 API는 외부에서 접근 가능한 HTTPS webhook 주소를 요구합니다. 로컬 개발 때는 별도 도메인을 만들지 않아도 됩니다. 저장소에 포함된 Compose 구성이 로컬 수신기와 Cloudflare Quick Tunnel을 함께 시작해 임시 공개 주소를 만듭니다.

webhook 수신기와 Quick Tunnel 실행

docker compose -f deploy/compose.webhook.yaml up -d --build --wait

터널이 준비되면 패키지 루트에서 다음 명령으로 실제 주소를 확인합니다.

공개 webhook 주소 확인

hancom-webhook-url
# HANCOM_WEBHOOK_URL=https://<이번 실행에서 생성된 주소>.trycloudflare.com/hancom/webhook

출력된 값을 RAG 예제를 실행하는 환경에 설정합니다. URL은 터널을 다시 만들면 바뀔 수 있으므로, 새로 시작했다면 다시 확인해야 합니다.

환경 변수 설정 예시

HANCOM_API_KEY=발급받은_키
HANCOM_WEBHOOK_URL=https://<위 명령이 출력한 실제 주소>.trycloudflare.com/hancom/webhook
OPENAI_API_KEY=모델_제공자_키
RAG_CHAT_MODEL=사용할_채팅_모델_ID
RAG_EMBEDDING_MODEL=사용할_임베딩_모델_ID

로컬 수신기는 다음처럼 확인할 수 있습니다.

webhook 수신기 상태 확인

curl -i http://localhost:8000/healthz

204 No Content가 반환되면 수신기가 실행 중인 상태입니다. 실습이 끝난 뒤에는 터널과 수신기를 함께 종료합니다.

webhook 수신기와 Quick Tunnel 종료

docker compose -f deploy/compose.webhook.yaml down

Quick Tunnel은 개발·테스트용입니다. 운영에서는 deploy/compose.webhook.production.yaml로 webhook 컨테이너를 실행할 수 있지만, 공개 도메인과 HTTPS는 배포 환경의 Ingress, Load Balancer 또는 리버스 프록시에서 별도로 연결해야 합니다. 운영용 URL은 HANCOM_WEBHOOK_URL에 명시적으로 설정합니다.

문서를 LangChain Document로 바꾸기

mode="elements"는 AIJSON 요소 단위로 문서를 만듭니다. 검색 결과에서 페이지와 요소 정보를 확인할 수 있습니다.

한컴 데이터 로더 결과를 LangChain Document로 변환

import os
from pathlib import Path

from langchain_hancom_loader import HancomDataLoader


input_path = Path("./document.hwpx")

loader = HancomDataLoader(
    input_path,
    api_key=os.environ["HANCOM_API_KEY"],
    webhook_url=os.environ["HANCOM_WEBHOOK_URL"],
    mode="elements",
    save_aijson_to=Path("./artifacts/document.aijson"),
)

documents = loader.load()

first = documents[0]
print(
    {
        "page_content": first.page_content[:200],
        "metadata": {
            key: first.metadata.get(key)
            for key in (
                "file_name",
                "file_format",
                "page",
                "page_index",
                "element_id",
                "category",
                "confidence",
            )
        },
    }
)

loader.load()를 호출하면 지정한 문서를 변환 API에 업로드하고 상태를 확인한 뒤, 완료된 AIJSON을 내려받아 element 단위 Document 목록으로 반환합니다.

save_aijson_to를 지정하면 로더가 Document로 바꾸기 전의 원본 AIJSON도 함께 저장합니다. 이 파일에는 문서 내용과 작업 정보가 포함될 수 있으므로 artifacts/는 Git으로 추적하지 않고, 공개 전에는 식별 정보와 원문 노출 여부를 확인해야 합니다. documents에는 본문뿐 아니라 변환 결과에 포함된 메타데이터가 함께 들어갑니다. 먼저 몇 개의 결과를 출력해 제목, 표, 본문이 어떻게 나뉘었는지와 page, category, element_id 같은 값이 있는지 확인하는 것이 좋습니다. 이 확인 없이 바로 벡터 저장소에 넣으면, 나중에 검색 결과가 어색해도 문서 변환과 청킹 중 어느 단계에서 문제가 생겼는지 구분하기 어렵습니다.

청킹하고 검색 근거를 확인하기

아래 예제는 Document를 청크로 나눈 뒤 메모리 벡터 저장소에 적재하고, 질문에 대한 상위 검색 결과를 출력합니다. 검색 결과가 비어 있으면 답변을 생성하지 않습니다.

청킹과 검색 근거 확인 함수

from __future__ import annotations

import os
from typing import Iterable

from langchain_core.documents import Document
from langchain_core.vectorstores import InMemoryVectorStore
from langchain_openai import OpenAIEmbeddings
from langchain_text_splitters import RecursiveCharacterTextSplitter


def build_retriever(documents: list[Document]):
    splitter = RecursiveCharacterTextSplitter(chunk_size=800, chunk_overlap=120)
    chunks = splitter.split_documents(documents)
    if not chunks:
        raise ValueError("검색할 텍스트 청크가 없습니다.")

    embeddings = OpenAIEmbeddings(model=os.environ["RAG_EMBEDDING_MODEL"])
    vector_store = InMemoryVectorStore.from_documents(chunks, embeddings)
    return vector_store.as_retriever(search_kwargs={"k": 3})


def inspect_evidence(retrieved: Iterable[Document]) -> list[Document]:
    evidence = list(retrieved)
    for rank, document in enumerate(evidence, start=1):
        print(
            {
                "rank": rank,
                "page": document.metadata.get("page"),
                "category": document.metadata.get("category"),
                "element_id": document.metadata.get("element_id"),
                "excerpt": " ".join(document.page_content.split())[:240],
            }
        )
    return evidence

이제 질문을 검색해 근거를 먼저 출력합니다.

질문 검색과 근거 유무 확인

question = "문서에서 제시한 신청 조건은 무엇인가요?"

retriever = build_retriever(documents)
retrieved = inspect_evidence(retriever.invoke(question))

if not retrieved:
    raise ValueError("검색 근거가 없어 답변을 생성하지 않습니다.")

검색 순위뿐 아니라 질문과 직접 관련 있는지, 조건·수치·예외가 함께 검색됐는지, 페이지와 요소 정보로 원문을 되짚을 수 있는지도 확인합니다. k=3은 예시일 뿐이며 문서와 질문 유형에 맞춰 조정해야 합니다.

`pypdf` 직접 추출과 한컴 데이터 로더 전처리 비교

비교에 사용한 자료는 36쪽짜리 영어 연구 논문 Why Language Models Hallucinate의 PDF입니다. 테스트 파일은 why-language-models-hallucinate.pdf로 저장했습니다. 같은 논문을 pypdf의 PdfReader.extract_text()로 페이지 전체 텍스트만 추출한 경로와, 한컴 데이터 로더가 반환한 AIJSON에서 제목·본문·표·목록을 구분해 사용한 경로에 각각 넣었습니다. 두 경로 모두 청크 크기 800자, 겹침 120자, text-embedding-3-small, 상위 3건 검색으로 맞춘 뒤 검색 결과와 답변 근거를 비교했습니다.

이번 비교에서는 IDK의 단순 일치보다 표 2 아래의 짧은 각주를 찾고, 그 근거로만 답변을 만드는지를 봤습니다.

같은 질문, 다른 검색 근거

표 2의 채점 기준 각주는 IDK 응답을 어떻게 설명하는가?

비교 항목	`pypdf` 직접 추출 — 문서 전처리 없음	한컴 데이터 로더 전처리 후
RAG에 넣은 단위	`PdfReader.extract_text()`가 뽑은 페이지 전체 텍스트를 일반 청크로 분할했습니다. 표 본문과 각주가 별도 타입으로 남지 않습니다.	AIJSON의 제목·본문·표·목록을 사용했습니다. 표와 각주는 별도 요소로 유지하고, 제목은 본문 청크에 연결했습니다.
상위 3건 검색	표 2의 14쪽 각주를 찾지 못했습니다. 가장 가까운 1위는 35쪽의 후속 본문이었습니다. 내용은 관련 있지만 질문이 가리킨 원래 각주는 아닙니다.	2위에서 표 2의 14쪽 각주를 찾았습니다. 결과에 `page: 14`, `category: "ListText"`, `element_id: "p13o4"`가 남았습니다.
근거 확인	페이지 번호도 질문의 대상과 다르고, 이 문장이 표의 각주인지 구분할 정보가 없습니다.	페이지·요소 유형·요소 ID로 “표 아래 각주”임을 검색 결과만으로 확인할 수 있습니다.

질문이 요구한 근거는 표 2 아래의 14쪽 각주입니다.

pypdf 직접 추출은 비슷하지만 다른 근거를 찾았습니다.

35쪽의 후속 본문에는 “IDK 응답은 낮은 점수를 받을 수 있다”는 설명이 있습니다. 질문과 주제는 맞닿아 있지만, 표 2의 각주가 아닙니다. 페이지 텍스트만 남았기 때문에 검색 결과만 보고는 이 문장이 표·본문·각주 중 어디에서 왔는지도 알 수 없습니다.

한컴 데이터 로더 전처리는 질문이 가리킨 실제 근거를 찾았습니다.

14쪽 표 2의 각주에는 “IDK가 할루시네이션이 있는 ‘fair’ 응답보다 낮은 점수를 받을 수 있어 할루시네이션을 강화한다”는 내용이 있습니다. 검색 결과에는 ListText, p13o4가 남아 이 문장이 표 아래의 각주라는 점까지 확인할 수 있습니다.

pypdf는 주제는 비슷하지만 출처가 다른 문장을 찾았고, 한컴 데이터 로더는 질문이 요구한 바로 그 표의 각주를 찾았습니다. 이 차이 때문에 단순 키워드 일치만으로는 답할 수 없는 질문에서, “관련 있어 보이는 문장”과 “실제로 인용해야 할 근거”를 구분할 수 있습니다.

검색 결과가 답변 품질에 미친 영향

검색 결과를 그대로 답변 모델에 전달하면 pypdf가 찾은 35쪽의 관련 문장으로도 그럴듯한 답을 만들 수 있습니다. 여기서는 질문이 가리킨 근거에 답변을 묶었는지를 기준으로 판단했습니다. 검증 규칙은 표 2의 14쪽 각주가 상위 검색 결과에 있을 때만 답변하도록 설정했습니다.

문서 추출과 검색에는 LLM을 쓰지 않았고, 답변 확인 단계에서만 gpt-4o-mini, temperature=0을 사용했습니다.

확인 항목	`pypdf` 직접 추출	한컴 데이터 로더 전처리
답변 상태	답변 보류	근거 기반 답변 생성
실제 출력	`INSUFFICIENT_EVIDENCE`	`The Table 2 grading-rubric notes that an IDK response may score lower than "fair" responses with hallucination, reinforcing hallucination.`
판단 근거	상위 3건에 표 2의 14쪽 각주가 없어, 관련 본문으로 추측해 답하지 않았습니다.	14쪽 `ListText` 각주 `p13o4`만 근거로 답변했습니다.

한컴 데이터 로더 경로에서는 원래 표의 각주가 검색 결과에 남아 답변 가능 여부와 인용 근거를 판단할 수 있었습니다. pypdf처럼 페이지 텍스트만 쓰는 경로도 단순 문단 질문에는 충분했습니다. 같은 8개 질문의 전체 적중 수도 두 경로 모두 4건이었습니다. 청킹 규칙은 실제 문서와 질문으로 검증해야 합니다. 표·각주·목록의 역할이 중요한 질의라면 남아 있는 구조 정보를 검색에 활용합니다.

근거가 있는 경우에만 답변 만들기

검색 결과에 필요한 정보가 있음을 확인한 뒤 그 근거만 언어 모델에 전달해 답변을 만듭니다.

검색된 근거만 사용하는 답변 생성 코드

from langchain_openai import ChatOpenAI


def answer_with_evidence(question: str, evidence: list[Document]) -> str:
    context = "\n\n---\n\n".join(
        f"[페이지 {document.metadata.get('page')}, "
        f"{document.metadata.get('category')}]\n{document.page_content}"
        for document in evidence
    )

    llm = ChatOpenAI(model=os.environ["RAG_CHAT_MODEL"], temperature=0)
    response = llm.invoke(
        [
            (
                "system",
                "제공된 근거만 사용해 한국어로 답하세요. 근거에 없으면 모른다고 답하고 "
                "추측하지 마세요. 답변 끝에 사용한 페이지 번호를 적으세요.",
            ),
            ("human", f"질문: {question}\n\n근거:\n{context}"),
        ]
    )
    return str(response.content)


print(answer_with_evidence(question, retrieved))

예제 코드는 retrieved가 비어 있는지만 검사합니다. 서비스 코드에서는 검색 결과의 관련성과 충분성도 판정하고, 답변 보류 UI와 질문·문서 버전·검색된 요소 ID 로그를 함께 둬야 합니다.

마무리

이번 실습에서는 한컴 데이터 로더의 구조화 결과를 일반 개발자도 기존 LangChain 흐름에서 바로 사용할 수 있도록 langchain-hancom-loader를 만들어 연동해 봤습니다. 변환 결과를 LangChain Document로 맞추는 과정은 생각보다 복잡하지 않았습니다. elements 모드에는 페이지, 요소 분류, 요소 ID와 위치 정보가 들어 있어 검색 출처 확인과 후처리 기준 작성이 수월했습니다.

아쉬운 점은 webhook 수신 환경을 사용자가 직접 준비해야 한다는 것입니다. 비동기 결과 전달을 위한 구조지만, 일반적인 로더를 연동할 때는 없던 외부 HTTPS 수신기 구현과 배포가 추가됩니다. 이번 패키지에서는 Compose 수신기와 Quick Tunnel로 처리했습니다. 한컴에서 기본 수신기를 제공하거나 webhook 없이 결과를 조회하는 방식도 지원하면 비개발자의 설정 부담이 줄어듭니다.

참고 자료

저작자표시 (새창열림)

'꿀팁 분석 환경 설정 > 소프트웨어리뷰' 카테고리의 다른 글

WinZoneTrigger 소개: 장소에 도착하면 PC가 먼저 준비되는 Windows 앱 (1)	2026.06.03
UPDF와 GPT-5로 경험한 PDF 작업 혁신: 더 스마트하게, 더 빠르게, 더 안전하게 (7)	2025.08.21

한컴 데이터 로더로 RAG 문서 전처리하기: LangChain 연동 실습

한컴 데이터 로더로 RAG 문서 전처리하기: LangChain 연동 실습

RAG에서 문서 전처리가 먼저인 이유

한컴 데이터 로더란

한컴 데이터 로더가 제공하는 결과

평문 추출과 구조화 결과의 차이

실습에 필요한 준비

로컬에서 webhook 주소 만들기

문서를 LangChain Document로 바꾸기

청킹하고 검색 근거를 확인하기

`pypdf` 직접 추출과 한컴 데이터 로더 전처리 비교

같은 질문, 다른 검색 근거

검색 결과가 답변 품질에 미친 영향

근거가 있는 경우에만 답변 만들기

마무리

참고 자료

'꿀팁 분석 환경 설정 > 소프트웨어리뷰' 카테고리의 다른 글

AI 도구

AI 도구 사이드 패널

티스토리툴바

한컴 데이터 로더로 RAG 문서 전처리하기: LangChain 연동 실습

RAG에서 문서 전처리가 먼저인 이유

한컴 데이터 로더란

한컴 데이터 로더가 제공하는 결과

평문 추출과 구조화 결과의 차이

실습에 필요한 준비

로컬에서 webhook 주소 만들기

문서를 LangChain Document로 바꾸기

청킹하고 검색 근거를 확인하기

pypdf 직접 추출과 한컴 데이터 로더 전처리 비교

같은 질문, 다른 검색 근거

검색 결과가 답변 품질에 미친 영향

근거가 있는 경우에만 답변 만들기

마무리

참고 자료

'꿀팁 분석 환경 설정 > 소프트웨어리뷰' 카테고리의 다른 글

AI 도구

AI 도구 사이드 패널

티스토리툴바

`pypdf` 직접 추출과 한컴 데이터 로더 전처리 비교