AWS Bedrock Knowledge Base 글에서는 관리형 RAG의 구성 요소와 API, 접근제어를 정리했습니다. 이번 글에서는 그 개념을 바탕으로 Slack에서 실제로 사용할 수 있는 RAG 챗봇 운영 구조를 설계합니다. 원본 문서는 Google Docs에서 관리하고, 이미 배포된 n8n workflow가 Google Docs를 PDF로 exp...

RAG 시리즈에서 chunking, 임베딩, 벡터 DB, hybrid search, 보안까지 RAG 파이프라인을 직접 구성하는 관점으로 다뤘습니다. 그런데 이 파이프라인 전체를 매니지드 서비스로 대신 운영해 주는 선택지도 있습니다. Amazon Bedrock Knowledge Base는 S3 등에 있는 문서를 가리키면 fetch, chunking, e...

Hermes Agent는 터미널과 메시징 환경에서 동작하는 self-hosted open-source agent입니다. 단순한 CLI 챗봇이 아니라 memory, SOUL.md persona, skills, cron, messaging gateway를 함께 사용해 개인 작업 환경에 상주하는 자율 AI agent로 구성할 수 있습니다. 이번 글에서는 W...

RAG 1편부터 6편까지 검색 파이프라인을 인덱싱, 벡터 DB, 검색 정확도, 보안, 지연/평가 순으로 살펴봤습니다. 이번 글에서는 검색된 청크를 LLM에 넘겨 답을 만드는 generation 단계와, 이 단계에서 출처(citation)를 어떻게 보장하는지를 다룹니다. 이어서 표준 vector RAG를 넘어서는 고급 기법인 GraphRAG와 Agent...

서버 쪽 observability는 APM, logs, metrics로 비교적 익숙하게 다룹니다. 그런데 “백엔드는 200 OK로 빠르게 응답했는데 사용자는 느리다고 한다”는 상황은 server-side 신호만으로는 잘 잡히지 않습니다. 느린 렌더링, 레이아웃 이동, 브라우저 JS 에러처럼 사용자가 실제로 겪는 문제는 대부분 client-side에서 ...

지금까지의 시리즈에서 검색 품질을 높이는 인덱싱, 벡터 DB, hybrid search와 접근제어를 다뤘습니다. 실제 서비스에 올리면 그다음으로 마주치는 문제는 응답이 느리다는 점입니다. RAG는 매 질문마다 검색과 생성을 모두 수행하므로 단계마다 지연이 쌓이고, 정확도를 높이려 붙인 reranking이나 접근제어가 다시 지연을 늘립니다. 이번 글에서...

RAG 2편부터 4편까지 “어떻게 하면 잘 검색하는가”를 다뤘습니다. 하지만 사내 정책 문서를 대상으로 RAG를 만들면, 정확도보다 먼저 부딪히는 제약이 있습니다. 정책 문서는 부서마다 열람 권한이 다르고, 이름/연락처/주민번호 같은 PII를 품고 있으며, 검색된 문서가 그대로 LLM 프롬프트로 들어가는 구조라 기존 시스템에 없던 새로운 공격면이 생깁...

RAG 2편에서 청킹과 임베딩을, 3편에서 벡터 DB와 인덱스를 살펴봤습니다. 그런데 dense 벡터 검색만으로는 검색 품질에 한계가 있습니다. 임베딩은 의미가 비슷한 문장을 잘 찾지만, “제3조” 같은 정확한 조항 번호나 고유명사, 제품명 매칭에는 오히려 약합니다. 이번 글에서는 dense 검색과 키워드 검색을 결합하는 Hybrid Search, 두...

RAG 2편에서 문서를 청크로 나누고 임베딩으로 벡터화하는 인덱싱 설계를 살펴봤습니다. 이렇게 만들어진 수백만 개의 벡터에서 질의와 가까운 것을 빠르게 찾으려면 저장소와 인덱스가 필요합니다. 이번 글에서는 벡터 검색의 핵심 문제와 측정 축, 대표 인덱스인 HNSW와 IVF의 동작 원리, 그리고 pgvector와 Qdrant를 선택 기준 관점에서 살펴봅...

RAG 1편에서 RAG 파이프라인의 큰 그림을 살펴봤습니다. 이번 글에서는 그중에서도 검색 품질을 가장 크게 좌우하는 인덱싱 단계, 즉 문서를 어떻게 쪼개고(chunking), 어떤 임베딩으로 벡터화하며, 청킹 과정에서 잃어버리는 맥락을 어떻게 되살리는지(Contextual Retrieval)를 다룹니다. RAG는 “검색이 틀리면 생성도 틀린다”는 구...