AI Engineering Academy · 강의

벡터 데이터베이스가 필요한 이유

무차별 대입 유사도 검색의 한계, HNSW와 같은 근사 최근접 이웃 알고리즘의 작동 방식, 벡터 데이터베이스가 운영 환경에서 해결하는 문제를 이해합니다.

벡터 데이터베이스가 필요한 이유은(는) CoddyKit의 무료 AI Engineering Academy 강의입니다. 이것은 4개 중 1번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 AI Engineering Academy 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. AI Engineering Academy 강의에는 총 4개의 강의가 포함되어 있습니다.

이 강의의 일부는 아직 번역되지 않았으며 영어로 표시됩니다.

The Limits of In-Memory Search

NumPy semantic search works well for small corpora, but it has a fundamental scalability problem: every search scans every vector. At 1 million documents, each query requires 1.5 billion floating-point multiplications, taking hundreds of milliseconds. Worse, all vectors must fit in RAM.

Production AI systems need search over millions of documents in under 50ms. This is what vector databases are designed to deliver.

Approximate Nearest Neighbor Search

Approximate Nearest Neighbor (ANN) algorithms trade a small amount of accuracy for dramatic speed improvements. Instead of checking every vector, ANN algorithms use smart indexing structures to skip large portions of the search space.

In practice, ANN returns the true nearest neighbor over 95% of the time while being 100-1000x faster than exact search. For RAG, this tradeoff is almost always worth it.

How HNSW Works

HNSW (Hierarchical Navigable Small World) is the dominant ANN algorithm used by Pinecone, Weaviate, Qdrant, and pgvector. It builds a multi-layer graph where each node connects to its nearest neighbors. Search starts at the top sparse layer, navigates to the approximate region, then descends to the dense bottom layer for precision.

HNSW offers excellent query speed (logarithmic in dataset size) and high recall, but requires building the index upfront.

What Vector Databases Add on Top

A vector database is more than an ANN index. It also provides:

Metadata filtering — retrieve only vectors where category='finance' or date > '2024-01-01'
Persistent storage — data survives restarts and scales beyond RAM
CRUD operations — insert, update, and delete individual vectors
Namespace isolation — separate collections for different customers or environments
Horizontal scaling — distribute millions of vectors across shards

Metadata Filtering in Practice

Metadata filtering lets you restrict retrieval to a relevant subset before running ANN search. For example, in a multi-tenant RAG system, you would filter by tenant_id so users only see their own documents. Without metadata filtering, you would need a separate index per tenant.

This is one of the most important capabilities that separates vector databases from simple ANN libraries like FAISS.

# Conceptual example — Pinecone query with metadata filter
results = index.query(
    vector=query_embedding,
    top_k=5,
    filter={
        'tenant_id': {'$eq': 'acme_corp'},
        'document_type': {'$in': ['invoice', 'contract']},
        'date': {'$gte': '2024-01-01'}
    },
    include_metadata=True
)

FAISS: High-Performance ANN Library

FAISS (Facebook AI Similarity Search) is an open-source ANN library from Meta — the fastest option for GPU-accelerated search. It is not a full database: it has no persistence, no metadata, and no built-in serving.

FAISS is ideal when you need maximum throughput on a single machine and manage persistence yourself. Chroma, Weaviate, and pgvector all use FAISS or HNSW under the hood.

import faiss
import numpy as np

d = 1536  # dimension
n = 10000  # number of vectors

# Build a flat (exact) index as a baseline
index = faiss.IndexFlatIP(d)  # Inner Product = dot product

# Add random vectors (pretend these are embeddings)
vectors = np.random.randn(n, d).astype('float32')
faiss.normalize_L2(vectors)  # normalize for cosine sim
index.add(vectors)

query = np.random.randn(1, d).astype('float32')
faiss.normalize_L2(query)

scores, indices = index.search(query, k=5)
print('Top 5 indices:', indices[0])
print('Top 5 scores:', scores[0])

Vector Databases vs Traditional Databases

Traditional SQL databases like PostgreSQL are optimized for exact lookups and range queries on structured data. They are not designed for high-dimensional nearest neighbor search. Even with the pgvector extension, pure PostgreSQL is slower than purpose-built vector databases for large corpora.

However, pgvector is an excellent choice when your application already runs on PostgreSQL and your corpus is under a few million documents, since it avoids adding another infrastructure component.

Managed vs Self-Hosted Options

Vector database choices fall into two categories:

Managed (serverless): Pinecone, Weaviate Cloud — no infrastructure to manage, pay per query/storage, immediate scalability
Self-hosted: Qdrant, Chroma, Weaviate open-source, pgvector — full control, lower cost at scale, but you manage backups, upgrades, and scaling

For early-stage projects, start with a managed service to move quickly. Evaluate self-hosting when monthly costs exceed $200-300.

Index Types: Flat, IVF, and HNSW

Different index types offer different trade-offs:

Flat: Exact search, no approximation, slow at scale but zero accuracy loss — good for baseline benchmarking
IVF (Inverted File): Partitions vectors into clusters, searches only the nearest clusters — fast but needs tuning of nlist and nprobe
HNSW: Graph-based, best recall-speed trade-off for most workloads, the default in most production databases

Quantization for Memory Reduction

Vector quantization compresses each 32-bit float in a vector to fewer bits, dramatically reducing memory usage at the cost of slight accuracy loss:

FP32: 1536 dims × 4 bytes = 6KB per vector
FP16: 3KB per vector — 2x compression, negligible accuracy loss
INT8: 1.5KB per vector — 4x compression, ~1% recall drop

At 10 million vectors, INT8 quantization reduces memory from 60GB to 15GB, making the difference between fitting in RAM or not.

When to Upgrade from NumPy to a Vector DB

Consider switching from in-memory NumPy search to a vector database when:

Your corpus exceeds 50,000 documents and query latency degrades
You need metadata filtering (by date, user, category, etc.)
You need persistence that survives application restarts
Multiple services or users need to share the same index
You need to update or delete individual documents without re-indexing everything

Quick Check

Test your understanding of AI Engineering concepts from this lesson.

Lesson Recap

In this lesson you learned: brute-force NumPy search does not scale beyond tens of thousands of documents, HNSW enables fast approximate nearest neighbor search by navigating a hierarchical graph, and vector databases add metadata filtering, persistence, and CRUD operations on top of ANN indexes. Next up we set up Pinecone, the most popular managed vector database, and index our first documents.

자주 묻는 질문

“벡터 데이터베이스가 필요한 이유” 강의는 무료인가요?

네 — “벡터 데이터베이스가 필요한 이유” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 AI Engineering Academy 강의 전체를 잠금 해제할 수 있습니다. AI Engineering Academy 강의에는 총 4개의 강의가 포함되어 있습니다.

“벡터 데이터베이스가 필요한 이유”에서 뭘 배우나요?

무차별 대입 유사도 검색의 한계, HNSW와 같은 근사 최근접 이웃 알고리즘의 작동 방식, 벡터 데이터베이스가 운영 환경에서 해결하는 문제를 이해합니다. 브라우저에서 직접 실행하는 실습 코드로 AI Engineering Academy을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.

AI Engineering Academy을(를) 시작하는 데 경험이 필요한가요?

사전 경험은 필요하지 않습니다. CoddyKit의 AI Engineering Academy은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 1번째 강의입니다.

“벡터 데이터베이스가 필요한 이유” 강의는 얼마나 걸리나요?

대부분의 CoddyKit 강의는 약 5~10분이 소요됩니다. 각 강의는 간결하고 인터랙티브하여 꾸준한 진행이 가능하며, 웹과 앱에서 중단한 부분부터 바로 시작할 수 있습니다.

이 AI Engineering Academy 강의에서 코드를 작성하고 실행할 수 있나요?

네. 모든 AI Engineering Academy 강의에는 내장 코드 에디터가 포함되어 있으므로, 브라우저에서 바로 실제 코드를 작성하고 실행한 후 즉시 AI 피드백을 받을 수 있습니다 — 로컬 설정이 필요 없습니다.

이 강의의 모든 강의

← AI Engineering Academy(으)로 돌아가기