Rag

사용자가 자연어 질의를 입력한 뒤 최종 답변을 받을 때까지 각 컴포넌트가 어떤 순서로 동작하는지 정리한 글입니다. 이 글은 시리즈의 첫 글입니다. 각 구성 요소를 왜 그렇게 선택했는지, 실험 과정에서 무엇이 달라졌는지는 이어지는 글에서 다룹니다. 단일 NL2SQL의 한계와 라우팅 구조 NL2SQL을 실운영 환경에 처음 적용하면 같은 문제를 반복해서 만납니다. DDL만으로는 T_CUST_MST 같은 약어 테이블이 무슨 의미인지, “순매출"이 어떤 산식인지 LLM이 파악·추론하지 못합니다. 공개 벤치마크가 아무리 올라가도 실제 엔터프라이즈 환경에서는 정확도가 절반 이하라는 보고가 꾸준히 나옵니다. 같은 종류의 오답은 데이터셋을 바꿔도 사라지지 않습니다. ...

기업 문서에서 표와 그래픽 요소를 정밀하게 추출하고 파싱하여 RAG 및 LLM 파이프라인의 검색 정확도를 극대화하는 실행 전략을 다룹니다.

Vector DB 없이 긴 문서의 맥락을 분석하고 파편화된 파일을 연결된 위키 형태로 지식화하는 오픈소스 OpenKB를 소개합니다.

벡터 DB와 Reranking을 무작정 도입하기보다 BM25와 질의 재작성 조합부터 시작해 데이터 조건에 따라 6단계로 검색 아키텍처를 점진적으로 확장하는 방안을 정리합니다.

공공기관 및 규제 산업에서 RAG와 LLM을 도입할 때 외부 API 없이 한국어 문서의 개인정보 33종을 로컬에서 탐지하고 가명화하는 Python 라이브러리 ko-pii를 소개합니다.

마이크로소프트가 제공하는 무료 온톨로지 학습 및 실습 플랫폼인 Ontology Playground를 소개하며, 대화형 그래프와 RDF 파일 변환 기능을 활용하는 방법을 다룹니다.

PostgreSQL과 pgvector를 기반으로 RAG 파이프라인, 에이전트 워크플로우, MCP 도구를 통합 제공하는 오픈소스 에이전트 플랫폼 MaxKB를 소개합니다.

LLM 에이전트의 답변 정확도를 높이기 위해 비정형 데이터를 구조화된 위키 형태로 변환하고 관리하는 LLM Wiki 구축 전략을 소개합니다.

결정론적 시스템에서 확률론적 시스템으로 전환되는 시대에 AI PM이 갖춰야 할 세 가지 새로운 역량과 이를 증명할 실무 포트폴리오 구성 방법을 공유합니다.

데이터 유출 걱정 없는 로컬 오픈소스 메모리 시스템 MemPalace를 소개합니다. 평면적 벡터 검색의 한계를 넘어선 계층적 데이터 관리 방식을 다룹니다.

Databricks AI Search에서 Nori 미지원 문제를 해결하기 위해 Kiwi 형태소 분석기를 도입했습니다. 색인 전 토큰화와 동의어 확장으로 한국어 BM25 검색 성능을 높인 과정을 다룹니다.

AI 에이전트가 로컬 파일을 검색할 때 발생하는 심각한 토큰 낭비와 지연 시간을 해결하고자, 벡터 DB 없이 결정론적 파일 지도와 LLM Wiki를 활용하는 오픈소스 Jikji의 효율적인 탐색 구조를 분석합니다.

소크라테스식 질문과 다중 에이전트 협업으로 검색 쿼리를 풍부하게 확장하고 검색 성능을 개선하는 프레임워크 AMD를 소개합니다.

구글 리서치가 발표한 Agentic RAG의 핵심인 Sufficient Context Agent의 동작 방식과 FramesQA 벤치마크 성능 평가 결과를 분석합니다.

모든 문서에 동일한 청킹을 적용하는 한계를 극복하고, 5가지 내재적 평가 지표로 문서마다 최적의 청킹 전략을 자동 선택하는 Adaptive Chunking 프레임워크를 소개합니다.

사전 지식 그래프를 구축하지 않고 질문 시점에 논리 구조를 동적으로 생성하는 LogicRAG의 작동 원리와 효율성을 다룹니다.

실무 문서의 핵심인 표와 차트를 정교하게 분석하는 기술을 살펴봅니다. 이중 그래프 구조로 데이터 간 맥락을 연결해 검색 정확도를 높였습니다.

국내 소프트웨어 기업의 추출 도구가 세계적인 개발자 플랫폼에서 1위를 차지했습니다. 완성된 제품을 넘어 핵심 역량을 오픈소스로 공개한 판단이 주효했습니다. 오랜 시간 다듬어온 문서 체계를 글로벌 표준 인프라로 전환한 과정을 살폈습니다.

문서 구조와 맥락을 보존하여 RAG 시스템의 검색 품질을 개선하는 청킹 기법의 실무 적용 방안을 다룹니다.

RAG는 매번 처음부터 답을 찾습니다. Karpathy는 LLM이 위키를 직접 유지보수하며 지식이 쌓이는 구조를 제안했습니다. DataNexus의 온톨로지 카탈로그가 방치되지 않으려면 같은 원리가 필요합니다.

노션, 깃허브, S3에 파편화된 사내 문서를 로컬 LLM으로 묶어 질의응답하는 오픈소스 플랫폼. 외부 API 없이 온프레미스로 돌립니다.

법령 XML을 직접 파싱하면 표 구조가 깨지고 전처리에 반나절이 빠집니다. 법망은 JSON으로 정제된 데이터를 바로 주는 API로, 그 과정을 미리 해결해놓은 서비스입니다.

노션, 깃허브, S3 등에 흩어진 팀 문서를 Ollama로 로컬 구동하는 RAG 플랫폼. 보안 환경에서도 외부 API 없이 자연어 검색이 됩니다.

RAG 파이프라인에 쓸 웹 데이터를 defuddle로 뽑아봤더니 사이트 구조에 따라 결과가 크게 달랐습니다. 시맨틱 HTML이 무너진 사이트에서는 본문과 광고가 섞이고, 동적 렌더링 환경에서는 내용 자체가 날아갑니다.

에이전트에게 Planning을 통째로 맡기면 프로덕션에서 루프를 돌다 멈추는 문제가 생깁니다. OpenAI 가이드는 그 문제를 명시적 워크플로우 제어로 풉니다.

PDF나 Word 파일을 LLM에 넣기 전에 표 구조와 제목 계층을 살려서 Markdown으로 바꿔주는 도구인데, 전처리 공수가 줄어드는 게 생각보다 큽니다.

“VIP 기준이 뭐죠?” 유통사 BI Agent 프로젝트에서 있었던 일입니다. 현업 담당자가 테스트 중에 Agent에게 물었습니다. “지난달 VIP 고객 매출 알려줘.” 시스템이 숫자를 뱉어냈는데, 담당자 표정이 좋지 않았습니다. “이거 뭔가 이상한데요. VIP 기준이 우리 팀이랑 다른 것 같아요.” 마케팅의 VIP와 CRM의 VIP가 달랐습니다. 매출도 마찬가지입니다. 순매출이냐 총매출이냐에 따라 수억 단위로 차이가 납니다. 처음 겪는 문제가 아니었습니다. DW를 클라우드로 옮기는 프로젝트에서도 봤고, 차세대 정보계를 여러 벤더와 1년 넘게 만들 때도 똑같았습니다. 벤더마다 “매출”, “원가"의 기준이 달라서 데이터 정합성 잡느라 몇 주씩 지연됐습니다. 용어 하나 안 맞으면 전체 일정이 밀립니다. DW/BI 프로젝트를 하면서 이 문제가 안 나온 적이 없습니다. ...