| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | ||||
| 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| 11 | 12 | 13 | 14 | 15 | 16 | 17 |
| 18 | 19 | 20 | 21 | 22 | 23 | 24 |
| 25 | 26 | 27 | 28 | 29 | 30 | 31 |
- go
- SRE
- 오블완
- tucker의 go 언어 프로그래밍
- minikube
- 바이브코딩
- Pinpoint
- 코틀린 코루틴의 정석
- PETERICA
- 정보처리기사 실기 기출문제
- CKA 기출문제
- Java
- AI
- CKA
- aws
- kotlin
- Spring
- AWS EKS
- 기록으로 실력을 쌓자
- MySQL
- Linux
- Kubernetes
- CloudWatch
- LLM
- 티스토리챌린지
- kotlin coroutine
- APM
- 컨텍스트 엔지니어링
- 공부
- golang
- Today
- Total
피터의 개발이야기
[AI] RAG구성을 위한 FAISS란? 본문
ㅁ 들어가며
최근 RAG(Retrieval Augmented Generation)를 구성하기 위해 벡터 검색 기술을 공부하게 되었고,
그 과정에서 FAISS를 중심으로 개념 정리와 실험을 진행했다.
이 글은 LLM 전문가가 아닌 백엔드 개발자 관점에서,
FAISS가 무엇이고 어떻게 쓰이는지,
그리고 어디까지 직접 운영할 수 있는지를 정리한 기록이다.
ㅁ FAISS란?
FAISS(Facebook AI Similarity Search)는 벡터 간 유사도 검색을 빠르게 수행하기 위한 라이브러리다.
데이터베이스가 아니라, 검색 엔진의 핵심 알고리즘 모음에 가깝다.
ㅇ 기본 성격
- Meta AI Research에서 개발한 오픈소스 라이브러리
- C++ 기반, Python 바인딩 제공
- 벡터(임베딩)를 입력받아 가장 가까운 벡터를 찾아주는 역할
ㅇ FAISS가 다루는 것과 다루지 않는 것
- 다룸: float 벡터, 거리 계산, 인덱스 구조
- 다루지 않음: 텍스트, 메타데이터, 트랜잭션, API, 권한
즉, FAISS는 "DB"가 아니라
"검색 인덱스를 직접 구현할 때 사용하는 엔진"이다.
ㅁ FAISS를 왜 쓰는가
벡터 검색은 단순한 키 조회가 아니라,
모든 벡터와의 거리 계산이 기본이 된다.
FAISS는 이 문제를 현실적인 성능으로 풀기 위한 도구다.
ㅇ 장점
- 메모리 기반이라 매우 빠름
- CPU만으로도 수십만~수백만 벡터 처리 가능
- GPU 사용 시 대규모 검색도 가능
- 인덱스 구조를 직접 선택하고 튜닝 가능
ㅇ 단점
- 서버 기능이 전혀 없음
- 메타데이터 관리, 백업, 복구를 직접 구현해야 함
- 메모리 한계를 넘으면 성능이 급격히 무너짐
Redis와 유사하게
"빠르지만, 책임도 전부 개발자 몫"인 도구라고 보면 이해가 쉽다.
ㅁ FAISS의 인덱스 개념 (Flat vs IVF)
ㅇ Flat 인덱스
- 모든 벡터를 전부 비교
- 구현은 단순하지만 데이터가 늘수록 선형으로 느려짐
- PoC나 소규모 데이터에 적합
ㅇ IVF(Inverted File Index)
- 벡터 공간을 여러 버킷(centroid)으로 나눔
- 검색 시 일부 버킷만 조회
- DB의 파티셔닝/샤딩과 유사한 개념
IVF는 LLM 기술이 아니라,
"풀스캔을 피하기 위한 전형적인 인덱스 전략"이다.
ㅁ RAG에서의 FAISS 사용 흐름
ㅇ 오프라인 단계
- 문서를 일정 길이로 청크 분할
- 각 청크를 임베딩 모델로 변환
- IVF 인덱스를 학습(train)
- 벡터를 FAISS 인덱스에 추가(add)
- 메타데이터는 SQLite 등 별도 저장
ㅇ 온라인 단계
- 사용자 질문을 임베딩으로 변환
- FAISS에서 top-k 벡터 검색
- 결과 ID로 메타데이터 조회
- 검색 결과를 LLM 프롬프트에 포함
이 구조에서 FAISS는
"검색 인덱스 계층" 역할만 담당한다.
ㅁ IVF train은 언제 다시 해야 하나
IVF train은 버킷(centroid)을 학습하는 단계다.
따라서 데이터 분포가 달라지면 다시 해야 한다.
ㅇ 재학습이 필요한 경우
- 새로운 도메인/카테고리 문서가 대량 유입
- 언어가 추가되거나 문서 스타일이 크게 변경
- 벡터 수가 초기 대비 20~50% 이상 증가
- Recall 저하, p95 latency 증가 등 지표 악화
ㅇ 재학습이 필요 없는 경우
- 소규모 문서 추가
- 분포 변화 없이 점진적 증가
- 성능 지표가 안정적인 경우
실무에서는
"add는 자주, train은 드물게"가 기본 원칙이다.
ㅁ 운영 관점에서의 핵심 포인트
ㅇ 메모리 관리
- 스왑이 발생하면 성능이 급락
- 메모리 여유선을 명확히 설정해야 함
ㅇ 업데이트 전략
- 메인 IVF 인덱스는 배치 재빌드
- 실시간 변경은 소규모 delta 인덱스로 흡수
ㅇ 장애 포인트
- 인덱스 재로딩 시간
- 재빌드 윈도우 관리
- 메타데이터와 벡터 간 불일치
ㅁ 마무리
FAISS는 LLM 기술이라기보다
"벡터 기반 검색 엔진을 만들기 위한 저수준 도구"에 가깝다.
RAG 시스템에서 성능과 안정성을 좌우하는 요소는
프롬프트보다 검색 구조와 인덱스 설계인 경우가 많다.
백엔드 개발자라면,
FAISS를 새로운 AI 기술로 보기보다
익숙한 검색·인덱스 문제의 연장선으로 바라보는 것이
이해와 운영 모두에 도움이 된다.
'AI > AI이론 | 공부' 카테고리의 다른 글
| 🏠 AI Knowledge Base - Home (0) | 2026.01.29 |
|---|---|
| [AI] Backend · DevOps · SRE를 지나 AI Platform Engineer를 지향하게 된 이유 (0) | 2026.01.27 |
| [AI] LLM 학습을 위한 큐레이션 허브(LLM Engineer Toolkit) (0) | 2026.01.13 |
| [AI] QAT(Quantization-Aware Training) — 양자화를 가장 똑똑하게 하는 방법 (0) | 2025.12.12 |
| [AI] LLM 양자화와 벡터 양자화(VQ)의 차이 (0) | 2025.12.10 |
