Rag 썸네일형 리스트형 RAG 청킹 전략 완전 정리 RAG 시스템이 엉터리 답변을 내놓을 때 대부분 이렇게 생각해요."임베딩 모델 바꿔볼까?""프롬프트 더 정교하게 써야겠다""LLM을 더 좋은 걸로 바꾸면 되겠지"근데 실제로 RAG 실패의 80%는 청킹 문제예요.잘못 자른 청크가 들어가면 아무리 좋은 LLM도 엉터리 답변을 낼 수밖에 없어요.청킹이 뭔가RAG는 문서를 통째로 넣을 수 없어요. 임베딩 모델의 입력 한계가 있고, 벡터 검색 정확도도 떨어져요.원문 (10,000 토큰):"회사 규정 전체 문서..."청킹:청크 1: "출근 시간은 오전 9시..." (512토큰)청크 2: "연차 사용 규정은..." (512토큰)청크 3: "복리후생 제도는..." (512토큰)...질문: "연차 며칠이야?"→ 청크 2만 검색됨→ 관련 내용만 LLM에 전달→ 정확한 답.. 더보기 컨텍스트 엔지니어링 — 프롬프트 엔지니어링의 다음 단계 2025년 6월, Andrej Karpathy(전 OpenAI, Tesla AI 디렉터)가 X에 짧은 글 하나를 올렸어요."프롬프트 엔지니어링이라는 말은 우리가 실제로 하는 일을 너무 사소하게 만든다. 더 정확한 표현은 컨텍스트 엔지니어링이다."그리고 Shopify CEO 토비 뤼트케가 동의하며 이렇게 정의했어요."LLM이 그럴듯하게 문제를 풀 수 있도록 모든 컨텍스트를 제공하는 기술."이 두 발언 이후 AI 개발 커뮤니티에서 컨텍스트 엔지니어링이 2026년 가장 중요한 개념으로 자리 잡았어요.프롬프트 엔지니어링과 뭐가 다른가먼저 LLM을 컴퓨터로 비유해볼게요.LLM = CPU컨텍스트 윈도우 = RAM컨텍스트 엔지니어링 = 운영체제운영체제는 CPU가 작업할 때 RAM에 딱 필요한 데이터만 올려요. 너무 .. 더보기 RAG 데모는 잘 되는데 배포하면 망하는 이유 7가지 — 원인별 해결법, 프로덕션 RAG 완전 가이드 RAG 데모는 항상 잘 돼요.PDF 몇 개 넣고, 벡터 DB 연결하고, LLM 붙이면 마법처럼 답이 나와요. 팀이 흥분하고, 경영진이 빠른 배포를 요구해요.그리고 3개월 뒤, 시스템이 무너지기 시작해요.데이터가 많아지면서 검색이 틀리고, 답이 엉뚱하고, 비용이 폭증하고, 아무도 원인을 모르는 상황이 돼요.엔터프라이즈 RAG 구현의 40~72%가 첫 해 안에 실패해요. 모델이 나빠서가 아니에요. 아키텍처가 데모용으로 설계됐기 때문이에요.이번 글에서는 RAG가 실패하는 7가지 이유와 실전 해결책을 코드와 함께 정리해 드릴게요.실패 원인 1: 잘못된 청킹 전략가장 흔하고 가장 치명적인 실수예요. 문서를 고정 크기(512 토큰)로 자르면 이런 일이 생겨요.원본 문서:"환불 정책은 구매 후 30일 이내에 적용됩니.. 더보기 [기초] LLM이 더 똑똑하게 생각하게 만드는 법 — CoT, ToT, Self-Consistency 완전 비교 LLM을 쓰다 보면 이런 상황이 생겨요."분명히 풀 수 있는 문제인데 틀린 답을 내놓네. 어떻게 하면 더 정확하게 추론하게 만들지?"모델을 바꾸거나 파인튜닝하지 않아도 추론 방식을 바꾸는 것만으로 정확도를 크게 올릴 수 있어요. 이번 글에서는 세 가지 핵심 추론 기법 — Chain-of-Thought, Tree-of-Thought, Self-Consistency — 을 원리부터 실전 적용까지 비교해 드릴게요.왜 추론 기법이 필요한가LLM은 기본적으로 다음 토큰을 예측하는 모델이에요. 바로 답을 내놓으라고 하면 중간 과정 없이 확률적으로 그럴듯한 답을 생성해요. 복잡한 문제에서는 이게 틀릴 확률이 높아요.# 바로 답하기 — 틀리기 쉬움질문: "농부가 닭 17마리와 양 10마리를 키운다. 다리는 총 몇 개인.. 더보기 쿼리 재작성, 반복 검색, 멀티소스 라우팅 — Agentic RAG 동작 원리와 동적 검색 전략 완전 정리 RAG 시스템을 만들고 나면 이런 한계가 생겨요."단순한 질문은 잘 답하는데, '2024년 실적을 바탕으로 2025년 전략을 분석해줘' 같은 복잡한 질문은 엉뚱한 답이 나온다."이건 일반 RAG의 구조적 한계예요. 한 번 검색하고 끝나는 구조로는 복잡한 다단계 질문을 처리할 수가 없어요. 이걸 해결하는 게 Agentic RAG입니다.일반 RAG의 한계일반 RAG의 파이프라인은 고정돼 있어요.질문 → 벡터 검색 → 상위 K개 문서 → LLM → 답변단순하고 빠른데, 세 가지 문제가 있어요.한 번밖에 검색 못 해요. 검색 결과가 별로여도 그냥 그걸로 답해요. "부족하다"는 판단을 못 해요.쿼리 복잡도를 무시해요. "파이썬이 뭐야?" 같은 단순 질문과 "2024년 AI 트렌드를 분석하고 우리 회사 전략에 어떻.. 더보기 Elasticsearch로 한국어 RAG 만드는 법 — Dense Vector KNN + BM25 + Nori 완전 정리 Elasticsearch로 RAG 시스템을 만들다 보면 이런 상황이 생겨요."의미 기반 벡터 검색도 하고 싶고, 정확한 키워드 검색도 하고 싶은데 어떻게 같이 써?"그리고 한국어 데이터를 다루면 또 이런 문제가 생겨요."형태소 분석 없이 BM25 하면 '검색엔진'으로 검색할 때 '검색'만 들어간 문서가 안 나오네."이번 글에서는 Dense Vector KNN으로 의미 검색을 하고, Nori 형태소 분석기 기반 BM25로 키워드 검색을 하고, 두 개를 하이브리드로 결합하는 방법을 처음부터 끝까지 정리해 드릴게요.전체 구조 먼저사용자 쿼리 │ ├─ 임베딩 변환 → Dense Vector KNN (의미 기반 검색) └─ 텍스트 그대로 → BM25 + Nori (키워드 기반 검색) │ .. 더보기 RAG 시스템에 맞는 벡터 DB는 뭔가 — ChromaDB vs Qdrant vs Pinecone vs Elasticsearch 완전 비교 RAG 시스템을 만들 때 이런 고민이 생깁니다."벡터 DB가 이렇게 많은데 뭘 써야 하지? 다들 자기가 제일 빠르다고 하는데."벤더 벤치마크는 전부 자기한테 유리하게 나와 있어요. 이번 글에서는 ChromaDB, Qdrant, Pinecone, Elasticsearch 네 가지를 실전 관점에서 비교해 드릴게요.벡터 DB가 왜 필요한가일반 DB는 정확한 값으로 검색해요. "이름 = 홍길동"처럼요. 벡터 DB는 의미적으로 유사한 것을 찾아요. "강아지"를 검색하면 "멍멍이", "반려견", "puppy"도 찾아주는 거예요.RAG 시스템에서 "사용자 질문과 관련된 문서를 찾아서 LLM에 넘기는" 과정이 바로 벡터 검색이에요. 이 검색이 빠르고 정확해야 RAG 전체 품질이 올라갑니다.4개 한눈에 비교구분 Chro.. 더보기 벡터 검색 정확도 올리는 법 — 임베딩 모델 선택부터 HNSW 튜닝, Reranking까지 벡터 검색을 붙여봤는데 결과가 기대보다 별로라는 경험, 한 번쯤 있으실 거예요."분명히 관련 있는 문서인데 왜 안 나오지?"이번 글에서는 벡터 검색 정확도를 높이는 방법을 임베딩 모델 선택부터 Reranking까지 단계별로 정리해 드릴게요.1. 좋은 임베딩 모델 선택벡터 검색 정확도의 기반은 임베딩 모델이에요. 모델이 좋아야 검색 품질이 올라갑니다.현재 성능이 검증된 모델들은 이렇습니다.BGE (bge-large, bge-m3) — 최근 벤치마크에서 성능 좋음E5 (e5-large, e5-mistral) — 다양한 벤치마크에서 우수한 성능Qwen-Embedding — 최근 MTEB 벤치마크에서 최상위권, 다국어 지원 강력MiniLM, Contriever — 가볍지만 성능 괜찮음OpenAI Embeddin.. 더보기 이전 1 2 다음