본문 바로가기
AI/LLM

RAG란? 사내 문서와 LLM을 연결하는 검색증강생성 완벽 이해

by eplus 2026. 8. 4.

ChatGPT와 같은 LLM은 방대한 자료를 학습했지만 우리 회사의 작업표준서, 설비 매뉴얼, 품질규정, 생산실적까지 알고 있지는 않습니다.

회사 내부자료를 프롬프트에 매번 복사해 넣는 것도 현실적이지 않습니다. 문서가 수천 개라면 LLM이 어떤 문서를 참고해야 하는지도 판단하기 어렵습니다.

이 문제를 해결하는 대표적인 기술이 RAG입니다.

RAG를 적용하면 사용자의 질문과 관련된 사내 문서를 먼저 찾고, 검색된 내용을 LLM에 전달해 근거 중심의 답변을 생성할 수 있습니다.


1. RAG란?

RAG는 Retrieval-Augmented Generation의 약자로, 우리말로는 검색증강생성이라고 합니다.

이름을 세 부분으로 나누면 쉽게 이해할 수 있습니다.

  • Retrieval: 관련 자료 검색
  • Augmented: 검색한 자료로 정보 보강
  • Generation: LLM을 이용해 답변 생성

즉, RAG는 다음과 같은 방식입니다.

사용자의 질문과 관련된 자료를 먼저 검색한 후,
검색 결과를 LLM에 제공해 답변을 생성하는 방식

RAG는 LLM이 학습하면서 기억한 지식인 ‘파라미터 기억’과 문서·검색 인덱스 같은 외부 지식인 ‘비파라미터 기억’을 결합하는 개념으로 제시됐습니다. RAG 원 논문


2. RAG가 필요한 이유

LLM만 사용하면 다음과 같은 문제가 발생합니다.

회사 내부정보를 모름

공개형 LLM은 일반적인 MES 개념은 설명할 수 있지만 특정 회사의 공정, 설비, 품질기준과 업무규칙은 알지 못합니다.

최신정보를 알지 못함

LLM이 학습된 이후 개정된 법률, 규정, 매뉴얼과 제품정보는 모델에 반영되지 않을 수 있습니다.

잘못된 답변을 만들 수 있음

LLM은 모르는 질문에도 문맥상 자연스러운 답변을 만들어낼 수 있습니다. 이를 환각 또는 Hallucination이라고 합니다.

답변 출처가 불분명함

LLM이 어떤 자료를 근거로 답했는지 확인하기 어렵습니다.

모델 재학습은 부담이 큼

문서가 변경될 때마다 LLM을 다시 학습하는 것은 시간과 비용이 많이 듭니다.

RAG를 사용하면 문서 검색 인덱스만 갱신해 최신 자료를 반영할 수 있습니다.


3. 일반 LLM과 RAG의 차이

일반 LLM

 
 
 

사용자가 다음과 같이 질문했다고 가정하겠습니다.

프레스 2호기의 이상 진동 기준은 무엇인가요?

일반 LLM은 해당 회사의 프레스 2호기 기준을 알지 못하므로 일반적인 진동점검 방법을 답하거나 잘못된 기준을 만들 수 있습니다.

RAG 적용 LLM

 
 
 

RAG 시스템은 다음 자료를 먼저 찾습니다.

  • 프레스 2호기 설비점검 기준서
  • 예방보전 작업표준서
  • 과거 이상 진동 조치이력
  • 제조사 설비 매뉴얼

LLM은 검색된 내용을 근거로 답변하고 참고 문서까지 표시할 수 있습니다.


4. RAG의 핵심 구성요소

RAG 시스템은 크게 다음 요소로 구성됩니다.

구성요소역할
원본 데이터 PDF, Word, DB, 웹페이지 등
문서 처리기 텍스트 추출과 정제
Chunk 처리기 문서를 검색 단위로 분할
임베딩 모델 문장을 숫자 벡터로 변환
검색 인덱스 키워드·벡터 검색 구조
벡터 DB 벡터와 메타데이터 저장
Retriever 질문과 관련된 자료 검색
Reranker 검색 결과의 우선순위 재평가
LLM 검색자료를 바탕으로 답변 생성
업무 프로그램 질문 입력, 답변과 출처 표시

5. RAG의 전체 처리 과정

RAG는 크게 두 단계로 나뉩니다.

사전 준비 단계

문서를 읽어 검색할 수 있는 형태로 만드는 과정입니다.

 
 
 

질문 처리 단계

사용자의 질문과 관련된 자료를 검색하고 답변을 생성하는 과정입니다.

 
 
 

6. 1단계: 문서 수집

RAG 구축의 시작은 사용할 자료를 선정하는 것입니다.

사용할 수 있는 자료

  • PDF
  • Word
  • Excel
  • CSV
  • 텍스트 파일
  • Markdown
  • HTML
  • 이메일
  • 게시판
  • MariaDB 데이터
  • MES·ERP 업무 데이터
  • NAS 저장 문서
  • 이미지와 스캔 문서
  • 설비 매뉴얼
  • CAD 도면의 속성정보

문서 선정 기준

모든 파일을 무조건 등록하면 검색 품질이 오히려 떨어질 수 있습니다.

다음 기준을 적용하는 것이 좋습니다.

  • 현재 유효한 문서인가?
  • 승인된 문서인가?
  • 최신 개정본인가?
  • 검색할 가치가 있는가?
  • 중복 문서가 아닌가?
  • 개인정보가 포함돼 있는가?
  • 문서 접근권한이 정의돼 있는가?
  • 폐기문서가 아닌가?

RAG의 품질은 LLM보다 원본 데이터의 품질에 더 큰 영향을 받을 수 있습니다.


7. 2단계: 텍스트 추출

문서에 보이는 내용과 프로그램이 추출하는 텍스트는 다를 수 있습니다.

일반 PDF

텍스트가 포함된 PDF는 비교적 쉽게 추출할 수 있습니다.

스캔 PDF

스캐너로 만든 PDF는 각 페이지가 이미지이므로 OCR을 이용해 문자를 인식해야 합니다.

표가 많은 문서

표의 행과 열 관계가 깨지지 않도록 구조적으로 추출해야 합니다.

예를 들어 다음 표가 있습니다.

설비점검주기진동기준
프레스 1호기 1개월 4.5mm/s
프레스 2호기 2주 3.8mm/s

텍스트를 단순 추출하면 값과 설비 관계가 뒤섞일 수 있습니다. 다음과 같이 의미가 유지되도록 변환해야 합니다.

설비명: 프레스 1호기
점검주기: 1개월
진동기준: 4.5mm/s

설비명: 프레스 2호기
점검주기: 2주
진동기준: 3.8mm/s
 

머리말과 꼬리말 제거

모든 페이지에서 반복되는 회사명, 문서번호, 저작권과 페이지 번호는 검색을 방해할 수 있습니다.

반복 정보는 제거하거나 메타데이터로 분리하는 것이 좋습니다.


8. 3단계: 문서 정제

추출한 텍스트에서 불필요한 내용을 정리합니다.

정제 대상

  • 중복 문장
  • 반복되는 머리말과 꼬리말
  • 깨진 문자
  • 불필요한 공백
  • 메뉴와 광고
  • 의미 없는 페이지 번호
  • OCR 오류
  • 폐기된 내용
  • 숨겨진 개인정보

유지해야 할 구조

다음 정보는 삭제하지 말고 유지해야 합니다.

  • 문서 제목
  • 장과 절
  • 표 제목
  • 항목 번호
  • 개정번호
  • 시행일
  • 페이지
  • 작성·승인 정보
  • 설비번호
  • 품목코드
  • 공정코드

이 정보는 나중에 검색 필터와 출처 표시에 사용됩니다.


9. 4단계: Chunk란?

Chunk는 긴 문서를 검색하기 좋은 작은 단위로 나눈 조각입니다.

LLM에 문서 전체를 전달하면 다음 문제가 발생할 수 있습니다.

  • 입력 토큰 증가
  • 응답속도 저하
  • 비용 증가
  • 중요정보 누락
  • 관계없는 정보 포함
  • 컨텍스트 한도 초과

따라서 문서를 문단, 절, 표와 의미 단위로 나눕니다.


10. Chunk 크기가 중요한 이유

Chunk가 너무 작은 경우

이상 진동이 발생하면 설비를 정지한다.
 

문장은 간단하지만 어떤 설비인지, 누가 조치하는지, 다음 절차가 무엇인지 알기 어렵습니다.

Chunk가 너무 큰 경우

설비 매뉴얼 20페이지를 하나의 Chunk로 만들면 원하는 내용과 관계없는 정보가 너무 많이 포함됩니다.

적절한 Chunk

문서명: 프레스 설비 안전점검 기준
항목: 이상 진동 조치
대상: 프레스 2호기

진동값이 기준치를 초과하면 작업자는 즉시 설비를
정지한다. 주전원을 차단한 후 체결부와 베어링 상태를
점검하고 설비보전 담당자에게 보고한다.
 

검색에 필요한 문맥을 유지하면서 불필요하게 길지 않은 형태가 좋습니다.


11. Chunk 분할 방법

고정 길이 분할

글자 수나 토큰 수를 기준으로 나눕니다.

예:

  • 500자 단위
  • 1,000자 단위
  • 300토큰 단위
  • 500토큰 단위

구현이 간단하지만 문장이나 표가 중간에서 끊어질 수 있습니다.

문단 단위 분할

빈 줄과 문단을 기준으로 분리합니다.

일반 문서와 블로그에 적합합니다.

제목 구조 기반 분할

장, 절, 항목과 제목을 기준으로 분리합니다.

다음과 같은 업무문서에 적합합니다.

  • 작업표준서
  • 품질규정
  • 설비 매뉴얼
  • 사내 규정
  • 제품설명서

표 단위 분할

표 전체 또는 행 단위로 분리합니다.

표 제목과 열 제목을 각 Chunk에 반복해서 넣어야 의미가 유지됩니다.

의미 기반 분할

문장 간 의미 변화를 분석해 주제가 달라지는 지점에서 분리합니다.

성능은 좋을 수 있지만 처리과정이 복잡합니다.

효과적인 Chunk와 검색 전략은 RAG 검색의 오탐과 누락에 직접적인 영향을 줍니다. Microsoft RAG Chunking 가이드


12. Chunk Overlap이란?

Chunk를 나눌 때 앞뒤 내용을 일부 겹치게 만드는 방식입니다.

예를 들어 500토큰 단위로 나누면서 50토큰을 겹칠 수 있습니다.

Chunk 1: 1~500 토큰
Chunk 2: 451~950 토큰
Chunk 3: 901~1,400 토큰
 

Overlap을 적용하면 Chunk 경계에서 문맥이 끊기는 문제를 줄일 수 있습니다.

그러나 너무 많이 겹치면 다음 문제가 생깁니다.

  • 저장공간 증가
  • 중복 검색 결과 증가
  • 임베딩 처리량 증가
  • 동일한 답변 근거 반복

문서 구조가 잘 정리돼 있다면 고정 길이보다 제목과 문단 중심으로 나누는 것이 좋습니다.


13. 임베딩이란?

임베딩은 텍스트의 의미를 숫자 배열인 벡터로 변환하는 기술입니다.

예를 들어 다음 세 문장은 단어가 다르지만 의미가 비슷합니다.

  • 설비가 고장 났습니다.
  • 장비에 장애가 발생했습니다.
  • 기계가 정상적으로 작동하지 않습니다.

임베딩 모델은 이 문장들을 벡터 공간에서 가까운 위치에 배치합니다.

설비 고장       → [0.12, -0.31, 0.87, ...]
장비 장애       → [0.14, -0.29, 0.82, ...]
점심 식단       → [-0.74, 0.55, 0.03, ...]
 

임베딩 벡터는 사람이 직접 해석하기 위한 값이 아니라 컴퓨터가 문장 사이의 의미적 유사성을 비교하기 위한 값입니다.

Ollama는 임베딩을 생성해 벡터 DB에 저장하고 RAG 검색에 사용할 수 있습니다. Ollama 임베딩 문서


14. 임베딩 모델 선택

생성형 LLM과 임베딩 모델은 역할이 다릅니다.

구분역할
생성 모델 질문을 이해하고 답변 작성
임베딩 모델 문장을 벡터로 변환
Reranker 검색 결과의 관련성 재평가

Ollama 공식 문서에서는 다음 임베딩 모델을 예시로 안내합니다.

  • embeddinggemma
  • qwen3-embedding
  • all-minilm

한국어 업무문서를 사용한다면 다음 항목을 시험해야 합니다.

  • 한국어 의미검색 성능
  • 문서의 전문용어 인식
  • 모델 처리속도
  • 임베딩 벡터 크기
  • 최대 입력 길이
  • 상업적 이용 라이선스

문서를 등록할 때와 질문을 검색할 때는 반드시 같은 임베딩 모델과 동일한 설정을 사용해야 합니다.

임베딩 모델을 변경하면 기존 문서 벡터를 다시 생성하는 것이 원칙입니다.


15. 유사도 계산

질문 벡터와 문서 벡터가 얼마나 가까운지 계산해 관련 문서를 찾습니다.

대표적인 방식은 코사인 유사도입니다.

cosine⁡(A,B)=A⋅B∥A∥∥B∥\operatorname{cosine}(A,B) = \frac{A\cdot B}{\|A\|\|B\|}

쉽게 말하면 두 벡터가 얼마나 비슷한 방향을 가리키는지 계산합니다.

유사도가 높으면 의미가 비슷할 가능성이 큽니다.

다만 유사도 점수가 높다고 반드시 정답 문서인 것은 아닙니다. 임계값, 검색 개수, 필터와 Reranking을 함께 조정해야 합니다.


16. 벡터 데이터베이스란?

벡터 DB는 임베딩 벡터를 저장하고 유사한 벡터를 빠르게 찾는 데이터베이스입니다.

대표적인 선택지

제품특징
Qdrant 자체 구축, 필터검색, REST·gRPC
Chroma 소규모 Python RAG 시험
Milvus 대규모 벡터 검색
Weaviate 검색과 메타데이터 관리
pgvector PostgreSQL 확장
FAISS 라이브러리 기반 유사도 검색
Azure AI Search 클라우드 검색과 RAG

Qdrant는 벡터 유사도 검색과 일반 데이터베이스 형태의 메타데이터 필터를 결합할 수 있습니다. Qdrant 필터링 문서


17. 벡터 DB에 저장할 정보

벡터만 저장해서는 운영 가능한 RAG를 만들기 어렵습니다.

다음 메타데이터를 함께 저장해야 합니다.

ChunkID
회사코드
사업장코드
문서ID
문서번호
문서명
문서분류
개정번호
시행일
페이지
장·절 제목
Chunk 순서
Chunk 원문
보안등급
열람부서
문서상태
원본파일 위치
임베딩 모델 버전
등록일시
 

이러한 메타데이터를 이용하면 다음 조건으로 검색할 수 있습니다.

회사코드 = 현재 로그인 회사
문서상태 = 승인
폐기여부 = 아니오
시행일 <= 현재일
열람부서 = 사용자 소속부서
 

18. 키워드 검색과 벡터 검색

키워드 검색

질문에 포함된 단어와 같은 단어를 문서에서 찾습니다.

장점:

  • 품목코드 검색
  • 설비번호 검색
  • 정확한 용어 검색
  • 문서번호 검색

단점:

  • 동의어나 비슷한 표현 검색이 약함
  • 질문과 문서의 표현이 다르면 놓칠 수 있음

벡터 검색

문장의 의미가 비슷한 자료를 찾습니다.

장점:

  • 자연어 질문
  • 동의어 검색
  • 표현이 다른 문장 검색
  • 의미 중심 검색

단점:

  • 정확한 코드와 숫자 검색이 약할 수 있음
  • 의미가 비슷하지만 관련 없는 문서를 찾을 수 있음

19. Hybrid Search란?

Hybrid Search는 키워드 검색과 벡터 검색을 함께 사용하는 방식입니다.

예를 들어 다음 질문이 있습니다.

PRS-002 설비의 이상 진동 조치기준은?

  • PRS-002: 키워드 검색에 유리
  • 이상 진동 조치기준: 벡터 검색에 유리

두 검색 결과를 결합하면 정확한 설비번호와 의미적으로 관련된 조치내용을 함께 찾을 수 있습니다.

 
 
 

Qdrant도 의미 기반 벡터 검색과 BM25 등 어휘 기반 검색을 혼합하는 기능을 지원합니다. Qdrant 텍스트·하이브리드 검색

MES·ERP처럼 설비번호, 품목코드, LOT 번호가 중요한 시스템에서는 Hybrid Search가 유리합니다.


20. Metadata Filtering이란?

벡터 유사도가 높더라도 사용자가 볼 수 없는 문서라면 검색 결과에서 제외해야 합니다.

예를 들어 다음 조건을 먼저 적용합니다.

  • 현재 회사
  • 현재 사업장
  • 사용자 소속부서
  • 문서 보안등급
  • 승인된 최신 문서
  • 유효기간
  • 문서종류
  • 설비번호

그 안에서 벡터 유사도 검색을 수행합니다.

벡터 유사도 검색
+
회사코드 필터
+
사업장 필터
+
문서상태 필터
+
사용자 열람권한 필터
 

필터 대상 메타데이터에는 별도의 인덱스를 구성해야 대량 데이터에서도 성능을 유지할 수 있습니다. Qdrant 인덱싱 안내


21. Top-K란?

Top-K는 질문과 가장 유사한 문서 조각을 몇 개 가져올지 결정하는 값입니다.

예:

Top-K = 5
 

유사도가 높은 Chunk 다섯 개를 LLM에 전달한다는 의미입니다.

너무 적은 경우

정답에 필요한 자료를 놓칠 수 있습니다.

너무 많은 경우

관련 없는 자료까지 LLM에 전달돼 답변이 흐려질 수 있습니다.

따라서 다음 값을 비교시험해야 합니다.

  • Top-3
  • Top-5
  • Top-10
  • 임계값 이상만 선택
  • Reranking 후 Top-3 선택

단순히 많이 전달하는 것보다 관련성이 높은 소수의 자료를 전달하는 것이 좋을 수 있습니다.


22. Reranking이란?

1차 검색 결과를 더 정밀한 모델로 다시 평가해 순서를 조정하는 과정입니다.

1차 벡터 검색은 빠르지만 질문과 문서의 세밀한 관계를 완전히 판단하지 못할 수 있습니다.

예를 들어 벡터 검색에서 20개를 찾은 뒤 Reranker가 질문과 각 문서를 다시 비교해 최종 5개를 선택합니다.

벡터 검색 Top-20
→ Reranker 재평가
→ 최종 Top-5
→ LLM에 전달
 

Reranking은 검색 정확도를 높일 수 있지만 응답시간과 연산량이 증가합니다.


23. 프롬프트 구성

검색 결과를 LLM에 그대로 붙여 넣는 것만으로 좋은 RAG가 만들어지지는 않습니다.

LLM의 역할과 답변 규칙을 명확하게 지정해야 합니다.

당신은 eMES Lite의 설비관리 도우미입니다.

규칙:
1. 제공된 참고자료만 근거로 답변하세요.
2. 참고자료에 없는 내용을 사실처럼 만들지 마세요.
3. 답을 확인할 수 없으면
   "제공된 문서에서 확인할 수 없습니다"라고 답하세요.
4. 안전 관련 내용은 담당자 확인이 필요함을 표시하세요.
5. 답변 마지막에 문서명, 개정번호와 페이지를 표시하세요.
6. 서로 다른 문서 내용이 충돌하면 임의로 선택하지 말고
   충돌 사실을 알리세요.

[참고자료 1]
문서명: 프레스 설비 점검기준
개정번호: 3
페이지: 12
내용: ...

[참고자료 2]
문서명: 예방보전 업무표준
개정번호: 5
페이지: 7
내용: ...

[사용자 질문]
프레스 2호기에서 이상 진동이 발생하면
어떻게 조치해야 하나요?
 

24. 출처 표시는 어떻게 할까?

RAG 답변에는 반드시 원문을 확인할 수 있는 출처가 필요합니다.

권장 표시정보

  • 문서명
  • 문서번호
  • 개정번호
  • 페이지
  • 장·절
  • 원문 열기 링크
  • 적용일자

예:

이상 진동이 발생하면 즉시 설비를 정지하고
주전원을 차단한 후 체결부와 베어링을 점검해야 합니다.

참고자료
1. 프레스 설비 점검기준, PRS-Q-003, Rev.3, 12쪽
2. 예방보전 업무표준, MNT-S-002, Rev.5, 7쪽
 

LLM이 출처를 임의로 작성하지 않도록 실제 검색 결과의 메타데이터를 프로그램이 별도로 표시하는 것이 더 안전합니다.


25. RAG와 파인튜닝의 차이

RAG와 파인튜닝은 서로 대체하는 기술이 아니라 목적이 다릅니다.

구분RAG파인튜닝
주요 목적 외부 지식 제공 모델의 행동·표현 조정
최신정보 반영 문서 재등록 재학습 필요
출처 표시 가능 어려움
사내 문서 활용 매우 적합 대량 학습자료 필요
구축비용 비교적 낮음 상대적으로 높음
데이터 삭제 검색 인덱스 삭제 모델 내부 제거 어려움
답변 형식 학습 제한적 적합
업무 분류 학습 가능하지만 제한적 적합

RAG가 적합한 경우

  • 사내 문서를 찾아 답해야 함
  • 문서가 자주 개정됨
  • 출처 표시가 필요함
  • 최신정보가 중요함
  • 모델 재학습을 피하고 싶음

파인튜닝이 적합한 경우

  • 회사 고유의 답변 형식이 있음
  • 특정 분류 작업을 반복함
  • 전문적인 문체가 필요함
  • 도구 호출 형식을 안정화해야 함
  • 충분한 학습 예제가 있음

실무에서는 RAG와 파인튜닝을 함께 사용할 수도 있습니다.


26. RAG와 데이터베이스 조회의 차이

RAG가 모든 데이터 조회를 대신해서는 안 됩니다.

RAG가 적합한 데이터

  • 작업표준서
  • 설비 매뉴얼
  • 품질규정
  • 회의록
  • 보고서
  • 계약조건
  • 자연어 문서

SQL 조회가 적합한 데이터

  • 오늘 생산량
  • 현재 재고
  • 월별 매출액
  • 품목별 불량률
  • LOT 추적
  • 설비 가동시간
  • 작업지시 상태

예를 들어 사용자가 다음과 같이 질문합니다.

오늘 프레스 공정 생산량은 얼마인가요?

이 질문은 벡터 검색보다 MariaDB에서 SQL로 조회하는 것이 정확합니다.

 
 
 

MES용 AI에서는 RAG, SQL과 업무 API를 함께 사용해야 합니다.


27. 문서 변경과 재색인

RAG는 최초 등록뿐만 아니라 문서의 전체 생명주기를 관리해야 합니다.

신규 문서

  • 텍스트 추출
  • Chunk 생성
  • 임베딩 생성
  • 벡터 DB 등록

문서 개정

  • 구버전 검색 제외
  • 변경된 Chunk 재생성
  • 새로운 임베딩 등록
  • 개정번호와 시행일 갱신

문서 폐기

  • 검색 대상에서 즉시 제외
  • 필요하면 벡터 삭제
  • 감사 목적의 원본과 이력 보관

문서 권한 변경

  • 메타데이터 필터 갱신
  • 사용자 접근권한 즉시 반영

문서 내용이 같은데 파일명만 변경된 경우까지 고려해 해시값을 이용한 중복검사를 적용하는 것이 좋습니다.


28. RAG의 보안과 권한관리

RAG에서 가장 위험한 문제는 사용자가 볼 수 없는 문서 내용이 AI 답변에 포함되는 것입니다.

기본 원칙

LLM에 전달하기 전에 권한을 검사해야 합니다.

답변을 생성한 뒤 내용을 가리는 방식은 안전하지 않습니다. 검색 단계에서 접근할 수 없는 Chunk를 제외해야 합니다.

권장 처리 순서

로그인 사용자 확인
→ 회사·사업장 확인
→ 부서·직책·개인권한 확인
→ 문서 보안등급 확인
→ 접근 가능한 Chunk만 검색
→ LLM에 전달
→ 답변이력 저장
 

관리해야 할 보안정보

  • 사용자 ID
  • 부서
  • 직책
  • 문서함 권한
  • 문서 보안등급
  • 열람 가능 기간
  • 개인정보 포함 여부
  • 다운로드·출력 제한
  • 질문·답변 감사이력

29. RAG 정확성 평가

RAG는 답변이 자연스럽다는 이유만으로 성공했다고 판단해서는 안 됩니다.

평가는 검색과 답변을 나눠서 진행해야 합니다.

검색 평가

  • 정답 문서를 찾았는가?
  • 정답 Chunk가 Top-K 안에 포함됐는가?
  • 관계없는 문서가 너무 많이 검색됐는가?
  • 최신 개정본을 찾았는가?
  • 권한 없는 문서가 제외됐는가?

답변 평가

  • 검색자료에 근거했는가?
  • 질문에 직접 답했는가?
  • 필요한 내용이 빠지지 않았는가?
  • 잘못된 내용이 추가되지 않았는가?
  • 출처가 정확한가?
  • 모를 때 모른다고 답했는가?

RAG의 종합 평가지표로는 근거성, 완전성, 관련성, 정확성과 검색자료 활용성 등을 사용할 수 있습니다. Microsoft RAG 평가 안내


30. RAG 테스트 질문 구성

실제 사용자 질문을 기준으로 평가 세트를 만들어야 합니다.

직접 질문

프레스 2호기 진동 기준은 얼마인가요?

표현을 바꾼 질문

PRS-002 장비가 얼마나 흔들리면 정지해야 하나요?

여러 문서가 필요한 질문

이상 진동 발생 시 작업자와 보전담당자의 조치절차를 알려주세요.

답이 없는 질문

프레스 2호기의 2030년 교체계획을 알려주세요.

문서가 충돌하는 질문

프레스 2호기 점검주기는 2주인가요, 1개월인가요?

권한 테스트

생산부 사용자가 임원 전용 원가문서를 질문했을 때 검색과 답변에서 제외되는지 확인합니다.


31. RAG 실패 원인

원본 문서 품질이 낮음

OCR 오류나 깨진 표가 많으면 정확한 검색이 어렵습니다.

Chunk가 부적절함

정답 문장이 여러 Chunk로 잘려 있거나, 너무 많은 내용이 하나로 묶여 있을 수 있습니다.

임베딩 모델이 부적합함

한국어, 제조업 전문용어와 코드 검색 성능이 부족할 수 있습니다.

벡터 검색만 사용함

설비번호와 품목코드 같은 정확한 값은 놓칠 수 있습니다.

Top-K가 너무 크거나 작음

정답을 놓치거나 관련 없는 자료를 너무 많이 전달할 수 있습니다.

최신 문서관리가 안 됨

폐기된 구버전이 검색돼 잘못된 답변이 생성될 수 있습니다.

권한 필터가 없음

정보유출 위험이 발생합니다.

LLM이 출처 밖의 내용을 추가함

프롬프트 규칙과 답변 검증이 부족할 수 있습니다.


32. RAG 개선 방법

Query Rewriting

사용자의 짧거나 모호한 질문을 검색하기 좋은 형태로 변환합니다.

원래 질문:
진동 나면 어떻게 해?

변환 질문:
프레스 설비에서 이상 진동이 발생한 경우
설비 정지 및 점검 절차는 무엇인가?
 

Query Expansion

동의어와 관련용어를 추가합니다.

이상 진동
→ 흔들림, 진동 초과, 베어링 이상, 설비 떨림
 

Hybrid Search

키워드와 벡터 검색을 결합합니다.

Metadata Filter

회사, 사업장, 부서, 문서상태와 설비번호를 먼저 제한합니다.

Reranking

1차 검색 결과의 순위를 정밀하게 재평가합니다.

Parent-Child Retrieval

작은 Chunk로 정확하게 검색한 후 상위 문단이나 절을 함께 LLM에 제공합니다.

답변 검증

생성된 문장마다 검색 근거가 있는지 별도 모델이나 규칙으로 확인합니다.


33. RAG의 종류

Classic RAG

한 번 검색하고 한 번 답변을 생성합니다.

질문 → 검색 → 생성
 

구현이 간단해 첫 번째 RAG 프로젝트에 적합합니다.

Advanced RAG

다음 기능을 추가합니다.

  • 질문 재작성
  • Hybrid Search
  • Reranking
  • 메타데이터 필터
  • 결과 압축
  • 답변 검증

Agentic RAG

AI 에이전트가 질문을 분석해 필요한 검색도구를 스스로 선택합니다.

예:

사용자 질문
→ 설비 매뉴얼 검색
→ 고장이력 DB 조회
→ 제조사 웹자료 확인
→ 결과 비교
→ 최종 답변
 

Agentic RAG는 복잡한 질문에 유리하지만 응답시간, 비용과 통제 난이도가 증가합니다.

Graph RAG

문서뿐만 아니라 사람, 조직, 설비, 품목과 사건 사이의 관계를 그래프로 구성해 검색합니다.

예:

프레스 2호기
→ 사용 공정
→ 생산 품목
→ 발생 불량
→ 교체 부품
→ 담당 보전기사
 

여러 개체의 관계를 추적해야 하는 업무에 적합합니다.


34. Ollama를 이용한 RAG 구조

Ollama는 생성 모델과 임베딩 모델을 모두 로컬에서 실행할 수 있습니다.

예시 모델

 
ollama pull embeddinggemma
ollama pull qwen3.5:4b
 

역할 분리

embeddinggemma
- 문서 임베딩 생성
- 사용자 질문 임베딩 생성

qwen3.5:4b
- 검색 결과 이해
- 최종 답변 작성
 

API

임베딩 생성:

POST http://localhost:11434/api/embed
 

답변 생성:

POST http://localhost:11434/api/chat
 

35. MES Lite에 RAG 적용하기

적용 가능한 업무

생산관리

  • 작업지시서 검색
  • 공정별 작업방법 안내
  • 생산실적 설명
  • 납기지연 사유 정리

설비관리

  • 설비 매뉴얼 검색
  • 고장 증상별 점검방법
  • 예방보전 기준 안내
  • 과거 고장이력 요약

품질관리

  • 검사기준 검색
  • 불량유형별 조치
  • 시정조치 사례 검색
  • 고객 불만 관련 문서 확인

문서관리

  • 최신 작업표준서 검색
  • 문서 개정내용 비교
  • 규정 질의응답
  • 연관 문서 추천

36. MES Lite 권장 아키텍처

 
 
 

구성요소별 역할

구성요소역할
C# 프로그램 질문, 답변, 출처 화면
AI 업무 API 질문 분석과 전체 흐름 통제
MariaDB 조직·권한·문서·업무정보
NAS 원본 문서 저장
Qdrant 임베딩과 Chunk 검색
Ollama 임베딩·LLM 로컬 실행
감사로그 질문, 검색문서와 답변 기록

37. 단계별 구축 방법

1단계: 소규모 PoC

  • 업무영역 하나 선정
  • 문서 20~50개 준비
  • OCR과 텍스트 추출
  • 기본 Chunk 생성
  • 임베딩과 벡터 검색
  • 출처 포함 답변 구현

설비관리나 작업표준서 검색부터 시작하기 좋습니다.

2단계: 검색 품질 개선

  • 질문 평가 세트 작성
  • Chunk 크기 비교
  • 임베딩 모델 비교
  • Hybrid Search 적용
  • Reranking 검토

3단계: 권한과 문서이력 연동

  • 사용자 로그인 연동
  • 부서·직책별 권한
  • 최신 승인본만 검색
  • 폐기문서 제외
  • 질문·답변 이력 저장

4단계: 업무 DB 연결

  • 생산실적 SQL 조회
  • 설비 고장이력 조회
  • 품질실적 조회
  • RAG와 정형 데이터 결합

5단계: 운영 안정화

  • 동시 사용자 테스트
  • 장애와 백업
  • GPU 모니터링
  • 모델·프롬프트 버전관리
  • 정기적인 품질평가

38. RAG 구축 시 핵심 원칙

성공적인 RAG를 구축하려면 다음 원칙이 중요합니다.

  1. 원본 문서의 품질을 먼저 높입니다.
  2. 문서 구조에 맞게 Chunk를 나눕니다.
  3. 한국어와 전문용어에 적합한 임베딩을 선택합니다.
  4. 키워드와 벡터 검색을 함께 검토합니다.
  5. 최신 승인문서만 검색합니다.
  6. LLM 전달 전에 접근권한을 검사합니다.
  7. 답변에 원문 출처를 표시합니다.
  8. 답이 없으면 모른다고 답하게 합니다.
  9. 실제 사용자 질문으로 평가합니다.
  10. 중요한 결정은 담당자가 최종 확인합니다.

마무리

RAG는 단순히 LLM에 문서를 첨부하는 기술이 아닙니다.

좋은 RAG 시스템을 만들려면 다음 과정이 모두 필요합니다.

  • 문서 수집
  • 텍스트 추출
  • 문서 정제
  • Chunk 분할
  • 임베딩 생성
  • 벡터·키워드 검색
  • 권한 필터
  • Reranking
  • 프롬프트 구성
  • 답변과 출처 표시
  • 품질평가
  • 문서 개정관리

RAG의 가장 중요한 목적은 LLM이 아는 내용을 늘리는 데만 있지 않습니다.

필요한 자료를 정확하게 찾고,
허가된 자료만 사용하며,
근거를 확인할 수 있는 답변을 만드는 것

중소 제조업의 MES, ERP, 설비관리와 문서관리시스템에 RAG를 적용하면 회사의 축적된 문서와 경험을 자연어로 활용할 수 있습니다.

처음에는 작은 문서집합으로 시작하고, 검색 정확성과 권한관리를 확인한 뒤 단계적으로 확장하는 것이 가장 현실적인 구축 방법입니다.

조그만 기술로 세상을 이롭게

반응형