💡 지식 & 테크

외부 유출 없는 로컬 RAG 구축 가이드: Hugging Face 임베딩과 Chroma DB를 활용한 보안형 AI 지식베이스 실무

Local RAG Host

01. 완전 오프라인 RAG 지식베이스의 필요성과 보안적 가치

상용 API 기반 RAG 시스템은 높은 유연성을 갖추고 있으나, 정보 보안 관리 및 호출 비용의 우상향 제약으로부터 완전히 탈피하기 어렵습니다. 보안이 중요시되는 사내 위키독스나 기술 백서, 재무 수치와 같은 문서는 사내망 외부로 반출되는 것을 법적으로 방지해야 합니다. 이에 대비해 로컬 호스트 단독 혹은 로컬 네트워크 내부에 전용 임베딩 장치와 벡터 DB를 탑재하는 아키텍처는 내부 자산을 사전에 완벽히 차단해주는 튼튼한 방어선입니다.

02. 보안형 로컬 RAG 시스템의 핵심 아키텍처 흐름도

로컬 RAG 아키텍처는 데이터의 인입부터 최종 추론까지 모든 연산이 외부 네트워크 연결 없이 단일 서버망 내에서 폐쇄적으로 완결되도록 설계됩니다. RAG 파이프라인의 전체 데이터 흐름과 각 단계별 컴포넌트의 역할은 다음과 같습니다.

이 순환 구조의 모든 구성 요소는 외부 인터넷 환경과 격리된 상태에서 로컬 서버 단독 연산으로 구동되므로, 어떠한 형태의 지식 정보도 유출되지 않는 절대적 보안 상태를 완성합니다.

03. 로컬 임베딩 모델의 기술적 대조와 추천 가이드

RAG 시스템의 검색 성공 여부는 입력된 쿼리와 적재된 문서 사이의 의미적 유사성을 정확하게 판별해 내는 임베딩(Embedding) 성능에 달려 있습니다. 오픈소스 생태계에서 가장 널리 활용되는 한국어 및 다국어 지원 로컬 임베딩 모델들의 상세 스펙입니다.

3.1. Ollama Embeddings API와 Hugging Face Sentence-Transformers의 기술적 차이

Ollama API 방식은 별도의 라이브러리 의존성 추가 없이 기존 실행 중인 Ollama 백그라운드 서비스 포트(11434)에 HTTP POST 요청을 전송하여 즉각적인 임베딩 벡터를 반환받을 수 있어 아키텍처가 단순해지는 장점이 있습니다. 파이썬 가상환경의 복잡한 의존성 관리 오버헤드가 없고 백그라운드에서 오버레이 데몬으로 작동하므로 관리가 극도로 편합니다.

반면, Hugging Face 라이브러리 직접 구동 방식은 PyTorch 프레임워크와 직접 연계되므로 대용량 문서 배치(Batch) 인입 시 파이프라인의 멀티스레딩 성능이 극대화되고 모델 변경이 매우 자유롭다는 강점을 지닙니다. 특히 GPU VRAM 캐싱 기법이나 모델 추론 가속(TensorRT, ONNX 등) 기법을 코드 레이어에서 수동 제어할 수 있어 프로덕션 스케일의 RAG 엔진 빌드에는 Hugging Face sentence-transformers의 직접 활용이 훨씬 우수한 효율성을 보여줍니다. 대량의 사내 문서를 초기 색인할 때는 Hugging Face 로컬 연동 방식을 사용하고, 가벼운 쿼리 응답 시에는 Ollama 엔드포인트를 병행 연동하는 하이브리드 설계가 실무적으로 권장됩니다.

04. 오픈소스 벡터 데이터베이스(Vector DB) 비교 분석 및 HNSW 튜닝

임베딩 연산을 통해 추출된 고차원 벡터 데이터를 안정적으로 저장하고, 수만 개 이상의 벡터 풀 속에서 근사 최근접 이웃(ANN) 검색을 지원하기 위해 전용 벡터 데이터베이스가 활용됩니다.

4.1. Chroma DB의 로컬 SQLite 저장 원리와 HNSW 최적화 기법

Chroma DB는 내장 스토리지 백엔드로 SQLite를 사용하며, 내부 테이블 구조 속에 텍스트 데이터의 UUID, 매핑 메타데이터 키-값 정보, 그리고 실제 임베딩 벡터 가중치를 BLOB 바이너리 필드로 저장합니다. SQLite 파일 잠금 메커니즘을 사용하므로, 단일 가동 API 서버나 소규모 RAG 시스템에 가장 안정적인 지연 시간 효율을 보장합니다.

특히, 대규모 문서 검색 환경에서 정확도와 지연 시간의 트레이드오프 관계를 세부 튜닝하기 위해 Chroma DB 생성 시 HNSW 파라미터를 메타데이터 속성으로 주입해야 합니다.

• M (기본값 16): HNSW 그래프 구축 시 맺을 수 있는 최대 연결 링크 개수입니다. 클수록 고차원 벡터 검색 정확도가 올라가지만 메모리 사용량 and 인덱싱 시간이 증가합니다. 보통 1024차원의 bge-m3 모델을 사용할 경우 16에서 32 수준으로 설정하는 것이 안정적입니다.
• construction_ef (기본값 100): 인덱스 빌드 시 탐색하는 동적 후보군 크기입니다. 높이면 정확도가 올라가며 색인 속도는 현저히 느려집니다. 운영 환경에서는 초기 로딩 시 200 이상으로 늘려 빌드하는 것이 널리 권장됩니다.
• search_ef (기본값 100): 쿼리 입력 시 검색 대상 후보군 크기입니다. 런타임에 동적으로 조절 가능하며, 높일수록 검색 정확도가 높아지고 쿼리 지연시간이 증가합니다. 실시간 챗봇 수준에서는 100에서 150 사이의 값으로 튜닝해 지연 시간을 100ms 이내로 제어하는 것이 좋습니다.

05. 실전 Python 연동 엔지니어링: RAG 파이프라인 구현

Hugging Face의 임베딩 엔진과 Chroma DB, 그리고 로컬 Ollama LLM 서버를 연동하여 완전한 오프라인 질의응답을 구현하는 파이썬 코드 전문 가이드입니다. 본 코드에서는 HNSW 최적화 파라미터 설정 및 부모-자식 이중 청킹 기반의 Parent Document Retriever를 전격 통합하여 실무 환경에 바로 배포 가능한 코드를 제시합니다.

5.1. 필요 종속성 패키지 설치

로컬 RAG의 백엔드를 가동하기 위해 터미널 가상환경에서 아래의 패키지들을 설치해 줍니다. 2026년 기준 하이브리드 검색 및 크로스 인코더 결합을 위해 sentence-transformers 라이브러리가 필수적으로 사용됩니다.

pip install langchain langchain-community langchain-chroma chromadb sentence-transformers requests

5.2. 로컬 문서 적재, 부모-자식 이중 청킹 및 Chroma DB 벡터 데이터 적재 소스 코드

로컬 디렉토리 내 문서를 파싱하여 HNSW 최적화 메타데이터를 포함한 Chroma DB 및 부모-자식 관계형 색인 빌드 코드 전문입니다.

import os
from langchain_community.document_loaders import TextLoader
from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain_community.embeddings import HuggingFaceEmbeddings
from langchain_chroma import Chroma
from langchain.storage import InMemoryStore
from langchain.retrievers import ParentDocumentRetriever

def build_local_vector_db():
    # 1. 원본 문서 로드 (완전 오프라인 환경 가정)
    document_path = r"D:\AI\identities\blog\scratch\sample_knowledge.txt"
    if not os.path.exists(document_path):
        # 테스트용 임시 지식 문서 생성
        with open(document_path, "w", encoding="utf-8") as f:
            f.write("애플 실리콘 M3 Ultra 칩은 128GB의 통합 메모리(Unified Memory)를 지원하며, UltraFusion 아키텍처를 통해 최대 819 GB/s의 초고속 대역폭을 보장합니다.\n")
            f.write("Chroma DB는 SQLite to 파일 기반 영구 저장소로 활용하여 대용량 벡터 데이터를 매우 가볍고 직관적으로 보존해 주는 대표적인 오픈소스 벡터 데이터베이스입니다.\n")
            f.write("로컬 RAG 파이프라인 구축 시 임베딩 모델인 BAAI bge-m3는 1024차원의 밀도 높은 임베딩 벡터를 출력하여 한국어 문맥 매핑 능력이 대단히 뛰어납니다.\n")
        print(f"임시 지식 문서가 생성되었습니다: {document_path}")

    loader = TextLoader(document_path, encoding="utf-8")
    documents = loader.load()

    # 2. 로컬 임베딩 모델 정의 (BAAI/bge-m3)
    model_name = "BAAI/bge-m3"
    model_kwargs = {"device": "cpu"}
    encode_kwargs = {"normalize_embeddings": True}
    embeddings = HuggingFaceEmbeddings(
        model_name=model_name,
        model_kwargs=model_kwargs,
        encode_kwargs=encode_kwargs
    )

    # 3. Chroma DB HNSW 최적화 파라미터 구성
    hnsw_metadata = {
        "hnsw:space": "cosine",
        "hnsw:construction_ef": 200,
        "hnsw:M": 16
    }

    # 4. Chroma DB 및 Local Persistent 디렉토리 매핑 (HNSW 메타데이터 주입)
    persist_directory = r"D:\AI\identities\blog\scratch\chroma_db_storage"
    vector_db = Chroma(
        collection_name="local_rag_collection",
        embedding_function=embeddings,
        persist_directory=persist_directory,
        collection_metadata=hnsw_metadata
    )

    # 5. Parent Document Retriever (부모-자식 다중 청킹) 구성
    # 자식 청크(200자)로 디테일하게 검색하고, 부모 청크(1000자)로 주변 문맥을 확보해 LLM에 전달합니다.
    parent_splitter = RecursiveCharacterTextSplitter(chunk_size=1000, chunk_overlap=200)
    child_splitter = RecursiveCharacterTextSplitter(chunk_size=200, chunk_overlap=50)
    
    # 부모 문서를 저장할 Key-Value 로컬 저장소 (메모리 방식 활용)
    store = InMemoryStore()

    retriever = ParentDocumentRetriever(
        vectorstore=vector_db,
        docstore=store,
        child_splitter=child_splitter,
        parent_splitter=parent_splitter,
    )

    # 문서를 추가하여 부모-자식 관계형 색인 빌드
    retriever.add_documents(documents, ids=None)
    print(f"[SUCCESS] Chroma DB 및 Parent Document 색인 완료! 경로: {persist_directory}")

if __name__ == "__main__":
    build_local_vector_db()

5.3. RRF 하이브리드 검색 및 Cross-Encoder 리랭킹 결합 추론 소스 코드

EnsembleRetriever를 활용하여 Dense 및 Sparse 검색 결과를 RRF 융합한 후, 다국어 및 한국어 최적 리랭커인 BAAI/bge-reranker-v2-m3 모델로 2차 정밀 재점수화(Rerank)를 거쳐 Ollama 서버에 REST API로 전송하는 고도화 프로그램 코드 전문입니다.

import os
import requests
import json
from langchain_community.embeddings import HuggingFaceEmbeddings
from langchain_chroma import Chroma
from langchain_community.retrievers import BM25Retriever
from langchain.retrievers import EnsembleRetriever
from langchain_core.documents import Document
from sentence_transformers import CrossEncoder

def execute_advanced_hybrid_rag(user_query):
    # 1. 로컬 임베딩 모델 정의 (BAAI/bge-m3)
    model_name = "BAAI/bge-m3"
    model_kwargs = {"device": "cpu"}
    encode_kwargs = {"normalize_embeddings": True}
    embeddings = HuggingFaceEmbeddings(
        model_name=model_name,
        model_kwargs=model_kwargs,
        encode_kwargs=encode_kwargs
    )

    # 2. Chroma DB 로컬 스토어 로드
    persist_directory = r"D:\AI\identities\blog\scratch\chroma_db_storage"
    vector_db = Chroma(
        collection_name="local_rag_collection",
        persist_directory=persist_directory,
        embedding_function=embeddings
    )
    
    # 3. Dense Retriever 구성 (HNSW search_ef 최적화 적용)
    # 쿼리 시점 탐색 범위(search_ef)를 150으로 상향 조정하여 검색 품질 극대화
    dense_retriever = vector_db.as_retriever(
        search_type="similarity",
        search_kwargs={
            "k": 5,
            "search_ef": 150
        }
    )

    # 4. Sparse Retriever (BM25) 구성을 위해 Chroma 적재 데이터 파싱
    db_data = vector_db.get()
    documents = []
    
    if db_data and "documents" in db_data:
        for text, meta in zip(db_data["documents"], db_data["metadatas"]):
            documents.append(Document(page_content=text, metadata=meta))
            
    if not documents:
        print("로컬 지식베이스에 데이터가 존재하지 않습니다. 먼저 document_loader를 실행하세요.")
        return
        
    sparse_retriever = BM25Retriever.from_documents(documents)
    sparse_retriever.k = 5

    # 5. EnsembleRetriever를 활용한 하이브리드 검색 및 RRF(Reciprocal Rank Fusion) 수행
    # Dense 벡터 유사도에 0.7, Sparse 키워드에 0.3의 가중치를 둡니다.
    ensemble_retriever = EnsembleRetriever(
        retrievers=[sparse_retriever, dense_retriever],
        weights=[0.3, 0.7]
    )
    
    initial_docs = ensemble_retriever.invoke(user_query)
    
    # 6. Cross-Encoder 리랭킹(Reranking)을 통한 최상위 컨텍스트 재정렬
    # 한국어/다국어 리랭킹 최신 표준인 BAAI/bge-reranker-v2-m3 모델을 활용해 정밀 재연산합니다.
    reranker_model = "BAAI/bge-reranker-v2-m3"
    reranker = CrossEncoder(reranker_model, device="cpu")
    
    pairs = [[user_query, doc.page_content] for doc in initial_docs]
    scores = reranker.predict(pairs)
    
    # 스코어 기준 역정렬 및 상위 2개 추출
    scored_docs = sorted(zip(scores, initial_docs), key=lambda x: x[0], reverse=True)
    final_docs = [doc for score, doc in scored_docs[:2]]
    
    # 7. 컨텍스트 조립
    context_parts = []
    for i, doc in enumerate(final_docs):
        context_parts.append(f"[참조 {i+1}]: {doc.page_content}")
    context = "\n".join(context_parts)
    
    print("\n--- [RRF + BGE Reranker v2 M3 추출 컨텍스트] ---")
    print(context)
    print("---------------------------------------\n")

    # 8. 로컬 Ollama API 서버용 시스템 프롬프트 조립
    system_prompt = (
        "당신은 사내 지식 기반 보안 AI 비서입니다. 제공된 [참조] 데이터만을 엄격히 근거하여 사실에 기반해 답변하세요.\n"
        "참조 데이터에 없는 내용은 절대 지어내어 답변(환각)하지 마십시오.\n\n"
        f"[사내 참조 지식]\n{context}"
    )

    # 9. P105 Nginx 보안 리버스 프록시 우회 API 호출
    ollama_api_url = "http://local-ai-server.lan/api/chat"
    auth_credentials = ("tippickouser", "my_secret_password")
    
    payload = {
        "model": "llama3:8b",
        "messages": [
            {"role": "system", "content": system_prompt},
            {"role": "user", "content": user_query}
        ],
        "stream": False
    }

    try:
        response = requests.post(
            ollama_api_url,
            auth=auth_credentials,
            json=payload,
            timeout=30
        )
        
        if response.status_code == 200:
            response_json = response.json()
            answer = response_json.get("message", {}).get("content", "")
            print("[로컬 RAG 최종 보안 답변]")
            print(answer)
        else:
            print(f"Ollama API 서버 에러 코드: {response.status_code}")
            
    except requests.exceptions.RequestException as e:
        print(f"로컬 서버 통신 실패: {e}")

if __name__ == "__main__":
    query = "M3 Ultra 칩셋의 대역폭과 지원 용량은 어떻게 되나요?"
    execute_advanced_hybrid_rag(query)

06. 로컬 RAG 검색 품질 고도화 핵심 실무 팁

완전 오프라인 RAG 시스템을 실무에 적용하여 현장 가용성을 높이기 위해서는 다음과 같은 파라미터 미세 조정 규칙이 성립되어야 합니다.

6.1. 부모-자식 이중 청킹(Parent Document Retrieval)의 물리적 비율

단순 단일 청킹 방식에서는 문맥 상실을 막기 위해 500자 이상의 청크를 사용하지만, 이는 임베딩 모델의 초점을 분산시킵니다. 텍스트 길이가 길어질수록 모델이 단락 내에서 가장 지배적인 키워드나 뉘앙스 정보에만 반응하고, 경계면에 적힌 미묘한 설명들을 벡터 공간에 충분히 압축하지 못하기 때문입니다.

효율적인 아키텍처에서는 검색 정밀도를 위한 자식 청크(150~250자)와 컨텍스트 보존을 위한 부모 청크(800~1200자)로 나누는 것입니다. 자식 청크의 임베딩 벡터로 HNSW 검색을 수행하여 신속하게 매칭 위치를 확보한 뒤, LLM 프롬프트에는 자식 청크가 가리키는 부모 청크를 로드함으로써, LLM이 문단의 시작과 끝맥락을 완벽하게 파악하도록 돕습니다. 이를 통해 검색 단계의 초점 일치와 생성 단계의 문맥 유실 방지라는 두 가지 장점을 동시에 얻게 됩니다.

6.2. Reciprocal Rank Fusion (RRF)의 조화 평균 연산

하이브리드 검색 시 Dense 유사도 점수와 Sparse 키워드 점수는 값의 분포가 완전히 달라 단순 선형 병합이 어렵습니다. Dense 점수는 보통 코사인 유사도 기반으로 0과 1 사이에 오밀조밀하게 뭉쳐있으며, Sparse(BM25) 점수는 문서 전체 어휘 빈도에 따라 0점부터 수십 점까지 발산하기 때문입니다. RRF는 각 검색기에서 도출한 순위의 역수를 더해 순위를 재결정함으로써 이 문제를 근본적으로 해결합니다.

RRF Score = 1 / (60 + Dense_Rank) + 1 / (60 + Sparse_Rank)

이 수식을 통하면 절대적인 점수 편차에 구애받지 않고, 양쪽 리트리버에서 고르게 상위에 랭크된 고신뢰 문서가 안정적으로 상위권으로 밀어 올려집니다. 이 조합에 BGE Reranker v2 M3 모델을 연계함으로써 검색 성능의 정점을 찍을 수 있습니다.

6.3. BGE-Reranker-v2-m3 적용을 통한 2차 검증 수칙

유사도 검색(Bi-Encoder 방식)은 질문 벡터와 문서 벡터 간의 단순 거리 계산이므로 연산이 매우 빠르지만 문맥적 상관도를 디테일하게 검증하지 못합니다. 단어나 조사 수준의 세밀한 교차 분석 대신, 독립적으로 사상된 벡터 공간 상의 최단거리 벡터군만 긁어모으기 때문입니다.

이러한 한계를 보완하기 위해 1차 검색된 후보 문서군(K=5~10)을 질문과 하나의 문장 쌍으로 묶어 Cross-Encoder 모델인 BGE-Reranker-v2-m3에 입력해야 합니다. 이 모델은 어텐션(Attention)을 완전히 융합하여 교차 평가하므로 훨씬 정확한 정밀 매치 스코어를 산출합니다. 로컬 RAG 백엔드에 리랭커 모델을 하나 더 연동해 두면 RAG의 검색 신뢰도가 수십 %포인트 이상 수직 상승하는 보상이 따릅니다.

07. 쿼리 변환 고급 기법: HyDE와 Multi-Query Retrieval

하이브리드 검색(Hybrid Search)과 리랭커(Reranker) 조합만으로는 해결하기 어려운 영역이 하나 있습니다. 사용자의 질문이 지나치게 짧거나 구어체에 가까울 때, 질문 벡터 자체가 내부 문서의 벡터 공간과 시맨틱 갭(semantic gap)을 형성하는 문제입니다. 이 갭을 근본적으로 좁히는 방법이 쿼리 변환(Query Transformation) 기법군이며, 2025년 프로덕션 RAG 파이프라인의 업계 표준으로 자리 잡고 있습니다.

7.1. HyDE (Hypothetical Document Embeddings)

HyDE는 사용자의 짧은 질문을 그대로 임베딩하지 않고, 로컬 LLM(Ollama)에 먼저 질문을 투입하여 가상(Hypothetical)의 답변 단락을 한 단계 생성합니다. 그리고 그 가상 답변 텍스트를 실제 검색 쿼리의 임베딩으로 사용합니다. 핵심 원리는 가상 답변이 실제 문서 코퍼스와 동일한 어휘, 도메인 용어, 문체를 공유한다는 점에 있습니다. 따라서 질문 벡터와 문서 벡터 간 표현 공간이 정렬되어 코사인 유사도 기반 ANN 검색에서 훨씬 강력한 결과가 도출됩니다.

# HyDE 구현 예시 (LangChain + Ollama 조합)
from langchain.chains import HypotheticalDocumentEmbedder
from langchain_community.llms import Ollama
from langchain_huggingface import HuggingFaceEmbeddings

# 1. 기반 임베딩 (로컬 bge-m3)
base_embeddings = HuggingFaceEmbeddings(
    model_name="BAAI/bge-m3",
    model_kwargs={"device": "cuda"}
)

# 2. 로컬 Ollama LLM 설정
ollama_llm = Ollama(model="llama3:8b", base_url="http://localhost:11434")

# 3. HyDE 임베딩 레이어 조립
hyde_embeddings = HypotheticalDocumentEmbedder.from_llm(
    llm=ollama_llm,
    base_embeddings=base_embeddings,
    custom_prompt="다음 질문에 대한 전문적인 기술 답변 단락을 작성하세요:
{question}"
)

# 4. 기존 Chroma DB 벡터스토어에 HyDE 임베딩으로 쿼리
results = vectorstore.similarity_search_by_vector(
    hyde_embeddings.embed_query("M3 Ultra 칩의 메모리 대역폭은?"),
    k=5
)
print(f"HyDE 검색 결과 {len(results)}개 반환")

로컬 구성의 장점은 가상 답변 생성 LLM 역시 Ollama 로컬 인스턴스를 그대로 재활용한다는 점입니다. 따라서 기존 오프라인 파이프라인 구조를 유지하면서도 HyDE 레이어를 단순히 임베딩 모듈 위에 얹는 형태로 통합이 가능합니다. Luyu Gao 외(2022)의 원 논문(arXiv:2212.10496)에서는 HyDE가 BM25, Dense Retrieval 단독 대비 다양한 오픈 도메인 QA 벤치마크에서 일관적으로 상위 정밀도를 기록했음을 보고하고 있습니다.

7.2. Multi-Query Retrieval과 쿼리 확장(Query Expansion)

하나의 사용자 질문에는 미처 표현되지 않은 의도가 숨어 있는 경우가 많습니다. Multi-Query Retrieval은 로컬 LLM을 활용하여 원본 질문에서 다양한 관점의 파생 쿼리(Sub-Query)를 복수 생성하고, 각각의 쿼리로 독립적인 벡터 검색을 병렬 수행합니다. 그 결과 집합들을 RRF로 재병합하여 단일 쿼리에서는 포착되지 않았을 다양한 각도의 관련 문서를 확보합니다.

# Multi-Query Retrieval 구현 예시
from langchain.retrievers.multi_query import MultiQueryRetriever
from langchain_community.llms import Ollama
from langchain_community.vectorstores import Chroma
from langchain_huggingface import HuggingFaceEmbeddings
import logging

logging.basicConfig()
logging.getLogger("langchain.retrievers.multi_query").setLevel(logging.INFO)

# 기반 retriever (Chroma + bge-m3)
embeddings = HuggingFaceEmbeddings(model_name="BAAI/bge-m3", model_kwargs={"device": "cuda"})
vectorstore = Chroma(
    persist_directory="D:/ai_knowledge_base/chroma_store",
    embedding_function=embeddings,
    collection_name="corp_docs_v2"
)
base_retriever = vectorstore.as_retriever(search_kwargs={"k": 5})

# 파생 쿼리 생성 LLM (로컬 Ollama)
llm = Ollama(model="llama3:8b", base_url="http://localhost:11434")

# Multi-Query 리트리버: 원본 쿼리에서 3개 파생 쿼리 자동 생성
multi_query_retriever = MultiQueryRetriever.from_llm(
    retriever=base_retriever,
    llm=llm,
    prompt_template="원본 질문을 다양한 관점에서 3가지 다른 방식으로 표현하세요:
원본: {question}
"
)

# 실행: 내부적으로 3개 쿼리 생성 → 병렬 검색 → 중복 제거 및 병합
unique_docs = multi_query_retriever.get_relevant_documents(
    "M3 Ultra 칩의 메모리 대역폭과 NPU 처리 능력에 대해 알려줘"
)
print(f"Multi-Query 결과 고유 문서: {len(unique_docs)}개")

Multi-Query와 HyDE는 상호 배타적이지 않습니다. 실제 프로덕션 환경에서는 두 기법을 파이프라인 체인으로 조합하는 경우가 증가하고 있습니다. 즉, 사용자의 원본 쿼리를 먼저 HyDE로 확장하여 풍부한 시맨틱 벡터를 생성하고, 그 확장 쿼리를 다시 Multi-Query로 3~5개의 파생 쿼리로 분기하여 검색 폭을 넓힌 뒤 RRF로 재병합하는 전략입니다. Reciprocal Rank Fusion 60 상수가 각 검색기의 절대 점수 편차를 정규화해 주므로, 파생 쿼리별로 점수 스케일이 다르더라도 안정적으로 최우선 관련 문서를 상위에 배치할 수 있습니다.

08. RAGAS 기반 로컬 RAG 품질 평가 체계

RAG 파이프라인을 구축한 이후 가장 흔하게 직면하는 문제는 “이 시스템이 실제로 잘 작동하고 있는가?”에 대한 정량적 근거를 확보하기 어렵다는 점입니다. 정성적인 인상 평가나 단순 히트율 통계는 시스템의 실제 품질을 오도하기 쉽습니다. 이를 해결하기 위해 등장한 오픈소스 평가 프레임워크가 RAGAS(Retrieval-Augmented Generation Assessment Suite)입니다.

RAGAS는 RAG 파이프라인의 두 핵심 단계인 검색(Retrieval)과 생성(Generation)을 독립적으로 평가하는 4가지 주요 메트릭을 제공합니다. 각 메트릭은 0에서 1 사이의 정규화된 스코어로 표현되므로, 시간에 따른 성능 트렌드 추적이나 A/B 테스트 비교가 즉시 가능합니다.

8.1. LLM-as-a-Judge 방식의 자동화 평가

RAGAS의 가장 중요한 특징은 BLEU/ROUGE 같은 단순 토큰 매칭 대신 LLM-as-a-Judge 패러다임을 채택한다는 점입니다. 고품질의 평가용 LLM(또는 로컬 환경에서는 Ollama 모델)이 답변의 사실 일관성과 질문 관련성을 구조화된 프롬프트로 평가하므로, 인간의 직관에 훨씬 근접한 뉘앙스 있는 스코어를 산출합니다. 이를 CI/CD 파이프라인에 통합하면 임베딩 모델 교체나 청킹 전략 변경 시 자동으로 품질 회귀(Regression)를 감지하는 지속적 품질 보증(CQA) 체계를 구축할 수 있습니다.

# RAGAS 로컬 평가 파이프라인 구현
from ragas import evaluate
from ragas.metrics import faithfulness, answer_relevancy, context_precision, context_recall
from datasets import Dataset
from langchain_community.llms import Ollama

# 평가 데이터셋 구성 (질문, 실제 답변, 검색된 컨텍스트)
eval_data = {
    "question": [
        "M3 Ultra 칩셋의 메모리 대역폭은 얼마인가요?",
        "KoSimCSE 임베딩 모델은 어떤 학습 방식을 사용하나요?"
    ],
    "answer": [
        "M3 Ultra 칩셋은 800GB/s의 메모리 대역폭을 제공합니다.",
        "KoSimCSE는 SimCSE 기법의 한국어 특화 버전으로, 대조 학습을 사용합니다."
    ],
    "contexts": [
        ["M3 Ultra는 Apple Silicon 최고봉 칩으로 800GB/s 대역폭과 192GB 통합 메모리를 지원합니다."],
        ["KoSimCSE는 SimCSE의 한국어 버전으로, Positive/Negative 쌍 대조 학습으로 한국어 의미 유사도를 학습합니다."]
    ],
    "ground_truth": [
        "M3 Ultra 칩의 메모리 대역폭은 800GB/s입니다.",
        "KoSimCSE는 대조 학습 기반으로 한국어 임베딩을 생성합니다."
    ]
}

# Ollama 기반 로컬 평가 LLM 설정 (오프라인 평가 가능)
local_llm = Ollama(model="llama3:8b", base_url="http://localhost:11434")

# RAGAS 4대 메트릭 평가 실행
dataset = Dataset.from_dict(eval_data)
result = evaluate(
    dataset=dataset,
    metrics=[faithfulness, answer_relevancy, context_precision, context_recall],
    llm=local_llm
)

print("=== RAGAS 로컬 RAG 품질 평가 결과 ===")
print(result.to_pandas().to_string())

8.2. 메트릭 진단에 따른 실무 튜닝 전략

RAGAS 메트릭은 단순 점수 제공을 넘어 진단 도구로서의 가치가 더 큽니다. Context Precision이 낮으면 리랭커 품질이나 Top-K 설정을 먼저 의심해야 합니다. Context Recall이 낮으면 청킹 전략의 문제(너무 작은 청크, 부적절한 분리 기준)이거나 Multi-Query나 HyDE 같은 쿼리 변환 기법의 부재가 원인일 가능성이 높습니다. Faithfulness가 낮다면 LLM이 컨텍스트를 무시하고 파라메트릭 지식(사전학습 기억)으로 답변을 생성하는 것이므로, 시스템 프롬프트에 “제공된 컨텍스트만을 엄격히 근거하라”는 지시를 강화하거나 더 지시 순응도가 높은 모델로 교체를 고려해야 합니다.

09. 결론 및 로컬 RAG 보안 가이드라인

로컬 임베딩 모델 bge-m3와 로컬 파일 기반 벡터 스토어 Chroma DB의 결합은 사내 문서의 단 한 글자도 외부 클라우드로 누출하지 않는 기밀성 최고의 인프라 아키텍처를 영위하게 해 줍니다. RAG 서버를 구축한 이후에는 서버 자체의 로컬 스토리지 볼륨 권한을 특정 인가된 프로세스만 접근 가능하도록 OS 파일 보안 권한을 제한하는 것이 유용합니다. 나아가 신규 파일의 주기적 동기화 처리를 위해 크론탭(Crontab)이나 백그라운드 파일 스캐너를 매핑해 둠으로써 항상 신선하고 안전한 오프라인 지식베이스 파이프라인을 유지해 보시기 바랍니다. 본 가이드에서 소개한 Parent-Child 이중 청킹, HNSW 파라미터 튜닝, RRF 기반 하이브리드 검색, BGE-Reranker 2차 정밀 검증, HyDE 시맨틱 갭 해소, Multi-Query 쿼리 확장, RAGAS 품질 평가에 이르는 7계층 고도화 스택을 단계적으로 도입하면, 엔터프라이즈급 로컬 RAG 파이프라인의 검색 정밀도와 답변 신뢰도를 최상위 수준으로 끌어올릴 수 있습니다.