RAG 지연 최적화와 평가 - 캐싱, 인덱스 튜닝, Ragas [RAG 6]
지금까지의 시리즈에서 검색 품질을 높이는 인덱싱, 벡터 DB, hybrid search와 접근제어를 다뤘습니다. 실제 서비스에 올리면 그다음으로 마주치는 문제는 응답이 느리다는 점입니다. RAG는 매 질문마다 검색과 생성을 모두 수행하므로 단계마다 지연이 쌓이고, 정확도를 높이려 붙인 reranking이나 접근제어가 다시 지연을 늘립니다. RAG의 지...
KKamJi
RAG 보안과 접근제어 - RBAC, PII, Prompt Injection과 캐시-권한 충돌 [RAG 5]
RAG 2편부터 4편까지 “어떻게 하면 잘 검색하는가”를 다뤘습니다. 하지만 사내 정책 문서를 대상으로 RAG를 만들면, 정확도보다 먼저 부딪히는 제약이 있습니다. 정책 문서는 부서마다 열람 권한이 다르고, 이름/연락처/주민번호 같은 PII를 품고 있으며, 검색된 문서가 그대로 LLM 프롬프트로 들어가는 구조라 기존 시스템에 없던 새로운 공격면이 생깁...
RAG 검색 정확도 - Hybrid Search와 Reranking [RAG 4]
RAG 2편에서 청킹과 임베딩을, 3편에서 벡터 DB와 인덱스를 살펴봤습니다. 그런데 dense 벡터 검색만으로는 검색 품질에 한계가 있습니다. 임베딩은 의미가 비슷한 문장을 잘 찾지만, “제3조” 같은 정확한 조항 번호나 고유명사, 제품명 매칭에는 오히려 약합니다. dense 검색과 키워드 검색을 결합하는 Hybrid Search, 두 검색 결과를 ...
RAG 벡터 DB와 인덱스 - HNSW/IVF와 pgvector vs Qdrant [RAG 3]
RAG 2편에서 문서를 청크로 나누고 임베딩으로 벡터화하는 인덱싱 설계를 살펴봤습니다. 벡터가 쌓이면 다음 문제는 질의와 가까운 후보를 어떤 비용으로 찾느냐입니다. 정확 검색과 ANN의 차이, 대표 인덱스인 HNSW와 IVF, 저장소인 pgvector와 Qdrant를 선택 기준과 함께 정리합니다. 인덱스는 검색 품질을 직접 보장하지 않습니다. 같은 품...
RAG 청킹과 임베딩, Contextual Retrieval - 검색 품질을 좌우하는 인덱싱 설계 [RAG 2]
RAG 1편에서 RAG 파이프라인의 큰 그림을 살펴봤습니다. 이제 오프라인 인덱싱이 온라인 답변에 어떤 영향을 주는지 보겠습니다. 문서를 어떻게 쪼개는지(chunking), 어떤 임베딩으로 벡터화하는지, 청킹에서 잃은 맥락을 어떻게 보강하는지(Contextual Retrieval)를 다룹니다. 검색 후보가 부실하면 근거 기반 답변도 부실해지므로, 인덱...
RAG 개념과 파이프라인 Overview - LLM의 한계와 검색 증강 파이프라인 [RAG 1]
사내 정책 문서를 찾는 상황을 떠올려 봅니다. “출장 규정에서 숙박비 한도가 얼마였지”, “보안 정책상 외부 저장소 사용이 허용되는가” 같은 질문의 답은 대부분 어딘가의 문서에 이미 존재합니다. 하지만 문서는 PDF, Confluence 위키, 사내 위키 등 여러 곳에 흩어져 있고, 일반 LLM에게 물으면 그 문서를 보지 못한 채 그럴듯하지만 틀린 답...
Spring/JVM Capstone - 업그레이드 후 Old gen과 off-heap 메모리 진단
이 커리큘럼은 하나의 질문에서 시작했습니다. “Spring Boot 메이저 업그레이드(새 JDK/G1GC 동반) 이후, Old gen이 예전보다 높게 유지되고 컨테이너 메모리가 빠듯해 보인다. 메모리 누수일까?” 마지막 글에서는 Series 1~4에서 쌓은 조각(요청 처리, JVM 메모리, GC, 동시성, 데이터 계층)을 모아 이 질문을 끝까지 진단합...
프로세스 메모리 레이아웃과 stack vs heap
Series 1에서 “요청이 흐르는 길”을 위에서 아래로 따라왔고, 3편에서 “스레드 스택은 힙이 아니라 native 메모리”라고 했습니다. 이번 편에서는 그때 흘려보낸 stack과 heap이 각각 무엇이고 어떻게 다른지를 프로세스 메모리 레이아웃 관점에서 정리합니다. Series 2는 한 계층 더 내려가 JVM과 메모리를 다룹니다. 그 첫걸음으로,...
buildpack과 JVM Memory Calculator
앞 편에서 “컨테이너 메모리 = Heap + Non-heap + 여유”라는 걸 봤습니다. 그런데 -Xmx(Heap)를 누가 정할까요? 명시하지 않으면, Spring Boot 컨테이너 이미지에서는 buildpack의 Memory Calculator가 자동으로 계산합니다. 그리고 그 계산식이 앞 편의 분해 그대로입니다. 이 편은 Series 1 4편의 ...
GC 튜닝과 JDK 버전별 G1 거동 변화
앞 편에서 G1의 기계장치(pause 목표, adaptive IHOP, mixed collection)를 봤습니다. Series 2의 마지막인 이번 편은 그 손잡이를 튜닝하거나, JDK 버전이 G1의 휴리스틱을 바꿀 때 메모리 곡선이 어떻게 달라지는지를 다룹니다. 흔한 증상 하나: “런타임(JDK) 업그레이드 후 Old gen이 예전보다 높게 유지된...