RUNNING COREKIT RAG PLATFORM

CoreKit RAG 플랫폼

문서를 올리면 자동으로 분석·색인하고, 자연어 질문에 원문 페이지 출처와 함께 답하는 RAG 플랫폼.
엔진(API)과 웹 서비스를 모두 자체 개발해 운영 중입니다.

FastAPI LangChain ChromaDB OpenAI React 19 TypeScript PostgreSQL AWS S3 Docker
PROBLEM

이 시스템이 해결하는 문제

BEFORE

방대한 문서에서 답을 못 찾는다

매뉴얼 수백 페이지를 사람이 직접 뒤져야 했다. 키워드 검색으로는 문맥을 파악하기 어렵고, 찾아도 맞는지 확인이 안 됐다.

AFTER

자연어로 질문하면 관련 구절을 찾아 AI가 답변을 생성하고, 원본 PDF의 페이지 번호(page_start~page_end)까지 함께 제시한다.

BEFORE

AI 답변을 믿기 어렵다

LLM은 근거 없이 그럴듯한 답을 만들어낸다. 문서에 없는 내용을 답변으로 내놓아도 사용자가 알 수 없다.

AFTER

유사도 문턱값 필터링, 근거 전용 프롬프트, 근거 부족 시 경고 반환, 답변·출처 구조 분리 — 4중 할루시네이션 필터로 통제한다.

BEFORE

RAG를 서비스마다 새로 만든다

여러 시스템이 각자 RAG를 구축하면 중복 비용이 크다. 임베딩·벡터 저장·LLM 호출 로직을 팀마다 따로 만들고 관리한다.

AFTER

클라이언트별 API 키 발급·차등 rate limit·웹훅 통지를 갖춘 공용 RAG 엔진. 외부 시스템은 API 연동만으로 문서 질의응답 기능을 탑재한다.

ARCHITECTURE

두뇌와 서비스 계층

두 저장소가 역할을 나눠 하나의 플랫폼을 구성한다. RAG 엔진이 "두뇌"(벡터 검색·LLM), 웹 서비스가 "서비스 계층"(인증·저장·운영·UX).

책임 영역 corekit-rag-web (서비스 계층) corekit-rag (RAG 엔진)
사용자 인증·권한 JWT + httpOnly 쿠키, ADMIN/USER 역할
파일 저장 S3 업로드, 메타데이터 DB 관리
인덱싱 처리 요청 + 상태 추적 + 웹훅 수신 PDF 파싱, 청킹, 임베딩, 벡터 저장
검색 질의 변환, 결과 enrichment, 검색 로그 벡터 검색, LLM 답변 생성, exam 분석
UI / 운영 전 화면, 관리자 패널, 이력·통계, 에러 로깅

DOCUMENT PIPELINE

ENGINEERING

기술적으로 내세울 것들

개발자 관점에서 설계가 까다로웠던 지점들.

01
이중 청킹(dual-granularity) 검색
동일 문서를 2,000자(topic)와 500자(keyword) 두 해상도로 인덱싱한다. 맥락형 검색과 정밀 매칭을 용도별로 선택·병합할 수 있다. exam 모드에서는 두 컬렉션을 동시 검색한 뒤 (doc_id, 페이지) 기준으로 중복 제거·거리순 병합해 재현율과 정밀도를 동시에 확보한다.
"sources": [{ "page_start": 12, "page_end": 13, "similarity": 0.87 }]
02
페이지 단위 출처 추적
청킹 시 문자 오프셋→페이지 매핑을 유지한다. 모든 답변 근거에 원본 PDF 페이지 범위를 제시해 검증 가능성(verifiability)을 확보한다. 웹 서비스에서는 Presigned URL에 #page=N fragment를 더해 원문의 정확한 페이지로 바로 이동한다.
03
4중 할루시네이션 필터
① 유사도 0.5 미만 제외 ② "검색된 내용에 없는 정보는 추측하지 말라"는 엄격 프롬프트 ③ 근거 부족 시 명시적 경고(warning) + 낮은 confidence 반환 ④ 문서 답변·웹 보충 답변 분리 제공. 환각 억제 장치를 파이프라인 전반에 내장했다.
04
AI 쿼리 정제 전처리
구어체 질문·시험 문제를 LLM이 JSON mode로 검색 친화적 기술 용어 쿼리로 변환한 뒤 벡터 검색을 수행한다. 일반 사용자 질문의 검색 품질을 개선하는 전처리 단계다. 브라우저 내 OCR(tesseract.js, 한+영)로 이미지 시험 문제도 서버 전송 없이 처리한다.
05
운영 안정성 설계
OpenAI 호출 지수 재시도, 100건 배치 임베딩, 작업 세마포어(TPM 한도 대응), 좀비 작업 자동 감지(5분 주기), graceful shutdown(진행 중 작업 완료 대기), 3중 동기화 인메모리 캐시, 검색 결과 캐시(TTL 30분). 각 단계에서 장애와 비용을 고려한 설계다.
검색 캐시 최대 1,000건 · TTL 30분 임베딩 배치 100건 · 재시도 3회 웹훅 재시도 1s → 5s → 30s
06
멀티테넌트 + 동적 폼 스키마
클라이언트별 API 키(SHA-256 해시만 저장), 차등 rate limit(기본 100/분), 웹훅 설정을 분리 관리한다. 웹 서비스에서는 문서유형별 메타데이터 필드(SELECT/TEXT/NUMBER/DATE)를 관리자가 정의하면 업로드 폼·검색 필터가 자동 생성된다.
Python 3.11 FastAPI LangChain 0.3 ChromaDB OpenAI React 19 TypeScript TanStack Query Vite PostgreSQL SQLAlchemy 2.0 AWS S3 Docker tesseract.js pdfjs-dist