Local Vector Database

**로컬 벡터 데이터베이스(Local Vector Database)**는 벡터 임베딩을 저장하고 유사도 검색을 수행하는 데이터베이스로, 서버 없이 로컬 환경에서 실행됩니다. AI/ML 애플리케이션에서 의미 기반 검색(semantic search)과 추천 시스템을 구현하는 핵심 인프라입니다.

주요 특징:

• 벡터 임베딩 저장 및 인덱싱
• 유사도 검색 (코사인 유사도, L2 거리 등)
• 로컬 파일 시스템 기반 (서버 불필요)
• Python/JavaScript 등 다양한 언어 지원

해당 개념이 필요한 이유

• 의미 기반 검색: 키워드 매칭이 아닌 문맥과 의미를 이해하는 검색
• RAG 구현: LLM에 외부 지식을 주입하여 hallucination 감소
• 빠른 프로토타이핑: 서버 설정 없이 로컬에서 즉시 개발 시작
• 데이터 주권: 민감한 데이터를 외부 서버로 전송하지 않음

AS-IS: 전통적인 키워드 검색

sequenceDiagram
    autonumber
    participant User
    participant App
    participant DB as Relational DB

    User->>App: "apple product"
    App->>DB: SELECT * WHERE text LIKE '%apple%'
    DB-->>App: "apple fruit", "apple pie"
    Note over App: "apple 회사" 제품은<br/>찾지 못함
    App-->>User: 부정확한 결과

TO-BE: 벡터 기반 의미 검색

sequenceDiagram
    autonumber
    participant User
    participant App
    participant Embed as Embedding Model
    participant VDB as Vector DB

    User->>App: "apple product"
    App->>Embed: Encode query
    Embed-->>App: [0.2, 0.8, ...]
    App->>VDB: Similarity search
    VDB-->>App: "iPhone", "MacBook", "iPad"
    Note over VDB: 의미적으로<br/>유사한 결과 반환
    App-->>User: 정확한 제품 정보

주요 로컬 벡터 DB 3종 비교

특징	LanceDB	Chroma	FAISS
개발사	LanceDB Inc.	Chroma	Meta AI Research
주요 용도	멀티모달 AI 애플리케이션	RAG 및 의미 검색	대규모 벡터 유사도 검색
데이터 포맷	Lance (columnar)	자체 포맷	In-memory indices
지원 언어	Python, JS, Rust	Python, JS	Python, C++
멀티모달 지원	✅ (텍스트, 이미지, 비디오 등)	⚠️ (주로 텍스트)	❌ (벡터만)
메타데이터 필터링	✅ SQL 쿼리 지원	✅	⚠️ (제한적)
Full-text 검색	✅	✅	❌
GPU 가속	✅	❌	✅
자동 버저닝	✅	❌	❌
Zero-copy	✅	❌	❌
클러스터링	❌	❌	✅
인덱스 타입	자체 + HNSW	자체	다양한 ANN 알고리즘
학습 곡선	중간	낮음 (가장 쉬움)	높음
확장성	Petabyte 규모	중소 규모	Billion 규모
메모리 효율	높음 (columnar)	중간	높음 (압축 지원)
라이선스	Apache 2.0	Apache 2.0	MIT

장단점 요약

LanceDB:

• ✅ 장점: 멀티모달, SQL 지원, 버저닝, 높은 확장성, columnar 포맷으로 분석 친화적
• ❌ 단점: 상대적으로 새로운 프로젝트, 커뮤니티 규모 작음, 클러스터링 미지원

Chroma:

• ✅ 장점: 가장 쉬운 사용법, 자동 임베딩 생성, LangChain/LlamaIndex 통합, 빠른 프로토타이핑
• ❌ 단점: 대규모 데이터 처리 제한적, GPU 가속 없음, 멀티모달 지원 약함

FAISS:

• ✅ 장점: 검증된 성능, 다양한 인덱스 알고리즘, GPU 가속, 클러스터링, 대규모 처리
• ❌ 단점: 낮은 수준 API (복잡함), 메타데이터 필터링 약함, 벡터만 저장 가능

LanceDB 심층 분석

아키텍처: Lance Columnar Format

LanceDB는 Lance 데이터 포맷을 기반으로 합니다. Lance는 Apache Arrow와 Parquet에서 영감을 받은 columnar 포맷으로, 다음과 같은 특징이 있습니다:

graph TB
    subgraph "Lance Format"
        A[Row Data] --> B[Columnar Storage]
        B --> C[Vector Column]
        B --> D[Metadata Columns]
        B --> E[Media Columns]

        C --> F[Index: HNSW/IVF]
        D --> G[SQL Engine]
        E --> H[Zero-copy Access]
    end

    style C fill:#e1f5ff
    style D fill:#fff5e1
    style E fill:#ffe1f5

Columnar 포맷의 이점:

1. 선택적 읽기: 필요한 컬럼만 읽어 I/O 최소화
2. 압축 효율: 같은 타입 데이터가 연속되어 압축률 향상
3. 분석 최적화: SQL 쿼리와 집계 연산에 유리
4. Zero-copy: 메모리 복사 없이 데이터 접근

핵심 기능

1. 멀티모달 데이터 지원

# 텍스트, 이미지, 비디오를 하나의 테이블에
db = connect("./my-db")
table = create_table("multimodal", [
    {
        "text": "A cat playing piano",
        "image_uri": "s3://bucket/cat.jpg",
        "video_uri": "file://./cat_video.mp4",
        "metadata": {"category": "pets"}
    }
])

2. Hybrid Search (Vector + Full-text + SQL)

# 벡터 검색 + SQL 필터링 동시 수행
results = table.search("cute animals") \
    .where("metadata.category = 'pets'") \
    .limit(10)

3. 자동 버저닝

# 데이터 변경 시 자동으로 버전 관리
table.add([{"text": "new entry"}])  # version 1
table.add([{"text": "another entry"}])  # version 2
 
# 이전 버전으로 롤백 가능
table.checkout(version=1)

4. GPU 가속 인덱싱

# GPU로 수백만 벡터 인덱싱
table.create_index(
    metric="cosine",
    num_partitions=256,
    use_gpu=True  # GPU 가속
)

실제 사용 케이스

케이스 1: Markdown 문서 검색 (✅ LanceDB 적합)

시나리오: 사용자가 여러 개의 기술 문서(md 파일)를 저장하고, 나중에 “OAuth 인증 flow”에 대한 내용을 찾고 싶은 경우

sequenceDiagram
    autonumber
    participant User
    participant App
    participant Chunker as Document Chunker
    participant Embed as Embedding Model
    participant LDB as LanceDB
    participant LLM

    Note over User,LDB: 1단계: 문서 저장
    User->>App: auth.md 파일 업로드
    Note over App: 파일 내용:<br/>"OAuth 2.0 flow는<br/>Authorization Code Grant..."

    App->>Chunker: 문서 분할 요청
    Note over Chunker: 512 토큰 단위로<br/>chunk 생성
    Chunker-->>App: chunk 리스트 반환

    App->>Embed: 각 chunk 임베딩 생성
    Embed-->>App: 벡터 리스트 반환

    App->>LDB: 벡터 + 메타데이터 저장
    Note over LDB: vector, text, filename,<br/>chunk_id, timestamp
    LDB-->>App: 저장 완료

    Note over User,LLM: 2단계: 검색 및 답변 생성
    User->>App: "OAuth 인증 절차가 뭐였지?"

    App->>Embed: 질의 임베딩 생성
    Embed-->>App: 질의 벡터 반환

    App->>LDB: 유사도 검색 top 3
    Note over LDB: Cosine similarity 계산
    LDB-->>App: 관련 chunk 3개 반환<br/>similarity scores 포함

    App->>LLM: 질의 + 검색된 컨텍스트
    Note over LLM: RAG 패턴:<br/>retrieved context를<br/>prompt에 주입
    LLM-->>App: 생성된 답변

    App-->>User: 답변 + 출처

Pseudo 코드:

# === 1단계: 문서 저장 ===
db = connect("./docs-db")
model = load_embedding_model()
 
# Markdown 파일 읽기 및 chunk 생성
content = read_file("auth.md")
chunks = split_into_chunks(content, max_tokens=512)
 
# ##임베딩 생성 및 저장
data = []
for i, chunk in enumerate(chunks):
    vector = model.encode(chunk)
    data.append({
        "vector": vector,
        "text": chunk,
        "filename": "auth.md",
        "chunk_id": i
    })
 
table = db.create_table("documents", data)
 
# === 2단계: 검색 ===
query = "OAuth 인증 절차가 뭐였지?"
query_vector = model.encode(query)
 
results = table.search(query_vector).limit(3)
 
# LLM에 컨텍스트 전달
context = join_texts(results)
prompt = f"Context: {context}\n\nQuestion: {query}"
answer = llm.generate(prompt)

핵심 포인트:

1. 문서를 작은 chunk로 분할 (512 토큰 단위)
2. 각 chunk를 벡터로 변환하여 메타데이터와 함께 저장
3. 질의를 벡터로 변환 후 유사도 검색
4. 검색된 chunk를 LLM 컨텍스트로 활용 (RAG)

---

케이스 2: 통계 집계 질의 (❌ LanceDB 부적합)

시나리오: “이번주 TODO를 가장 많이 한 날은?” - 단순 통계 질의는 SQL이 더 효율적

sequenceDiagram
    autonumber
    participant User
    participant App
    participant RDB as PostgreSQL
    participant LDB as LanceDB

    User->>App: "이번주 TODO 가장 많이 한 날?"

    Note over App: 구조화된 데이터<br/>집계 쿼리 필요

    rect rgb(255, 200, 200)
        Note over App,LDB: ❌ LanceDB 사용 시 문제점
        App->>LDB: TODO 텍스트로 검색 시도
        Note over LDB: 의미 기반 검색은<br/>COUNT와 같은<br/>통계 연산 불가
        LDB-->>App: 부정확한 결과
    end

    rect rgb(200, 255, 200)
        Note over App,RDB: ✅ RDB 사용이 정답
        App->>RDB: SELECT date, COUNT(*)<br/>GROUP BY date<br/>ORDER BY count DESC
        Note over RDB: 인덱스 스캔<br/>집계 연산<br/>정렬
        RDB-->>App: date: 2024-01-10, count: 15
    end

    App-->>User: "월요일에 15개로 가장 많았습니다"

왜 LanceDB가 부적합한가:

요구사항	LanceDB	RDB (SQL)
집계 연산 (COUNT, SUM)	❌ 벡터 검색만 가능	✅ 최적화된 집계
GROUP BY	❌ 지원 안 함	✅ 네이티브 지원
정렬 (ORDER BY count)	❌ 유사도만 정렬	✅ 임의 컬럼 정렬
성능	느림 (불필요한 임베딩)	빠름 (인덱스 활용)
정확성	보장 안 됨	100% 정확

올바른 접근 (Pseudo 코드):

# ✅ RDB로 통계 처리
conn = connect_database()
 
result = conn.execute("""
    SELECT date, COUNT(*) as count
    FROM todos
    WHERE created_at >= NOW() - INTERVAL '7 days'
    GROUP BY date
    ORDER BY count DESC
    LIMIT 1
""")
 
# result: (2024-01-10, 15)

핵심 포인트:

• 집계/통계 질의는 구조화된 쿼리가 필요
• LanceDB는 의미 기반 검색에 특화, 집계 연산 미지원
• COUNT, SUM, GROUP BY → RDB가 정답

---

케이스 3: 하이브리드 검색 (✅ RDB + LanceDB)

시나리오: “지난달 생산성이 낮았던 이유와 개선 방안은?” - 통계 분석 + 문서 검색 결합

sequenceDiagram
    autonumber
    participant User
    participant App
    participant RDB as PostgreSQL
    participant LDB as LanceDB
    participant Embed as Embedding Model
    participant LLM

    User->>App: "지난달 생산성이 낮았던 이유와<br/>개선 방안은?"

    Note over App: 복합 질의:<br/>통계 분석 + 문서 검색

    rect rgb(230, 240, 255)
        Note over App,RDB: Part 1: 통계 데이터 수집
        App->>RDB: SELECT date, COUNT(*)<br/>AVG time<br/>GROUP BY date
        Note over RDB: 집계 쿼리로<br/>생산성 통계 계산
        RDB-->>App: 12월: 8개/일<br/>11월: 12개/일 (33% 감소)
    end

    rect rgb(255, 245, 230)
        Note over App,LDB: Part 2: 관련 보고서 검색
        App->>Embed: "생산성 감소 원인" 임베딩
        Embed-->>App: 질의 벡터 반환

        App->>LDB: 유사도 검색<br/>where type = report
        Note over LDB: Hybrid search:<br/>Vector + Metadata filter
        LDB-->>App: 관련 보고서 3개 반환
    end

    rect rgb(240, 255, 240)
        Note over App,LLM: Part 3: 통합 분석
        App->>LLM: 통계 데이터 + 보고서 문서
        Note over LLM: RAG + 통계 분석<br/>결합하여 답변 생성
        LLM-->>App: 원인 분석 + 개선 방안
    end

    App-->>User: 통합 답변 + 출처

Pseudo 코드:

# === Part 1: RDB에서 통계 수집 ===
conn = connect_database()
 
stats = conn.execute("""
    SELECT
        DATE_TRUNC('month', created_at) as month,
        COUNT(*) as todo_count,
        AVG(completion_time) as avg_time
    FROM todos
    WHERE created_at >= '2024-11-01'
    GROUP BY month
""")
 
# stats: [(2024-11, 360, 45.2), (2024-12, 248, 58.7)]
productivity_drop = calculate_drop_percentage(stats)
# -31.1%
 
# === Part 2: LanceDB에서 관련 문서 검색 ===
db = connect("./reports-db")
model = load_embedding_model()
 
query = "생산성 감소 원인 분석 개선 방안"
query_vector = model.encode(query)
 
table = db.open_table("reports")
results = table.search(query_vector) \
    .where("type = 'report' AND date >= '2024-12-01'") \
    .limit(3)
 
# === Part 3: LLM에 통합 정보 전달 ===
context = f"""
통계 데이터:
- 11월 TODO: 360개
- 12월 TODO: 248개
- 생산성 감소: {productivity_drop}%
 
관련 문서:
{join_texts(results)}
"""
 
prompt = f"{context}\n\nQuestion: 지난달 생산성이 낮았던 이유와 개선 방안은?"
answer = llm.generate(prompt)

하이브리드 접근의 장점:

구성 요소	역할	강점
RDB (SQL)	정량 데이터 제공	정확한 통계, 빠른 집계
LanceDB	정성 정보 검색	관련 문서, 맥락, 인사이트
LLM	통합 분석	데이터 + 문서 결합 해석

언제 하이브리드를 사용하는가:

• ✅ “왜?” 질문 - 통계 + 원인 분석
• ✅ “어떻게 개선?” - 데이터 + 과거 인사이트
• ✅ “무슨 일이 있었나?” - 팩트 + 맥락
• ❌ “몇 개?” - RDB만으로 충분
• ❌ “관련 문서는?” - LanceDB만으로 충분

핵심 포인트:

1. RDB: 구조화된 데이터의 통계/집계 (COUNT, AVG, GROUP BY)
2. LanceDB: 비구조화 문서의 의미 검색 (보고서, 회고록 등)
3. LLM: 양쪽 결과를 결합하여 통합 인사이트 생성

---

LanceDB vs 다른 DB: 선택 기준

LanceDB를 선택해야 하는 경우:

• 멀티모달 데이터 (텍스트 + 이미지 + 비디오) 처리
• SQL 쿼리와 벡터 검색을 동시에 사용
• 데이터 버저닝이 필요한 경우
• Petabyte 규모로 확장 가능성
• 분석 워크로드와 검색을 함께 수행

Chroma를 선택해야 하는 경우:

• 빠른 프로토타이핑과 간단한 API 필요
• LangChain/LlamaIndex 기반 RAG 구현
• 텍스트 중심 애플리케이션
• 학습 곡선 최소화

FAISS를 선택해야 하는 경우:

• 최고 수준의 검색 성능 필요
• 다양한 ANN 알고리즘 실험
• 벡터 클러스터링 필요
• 순수 벡터 검색에만 집중
• 메타데이터 필터링이 중요하지 않음

LanceDB 성능 특징

graph LR
    A[Query] --> B{Index Type}
    B -->|IVF| C[10ms<br/>99% recall]
    B -->|HNSW| D[1ms<br/>95% recall]
    B -->|Flat| E[100ms<br/>100% recall]

    style C fill:#90EE90
    style D fill:#FFD700
    style E fill:#FFB6C1

• 밀리초 단위 응답: 수억 개 벡터에서도 빠른 검색
• 확장성: 단일 서버에서 수십억 벡터 처리 가능
• 트레이드오프: 인덱스 타입에 따라 속도/정확도 조절

제약사항

1. 상대적으로 새로운 프로젝트: 생태계가 성숙하지 않음
2. 클러스터링 미지원: FAISS와 달리 벡터 클러스터링 없음
3. 문서 부족: 일부 고급 기능은 문서화가 미흡
4. 메모리 사용량: Columnar 포맷으로 인한 추가 메모리 필요

Q&A

Q) “OAuth” 같은 키워드를 추가해서 검색을 더 빠르고 정확하게 할 수는 없나요?

✅ 가능합니다! Hybrid Search (하이브리드 검색)를 사용하면 됩니다.

Hybrid Search란? 벡터 검색(의미 기반)과 키워드 검색(정확한 단어 매칭)을 결합하는 방식입니다.

방식: Vector DB 하나에만 저장

sequenceDiagram
    autonumber
    participant User
    participant App
    participant KeywordExtractor as Keyword Extractor
    participant Embed as Embedding Model
    participant LDB as LanceDB

    Note over User,LDB: 1단계: 데이터 저장 (텍스트 + 벡터 + 키워드)

    User->>App: 문서 업로드
    Note over App: "OAuth 2.0 flow는<br/>Authorization Code Grant..."

    App->>KeywordExtractor: 키워드 추출 요청
    Note over KeywordExtractor: TF-IDF, 품사 태깅 등
    KeywordExtractor-->>App: keywords 반환

    App->>Embed: 텍스트 임베딩 생성
    Embed-->>App: 벡터 반환

    App->>LDB: 텍스트 + 벡터 + 키워드 저장
    Note over LDB: text: "OAuth 2.0..."<br/>vector: [0.2, 0.8, ...]<br/>keywords: ["OAuth", "Authorization"]
    LDB-->>App: 저장 완료

    Note over User,LDB: 2단계: Hybrid Search

    User->>App: "OAuth 인증 방법"

    App->>Embed: 질의 임베딩 생성
    Embed-->>App: 질의 벡터 반환

    App->>LDB: Hybrid Search 실행
    Note over LDB: 1. 벡터 유사도 계산 (0.85)<br/>2. Full-text BM25 (12.3)<br/>3. 가중합: 0.7*0.85 + 0.3*0.8
    LDB-->>App: 결과 반환 (final_score 내림차순)

    App-->>User: "OAuth" 키워드 포함 + 의미 유사 문서

Pseudo 코드:

# === 1단계: 키워드 포함하여 저장 ===
db = connect("./docs-db")
model = load_embedding_model()
 
content = read_file("auth.md")
chunks = split_into_chunks(content, max_tokens=512)
 
data = []
for chunk in chunks:
    # 키워드 추출
    keywords = extract_keywords(chunk)  # ["OAuth", "Authorization", "Grant"]
 
    # 임베딩 생성
    vector = model.encode(chunk)
 
    data.append({
        "text": chunk,
        "vector": vector,
        "keywords": keywords  # 키워드 저장
    })
 
table = db.create_table("documents", data)
 
# === 2단계: Hybrid Search ===
query = "OAuth 인증 방법"
query_vector = model.encode(query)
 
# 방법 1: SQL 필터링 + 벡터 검색
results = table.search(query_vector) \
    .where("'OAuth' = ANY(keywords)") \
    .limit(10)
 
# 방법 2: 스코어 가중합
vector_results = table.search(query_vector)
fulltext_results = table.search_fulltext(query)
 
# 두 스코어 결합
final_results = []
for doc_id in all_doc_ids:
    vector_score = get_vector_score(doc_id)      # 0.85
    fulltext_score = get_fulltext_score(doc_id)  # 0.8 (normalized)
 
    final_score = 0.7 * vector_score + 0.3 * fulltext_score
    final_results.append((doc_id, final_score))
 
# 최종 점수로 정렬
final_results.sort(key=lambda x: x[1], reverse=True)

핵심 포인트:

• 의미는 비슷하지만 키워드가 없는 경우도 찾음 (벡터 검색)
• 정확한 키워드가 있는 경우 우선순위 상승 (Full-text 검색)
• 데이터 중복 저장 불필요 (Vector DB 하나에서 처리)
• 정확도(Precision)와 재현율(Recall) 모두 향상

구현 복잡도:

• LanceDB, Chroma: 내장 Full-text 검색 지원 → 간단
• FAISS: Full-text 미지원 → 별도 처리 필요

---

Q) 검색 결과가 어떤 문서에서 왔는지 출처를 표시할 수 있나요?

✅ 가능합니다! 메타데이터에 출처 정보를 저장하면 됩니다.

sequenceDiagram
    autonumber
    participant User
    participant App
    participant Parser as Document Parser
    participant Embed as Embedding Model
    participant LDB as LanceDB
    participant LLM

    Note over User,LDB: 1단계: 출처 메타데이터 포함하여 저장

    User->>App: 문서 업로드 (auth.md)

    App->>Parser: 문서 파싱 + 메타데이터 추출
    Note over Parser: 파일명, 줄 번호,<br/>섹션 제목, URL 추출
    Parser-->>App: chunks + 메타데이터

    App->>Embed: 각 chunk 임베딩 생성
    Embed-->>App: 벡터 리스트 반환

    App->>LDB: 벡터 + 텍스트 + 출처 메타데이터 저장
    Note over LDB: vector, text, filename,<br/>line_range, section_title,<br/>url, page_number
    LDB-->>App: 저장 완료

    Note over User,LLM: 2단계: 검색 + 출처 표시

    User->>App: "OAuth 인증 절차가 뭐였지?"

    App->>Embed: 질의 임베딩 생성
    Embed-->>App: 질의 벡터 반환

    App->>LDB: 유사도 검색
    LDB-->>App: 결과 + 출처 메타데이터

    Note over App: 출처 정보 포맷팅:<br/>파일명, 줄, 섹션, URL

    App->>LLM: 질의 + 컨텍스트 + 출처 번호
    Note over LLM: 답변 생성 시<br/>출처 번호 인용
    LLM-->>App: 답변 + [출처 1], [출처 2]

    App-->>User: 답변 + 출처 목록
    Note over User: 신뢰도 확인 가능<br/>원본 문서 직접 접근

Pseudo 코드:

# === 1단계: 출처 메타데이터 포함하여 저장 ===
db = connect("./docs-db")
model = load_embedding_model()
 
content = read_file("auth.md")
chunks = parse_with_metadata(content)  # 줄 번호, 섹션 포함
 
data = []
for chunk_info in chunks:
    vector = model.encode(chunk_info.text)
 
    data.append({
        "vector": vector,
        "text": chunk_info.text,
 
        # 출처 메타데이터
        "filename": "auth.md",
        "line_range": chunk_info.line_range,      # "45-67"
        "section_title": chunk_info.section,      # "## OAuth 2.0 Flow"
        "url": "https://docs.oauth.net/2.0/",
        "page_number": chunk_info.page            # PDF인 경우
    })
 
table = db.create_table("documents", data)
 
# === 2단계: 검색 + 출처 표시 ===
query = "OAuth 인증 절차가 뭐였지?"
query_vector = model.encode(query)
 
results = table.search(query_vector).limit(3)
 
# 출처 포함 컨텍스트 생성
context_with_sources = ""
for i, result in enumerate(results, 1):
    context_with_sources += f"""
[출처 {i}] {result.filename} ({result.line_range}줄, {result.section_title})
{result.text}
"""
 
# LLM 프롬프트
prompt = f"""
다음 문서를 참고하여 질문에 답변하세요.
답변 시 반드시 [출처 번호]를 명시하세요.
 
{context_with_sources}
 
질문: {query}
"""
 
answer = llm.generate(prompt)
 
# 사용자에게 표시
print(answer)
print("\n=== 참고 문서 ===")
for i, result in enumerate(results, 1):
    print(f"[{i}] {result.filename} ({result.line_range}줄)")
    print(f"    🔗 {result.url}")

출력 예시:

OAuth 인증은 Authorization Code Grant 방식을 사용합니다[출처 1].
토큰 전송 시 반드시 HTTPS를 사용해야 합니다[출처 2].

=== 참고 문서 ===
[1] auth.md (45-67줄)
    🔗 https://docs.oauth.net/2.0/

[2] security-guide.md (120-145줄)
    🔗 https://docs.example.com/security

핵심 포인트:

1. 메타데이터에 파일명, 줄 번호, 섹션, URL 저장
2. 검색 결과와 함께 출처 정보 반환
3. LLM 답변에 출처 번호 인용 포함
4. 사용자가 원본 문서를 직접 확인 가능 (신뢰도 향상)

---

참고 문서

• LanceDB GitHub
• Chroma GitHub
• FAISS GitHub