CELL AI DEVLOG

"AI가 왜 이걸 지어냈냐?"는 질문이 반복된다면 RAG 파이프라인이 잘못된 겁니다. 문서 파싱이 깨지거나, 청킹이 문맥을 잘라버리거나, 검색된 청크가 엉뚱한 내용이거나. RAGFlow는 이 세 가지 실패 지점을 설계 원칙으로 해결합니다. 답변마다 어느 문서의 어느 부분에서 왔는지 추적 가능한 인용이 붙습니다.[핵심 요약]→ RAGFlow: Infiniflow가 만든 오픈소스 RAG 엔진 — GitHub 73,200+ 스타, Apache 2.0→ 핵심 철학: 답변 품질은 문서 파싱 품질에서 시작 — "Garbage in, garbage out" 해결→ DeepDoc: PDF·Word·Excel·스캔본·PPT의 표·이미지·복잡한 레이아웃 정확히 파싱→ 인용 추적: 모든 답변에 출처 문서 + 청크 위치 표시..

RAG를 만들었는데 검색 품질이 나쁩니다. 청킹도 바꿔보고 프롬프트도 바꿨는데 여전합니다. 임베딩 모델이 문제일 수 있습니다. 선택 기준부터 실전 적용까지 정리했습니다.[핵심 요약]→ 임베딩: 텍스트를 의미 기반 숫자 벡터로 변환하는 것→ 역할: RAG에서 "관련 문서를 찾는" 핵심 엔진→ 모델 선택이 RAG 품질의 40~60%를 결정→ 주요 모델: Qwen3-Embedding, OpenAI, Cohere, bge-m3, Voyage AI→ 한국어: Qwen3-Embedding-8B, bge-m3, Cohere multilingual 추천→ 평가: MTEB 벤치마크 기준 + 실제 도메인 테스트 필수→ 비용: 로컬(무료) vs API(편리) — 볼륨에 따라 선택임베딩이 뭔지 30초 정리# 임베딩 = 텍스트..

RAG 파이프라인을 만들다 보면 항상 이 벽에 부딪혀요."이 PDF 분석해줘"→ LLM: ????이유:PDF는 렌더링용 포맷텍스트, 이미지, 표가 뒤섞인 이진 파일LLM이 직접 이해하기 어려움그래서 보통 이렇게 함:PDF → PyPDF2로 텍스트 추출 → 근데 표/이미지 날아감Word → python-docx → 복잡한 파싱 코드 작성PPT → 슬라이드 하나씩 수동 처리Excel → pandas로 읽고 또 변환→ 포맷마다 다른 라이브러리→ 포맷마다 다른 코드→ 복잡하고 유지보수 힘듦Microsoft가 이 문제를 해결하는 도구를 오픈소스로 냈어요. markitdown이에요.pip install 'markitdown[all]'markitdown 문서.pdf끝.GitHub 별 5만개+. MIT 라이선스.뭘 지..

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 데모는 항상 잘 돼요.PDF 몇 개 넣고, 벡터 DB 연결하고, LLM 붙이면 마법처럼 답이 나와요. 팀이 흥분하고, 경영진이 빠른 배포를 요구해요.그리고 3개월 뒤, 시스템이 무너지기 시작해요.데이터가 많아지면서 검색이 틀리고, 답이 엉뚱하고, 비용이 폭증하고, 아무도 원인을 모르는 상황이 돼요.엔터프라이즈 RAG 구현의 40~72%가 첫 해 안에 실패해요. 모델이 나빠서가 아니에요. 아키텍처가 데모용으로 설계됐기 때문이에요.이번 글에서는 RAG가 실패하는 7가지 이유와 실전 해결책을 코드와 함께 정리해 드릴게요.실패 원인 1: 잘못된 청킹 전략가장 흔하고 가장 치명적인 실수예요. 문서를 고정 크기(512 토큰)로 자르면 이런 일이 생겨요.원본 문서:"환불 정책은 구매 후 30일 이내에 적용됩니..

LLM을 쓰다 보면 이런 상황이 생겨요."분명히 풀 수 있는 문제인데 틀린 답을 내놓네. 어떻게 하면 더 정확하게 추론하게 만들지?"모델을 바꾸거나 파인튜닝하지 않아도 추론 방식을 바꾸는 것만으로 정확도를 크게 올릴 수 있어요. 이번 글에서는 세 가지 핵심 추론 기법 — Chain-of-Thought, Tree-of-Thought, Self-Consistency — 을 원리부터 실전 적용까지 비교해 드릴게요.왜 추론 기법이 필요한가LLM은 기본적으로 다음 토큰을 예측하는 모델이에요. 바로 답을 내놓으라고 하면 중간 과정 없이 확률적으로 그럴듯한 답을 생성해요. 복잡한 문제에서는 이게 틀릴 확률이 높아요.# 바로 답하기 — 틀리기 쉬움질문: "농부가 닭 17마리와 양 10마리를 키운다. 다리는 총 몇 개인..

RAG 시스템을 만들고 나면 이런 한계가 생겨요."단순한 질문은 잘 답하는데, '2024년 실적을 바탕으로 2025년 전략을 분석해줘' 같은 복잡한 질문은 엉뚱한 답이 나온다."이건 일반 RAG의 구조적 한계예요. 한 번 검색하고 끝나는 구조로는 복잡한 다단계 질문을 처리할 수가 없어요. 이걸 해결하는 게 Agentic RAG입니다.일반 RAG의 한계일반 RAG의 파이프라인은 고정돼 있어요.질문 → 벡터 검색 → 상위 K개 문서 → LLM → 답변단순하고 빠른데, 세 가지 문제가 있어요.한 번밖에 검색 못 해요. 검색 결과가 별로여도 그냥 그걸로 답해요. "부족하다"는 판단을 못 해요.쿼리 복잡도를 무시해요. "파이썬이 뭐야?" 같은 단순 질문과 "2024년 AI 트렌드를 분석하고 우리 회사 전략에 어떻..

Elasticsearch로 RAG 시스템을 만들다 보면 이런 상황이 생겨요."의미 기반 벡터 검색도 하고 싶고, 정확한 키워드 검색도 하고 싶은데 어떻게 같이 써?"그리고 한국어 데이터를 다루면 또 이런 문제가 생겨요."형태소 분석 없이 BM25 하면 '검색엔진'으로 검색할 때 '검색'만 들어간 문서가 안 나오네."이번 글에서는 Dense Vector KNN으로 의미 검색을 하고, Nori 형태소 분석기 기반 BM25로 키워드 검색을 하고, 두 개를 하이브리드로 결합하는 방법을 처음부터 끝까지 정리해 드릴게요.전체 구조 먼저사용자 쿼리 │ ├─ 임베딩 변환 → Dense Vector KNN (의미 기반 검색) └─ 텍스트 그대로 → BM25 + Nori (키워드 기반 검색) │ ..

RAG 시스템을 만들 때 이런 고민이 생깁니다."벡터 DB가 이렇게 많은데 뭘 써야 하지? 다들 자기가 제일 빠르다고 하는데."벤더 벤치마크는 전부 자기한테 유리하게 나와 있어요. 이번 글에서는 ChromaDB, Qdrant, Pinecone, Elasticsearch 네 가지를 실전 관점에서 비교해 드릴게요.벡터 DB가 왜 필요한가일반 DB는 정확한 값으로 검색해요. "이름 = 홍길동"처럼요. 벡터 DB는 의미적으로 유사한 것을 찾아요. "강아지"를 검색하면 "멍멍이", "반려견", "puppy"도 찾아주는 거예요.RAG 시스템에서 "사용자 질문과 관련된 문서를 찾아서 LLM에 넘기는" 과정이 바로 벡터 검색이에요. 이 검색이 빠르고 정확해야 RAG 전체 품질이 올라갑니다.4개 한눈에 비교구분 Chro..