2분
문서가 늘면 검색이 느려질까
Day 3: 벡터 DB (Chroma, Pinecone)
문서가 늘면 검색이 느려질까
RAG 기초 > Day 3: 벡터 DB (Chroma, Pinecone)
학습 목표
- 벡터 DB가 왜 필요한지 체감한다
- 파일/리스트 기반 검색의 한계를 이해한다
문서가 늘면 검색이 느려질까
"문서가 5만 건이 되면 파이썬 리스트로는 못 버티겠죠?"
김 대리가 물었다. 그럴듯한 걱정이다. 그런데 이런 질문에는 답을 듣는 것보다 재보는 편이 빠르다.
import numpy as np, time
n, dim = 50_000, 1536
db = np.random.randn(n, dim).astype("float32")
db /= np.linalg.norm(db, axis=1, keepdims=True)
q = db[0]
t = time.perf_counter()
scores = db @ q # 전수 비교를 행렬곱 한 번으로
top = np.argsort(-scores)[:5]
print(f"{n}건 검색: {time.perf_counter() - t:.3f}초")직접 돌려 보고 그 숫자를 적어라. 그리고 n을 5,000과 500,000으로 바꿔 다시 재라. 노트북에서도 생각보다 빠르게 끝날 것이다. 전수 비교는 곱셈과 덧셈일 뿐이고, numpy는 그 일을 잘한다.
그러면 벡터 DB는 왜 필요한가
속도만 놓고 보면 프로토타입 규모에서 벡터 DB가 없어도 된다. 실제로 필요해지는 것은 다른 곳이다.
| 필요해지는 것 | 리스트 + 전수 비교로는 |
|---|---|
| 여러 사람이 동시에 물어본다 | 요청마다 전체를 다시 훑는다 |
| 서버를 다시 켜도 색인이 남아야 한다 | 메모리에만 있어 매번 다시 만든다 |
| 문서 한 건만 갱신하고 싶다 | 전체를 다시 임베딩한다 |
| 설비별·버전별로 걸러서 찾는다 | 필터를 직접 만들어야 한다 |
| 벡터가 메모리보다 커진다 | 올릴 수 없다 |
여기에 규모가 커지면 지연시간도 문제가 되기 시작한다. 근사 검색(HNSW)은 그때 모든 벡터를 보지 않고 답을 찾는 방법이다. 얼마나 덜 보는지는 오늘 시뮬레이터에서 직접 세어 볼 수 있다.
오늘은 벡터 DB 두 가지(Chroma, Pinecone)를 배우고 직접 구축한다.
AI로 학습하기 — 꿀팁
벡터 만 개 검색 성능 병목 원인 분석AI 학습 팁
파일 기반 벡터 검색의 O(n) 스캔이 왜 실시간 제조 환경에서 허용 불가한지 구체적 수치로 이해하면 벡터 DB의 필요성이 명확해진다.
제조 공장 설비 문서를 벡터화했더니 10,000개 청크가 생성되었다. 현재 numpy 배열로 저장해 코사인 유사도를 전체 스캔하는 방식을 사용 중이다. 다음을 계산하고 분석해줘: 1) 768차원 벡터 10,000개의 메모리 사용량(float32 기준), 2) 검색 1회당 연산량(FLOPs 추정)과 예상 지연시간(CPU 기준), 3) 문서가 100,000개로 늘어날 경우 선형 스캔 vs HNSW 인덱스의 검색 시간 비교표, 4) 생산라인 작업자가 설비 이상 발생 시 허용 가능한 최대 응답 시간(SLA)과 현재 방식이 이를 만족하는지 여부. 실제 벡터 DB(Chroma, Pinecone) 도입 후 기대되는 성능 개선 수치도 포함해줘.
이 팁이 도움이 됐나요?