로컬에서 PDF 1,000개와 채팅하기: 테스트 예제를 넘어선 규모의 RAG

1,000개 이상의 문서에서 기본 RAG가 실패하는 이유

• RAM을 벗어난 인덱스: LanceDB, ChromaDB, FAISS는 모두 메모리 상주로 시작합니다. 인덱스가 사용 가능한 RAM(16 GB 노트북에서 일반적으로 5–8 GB 벡터)을 초과하면 디스크 읽기로 떨어지고 쿼리 p95 지연시간이 ~300ms에서 1–3초로 급증합니다.
• 코사인 전용은 드문 용어에서 실패합니다: 밀집 임베딩은 일반적이지 않은 고유명사, 약물 이름, 법령 번호, 코드 식별자를 과소평가합니다. "Section 230(c)(1)"에 대한 쿼리가 임베딩이 수치적 특수성을 구별할 수 없기 때문에 "Section 9"에 대한 청크를 검색합니다. BM25는 그것을 잡습니다. 순수 코사인 검색은 그것을 놓칩니다.
• 규모에서 top-4는 너무 좁습니다: 1,000개 청크에서 top-4는 적절한 재현율을 가집니다. 50,000개 청크에서 최적 청크는 종종 top-4 창 밖인 12–30 범위에 있습니다. 검색이 작동하는 것처럼 보이지만(응답이 그럴듯함) 잘못된 구절을 기반으로 합니다.
• 메타데이터 필터링이 없으면 인덱스가 낭비됩니다: 10,000개 문서 코퍼스에서 "Smith가 X에 대해 뭐라고 했습니까?"를 묻는 것은 인덱스의 모든 청크를 검색하지만, 시스템은 먼저 "Smith가 작성한 문서"로 사전 필터링해야 합니다. 기본 RAG에는 메타데이터별 사전 필터링 개념이 없습니다.
• 기본 512/0 청크 크기는 긴 컨텍스트를 분열시킵니다: PDF 단락과 법적 섹션은 512 토큰에 거의 맞지 않습니다. 기본 0 겹침은 청크 간 의미를 잃습니다. 1,000/200 조정이 중간 규모 코퍼스에서 이를 수정합니다. 5,000개 문서 이상에서는 계층적 청킹이 필요합니다.
• 업데이트 시 임베딩 드리프트: 원래 인덱스에서 3개월 후 1,000개의 새 PDF를 추가하면 sentence-transformer 모델 버전이 변경되었을 수 있습니다. 하나의 인덱스에 두 가지 모델 버전의 임베딩을 혼합하면 검색이 조용히 저하됩니다 — 모든 아키텍처는 임베더를 변경할 때 완전한 재인덱싱을 강제합니다.

아키텍처 결정 트리: 먼저 코퍼스 크기에 따라 선택

• 1,000개 미만의 문서(~5,000개 청크 미만): 청크 크기 1,000/겹침 200과 nomic-embed-text-v1.5 임베더가 있는 AnythingLLM Desktop. 맞춤 코드 없음. 설정을 위한 30분 단계별 가이드를 참조하십시오.
• 1,000–5,000개 문서(5k–25k개 청크): 계층적 인덱스(DocumentSummaryIndex + VectorStoreIndex)가 있는 완전 로컬 모드의 LlamaIndex, Ollama를 LLM 제공자로, nomic-embed-text-v1.5를 임베더로, LanceDB 또는 ChromaDB를 벡터 스토어로. ~Python 150줄, 장시간 실행 프로세스로 작동.
• 5,000–10,000개 문서(25k–50k개 청크): Ollama, ChromaDB, Whoosh 또는 Tantivy를 통한 BM25 하이브리드 검색, 상위 50개 후보에 BGE-reranker-v2-m3 재랭커가 있는 맞춤 스택. ~Python 300–400줄. 이 규모에서 재랭커는 필수입니다.
• 10,000개+ 문서(50k+ 청크): 페이로드 기반 메타데이터 필터링, Qdrant의 기본 희소 벡터를 사용한 하이브리드 검색, BGE-reranker-v2-m3, 문서 ID별 계층적 요약 인덱스가 있는 단일 노드 모드의 Ollama + Qdrant. 단일 사용자를 위한 프로덕션 등급 설정.
• 멀티 사용자(모든 규모): 위의 어느 것 앞에서든 Open WebUI, 또는 동일한 Qdrant + Ollama 백엔드를 감싸는 소형 FastAPI 래퍼. 멀티 사용자는 운영 초점(인증, 격리, 속도 제한)을 바꾸지만 검색 아키텍처는 바꾸지 않습니다.

아키텍처 비교 표

옵션 1: 조정된 AnythingLLM (100–1,000개 문서)

• LLM: Ollama를 통한 Llama 3.3 8B Q4_K_M (추론 중 5 GB RAM). 24 GB+ 시스템에서 Qwen 3 14B Q4가 합성을 눈에 띄게 향상시킵니다.
• 임베더: AnythingLLM 기본값에서 Ollama를 통한 nomic-embed-text-v1.5로 변경합니다. 기본 임베더가 "AnythingLLM이 확장되지 않는다"는 보고가 있는 주요 이유입니다.
• 청킹: 벡터 데이터베이스 설정의 워크스페이스별로 1,000 토큰과 200 토큰 겹침으로 설정합니다. 기본 512/0은 수십 개 이상의 문서가 있는 코퍼스에는 잘못되었습니다.
• Top-K: 기본 4에서 6–8로 증가합니다. 1,000개 문서에서 최적 청크는 종종 5–7 범위에 있으며 LLM은 약한 청크를 무시할 수 있습니다.
• 워크스페이스 파티셔닝: 문서 카테고리별로 워크스페이스를 만듭니다(기사, 계약서, 노트). 각 워크스페이스에는 별도로 인덱싱된 LanceDB가 있습니다. 워크스페이스 간 쿼리는 지원되지 않지만 워크스페이스별 재현율이 단일 대형 풀보다 훨씬 높습니다.

옵션 2: 로컬 LlamaIndex (1,000–5,000개 문서)

• 스택: Ollama + LlamaIndex + LanceDB(또는 ChromaDB) + OllamaEmbedding 어댑터를 통한 nomic-embed-text-v1.5. 디스크에 지속; 소형 FastAPI 래퍼 또는 CLI로 상호작용하는 장시간 실행 Python 프로세스로 작동합니다.
• VectorStoreIndex에 대한 DocumentSummaryIndex: LlamaIndex는 인덱싱 시 문서당 요약을 작성한 다음 검색 시 먼저 관련 문서를 선택(요약 검색)하고 그 다음에만 해당 문서 내에서 청크를 검색합니다. 가장 저렴한 계층적 검색 패턴입니다.
• 쿼리 라우팅: RouterQueryEngine은 팩트 검색 쿼리를 청크 인덱스로, 합성 쿼리를 요약 인덱스로 보냅니다. ~코드 30줄; 장문서 코퍼스에서 응답 품질이 두 배로 향상됩니다.
• 문장 창 검색: N개의 주변 문장과 함께 대상 문장을 검색하는 두 번째 선택적 인덱스. 답이 하나의 문장이지만 그 의미가 주변 단락에 의존하는 법적, 학문적 코퍼스에 유용합니다.
• 지속성: index.storage_context.persist(persist_dir=...)가 모든 것을 저장합니다. NVMe SSD에서 5,000개 문서 인덱스의 재로드 시간은 10–30초입니다.

# Minimal LlamaIndex local RAG with hierarchical indices (~30 lines)
from llama_index.core import VectorStoreIndex, DocumentSummaryIndex, SimpleDirectoryReader
from llama_index.embeddings.ollama import OllamaEmbedding
from llama_index.llms.ollama import Ollama
from llama_index.core import Settings

Settings.llm = Ollama(model="llama3.3:8b-instruct-q4_K_M", request_timeout=120)
Settings.embed_model = OllamaEmbedding(model_name="nomic-embed-text:latest")
Settings.chunk_size = 1000
Settings.chunk_overlap = 200

docs = SimpleDirectoryReader("./pdfs").load_data()

# Summary index for routing + chunk index for retrieval
summary_index = DocumentSummaryIndex.from_documents(docs)
chunk_index = VectorStoreIndex.from_documents(docs)

summary_index.storage_context.persist("./storage/summary")
chunk_index.storage_context.persist("./storage/chunks")

# At query time, route by question type
response = chunk_index.as_query_engine(similarity_top_k=8).query(
    "What sample size did Smith et al. use?"
)
print(response)

옵션 3: 맞춤형 Ollama + ChromaDB (5,000–10,000개 문서)

• 스택: Ollama + ChromaDB(서버 모드) + BM25를 위한 Whoosh 또는 Tantivy + BGE-reranker-v2-m3(~570 MB, CPU에서 50–100개 후보/초에 작동). 단일 Python 프로세스 또는 수집 + 쿼리 워커로 분할된 호스트.
• 검색 시 하이브리드 검색: BM25와 밀집 벡터 검색을 병렬로 실행하고, 각각의 상위 25개를 가져오고, 중복을 제거하고, 크로스 인코더로 결합된 상위 50개를 재랭킹합니다. 최종 top-K 6–8이 LLM으로 갑니다.
• ChromaDB 메타데이터 필드: 인덱싱 시 각 청크에 source_filename, page_number, document_type, author, year를 채웁니다. 쿼리 시 필터링(where={"document_type": "contract"})은 품질 손실 없이 검색 공간을 5–10배 줄입니다.
• 배치 인덱싱: ChromaDB는 32–128개 청크의 배치로 임베딩을 생성합니다. RTX 4070에서 BGE-reranker가 병목입니다(CPU에서 50–100개 후보/초; GPU에서 400+/초).
• 지속성: ChromaDB는 SQLite + Parquet 디렉토리에 씁니다. 디스크의 50,000개 청크 인덱스는 ~3–5 GB입니다. 백업은 디렉토리 복사입니다.

옵션 4: Ollama + Qdrant (10,000개+ 문서)

• 스택: Ollama + Qdrant(Docker, 단일 노드) + 기본 희소 벡터(Qdrant 1.10+에 내장된 BM25 동등물) + BGE-reranker-v2-m3 + 소형 Python 오케스트레이션 레이어.
• 기본 하이브리드: Qdrant는 동일한 컬렉션에서 밀집 + 희소 벡터를 지원하며 쿼리 시 가중 퓨전이 있습니다. 유지 관리할 별도의 BM25 프로세스가 없습니다.
• HNSW 조정: 50,000개+ 벡터에서 인덱스 구성을 위해 ef_construct를 200으로, m을 32로 증가시키고 쿼리 시 ef=128을 사용합니다. 기본값이 작동하지만 구성 속도를 위해 ~10%의 재현율을 교환합니다.
• 필터링을 위한 페이로드 스키마: Qdrant는 페이로드를 일급 시민으로 취급합니다. 서브밀리초 사전 필터링을 활성화하기 위해 author, document_type, year, tags를 키워드 페이로드로 인덱싱합니다.
• 계층적 검색: 두 개의 컬렉션을 유지합니다 — summaries(문서당 하나의 벡터)와 chunks(일반). 쿼리를 먼저 요약 컬렉션을 통해 라우팅한 다음 일치하는 문서 ID 내의 청크를 검색합니다.
• 지속성: Qdrant는 마운트된 단일 볼륨에 씁니다. 100,000개 청크 컬렉션은 페이로드 크기와 HNSW 설정에 따라 디스크에 ~6–12 GB를 차지합니다.

# Qdrant collection with dense + sparse vectors and metadata filtering
from qdrant_client import QdrantClient
from qdrant_client.models import (
    Distance, VectorParams, SparseVectorParams, SparseIndexParams
)

client = QdrantClient(host="localhost", port=6333)

client.create_collection(
    collection_name="docs",
    vectors_config={
        "dense": VectorParams(size=768, distance=Distance.COSINE),  # nomic-embed-text-v1.5
    },
    sparse_vectors_config={
        "bm25": SparseVectorParams(index=SparseIndexParams(on_disk=False)),
    },
)

# Query: hybrid search + payload filter, no separate BM25 process needed
from qdrant_client.models import Filter, FieldCondition, MatchValue, Prefetch

results = client.query_points(
    collection_name="docs",
    query=dense_vec,
    using="dense",
    prefetch=[
        Prefetch(query=sparse_vec, using="bm25", limit=25),
        Prefetch(query=dense_vec, using="dense", limit=25),
    ],
    query_filter=Filter(
        must=[FieldCondition(key="document_type", match=MatchValue(value="contract"))]
    ),
    limit=50,  # before rerank
)

하이브리드 검색: BM25 + 벡터가 둘 중 어느 것보다 뛰어납니다

• 밀집 단독이 실패하는 이유: 임베딩은 드문 토큰을 과소평가합니다. "RFC 9110 section 7.4" 또는 "MNDA-2024-0143" 같은 쿼리는 일반적인 IETF/계약 청크 근처에 임베딩됩니다. BM25는 정확한 식별자를 잡습니다. 순수 코사인 검색은 그것을 놓칩니다.
• BM25 단독이 실패하는 이유: 어휘 일치는 패러프레이즈를 놓칩니다. "계약을 어떻게 취소합니까?"라는 쿼리가 "해지 절차"라는 제목의 청크에 대해 밀집 공간에서 일치하지만 BM25에서 0점을 받습니다.
• Reciprocal Rank Fusion(RRF)이 표준 결합자입니다: 결과 목록 중 하나에 나타나는 각 청크에 대해 1/(60+rank_dense) + 1/(60+rank_bm25)로 점수를 매깁니다. 내림차순으로 정렬합니다. 60은 스무딩 상수입니다; 30–100 사이의 값이 실제로 작동합니다.
• 실용적인 레시피: 각 방법에서 상위 25개를 검색하고, RRF를 통해 결합하고, 상위 50개를 가져오고, 재랭커에 보내고, 그 다음 상위 6–8개를 LLM에 보냅니다. 이것이 1,000개 이상의 문서에서 모든 규모의 표준 프로덕션 파이프라인입니다.
• 저장소 비용: BM25 인덱스는 밀집 인덱스(동일 규모에서 ~500 MB–2 GB)에 비해 작습니다(10,000개 문서당 ~50–150 MB). 기존 밀집 스토어에 BM25를 추가하는 것은 저렴합니다.

재랭킹: 상위 N 정제 단계

• BGE-reranker-v2-m3(~570 MB, 다국어, Apache 2.0)는 2026년 5월의 기본 선택입니다. 현대 CPU에서 50–100개 후보/초에 작동합니다; GPU에서 400+/초. 상위 50개 재랭킹의 지연시간 비용은 CPU에서 ~200–500 ms, GPU에서 ~80–150 ms입니다.
• 크로스 인코더가 검색에서 이기는 이유: 밀집 임베딩은 쿼리와 문서를 독립적으로 인코딩하므로 모델이 그것들을 함께 볼 수 없습니다. 크로스 인코더는 `[CLS] 쿼리 [SEP] 후보 [SEP]`를 공동으로 읽고 쌍을 직접 점수 매깁니다. Recall@5는 일반적으로 15–25포인트 상승합니다.
• 재랭커를 주입할 위치: 하이브리드 검색 후, LLM 전. 하이브리드에서 상위 50개를 가져오고, 상위 6–8개로 재정렬하고, LLM에 컨텍스트로 보냅니다.
• 대안 — Cohere Rerank API: 더 높은 품질이지만 클라우드 호출이 필요합니다. 완전 로컬 스택의 경우 BGE-reranker-v2-m3가 실용적인 기본값입니다. mxbai-rerank-base-v2가 강력한 대안 후보입니다.
• 1,000개 미만 문서에서는 재랭커를 건너뛰어도 됩니다: 품질 향상이 지연시간 비용을 정당화하지 않습니다. 5,000개 문서 이상에서는 그것을 생략하면 ~15–25%의 응답이 잘못된 청크를 기반으로 하게 됩니다.

메타데이터 필터링: 검색 공간을 사전 축소

• 인덱싱 시 채울 범용 페이로드 필드: source_filename, page_number, document_type(기사/계약서/노트/위키), author, year, language, 더불어 도메인별 태그(예: case_number, project_id, client_id).
• 쿼리 시 사전 필터: "2024년 3분기 이사회 회의록이 가격에 대해 뭐라고 했습니까?" → 먼저 document_type=board_minutes AND year=2024 AND quarter=3으로 필터링하고, 전체 10,000개 대신 ~12개 문서 내에서 벡터 검색.
• 벡터 스토어 지원: Qdrant 페이로드, Weaviate 속성, ChromaDB 메타데이터, LanceDB 스키마 열이 모두 필터링을 지원합니다. 성능은 다양합니다 — 인덱싱된 필드의 Qdrant 페이로드 필터링은 서브밀리초; 100k개+ 청크에서 ChromaDB 메타데이터 필터링은 50–150 ms를 추가할 수 있습니다.
• 자동 메타데이터 추출: 법적 코퍼스의 경우 인덱싱 시 소형 LLM 단계가 문서당 사건 번호, 날짜, 당사자 이름을 추출할 수 있습니다. Llama 3.3 8B에서 문서당 ~30초가 소요됩니다; 수집당 한 번 실행됩니다.
• 하이브리드 검색과 결합: 페이로드 필터가 범위를 줄입니다 → 필터링된 세트 내에서 BM25 + 밀집 검색 → 재랭킹. 페이로드 필터는 모든 대형 RAG 시스템에서 가장 저렴한 5–10× 가속입니다.

계층적 검색: 먼저 요약, 그 다음 청크

• 문서당 요약: 인덱싱 시 LLM에게 각 문서의 100–200 토큰 요약을 작성하도록 요청합니다. 해당 요약의 임베딩을 별도의 summaries 컬렉션에 생성합니다. 비용은 Llama 3.3 8B에서 문서당 ~30–90초입니다.
• 2단계 검색: (1) 쿼리 임베딩을 생성하고 summaries를 검색하고 상위 5개 문서를 가져옵니다; (2) 해당 5개 문서 내에서 하이브리드 검색을 통해 상위 8개 청크를 검색합니다; (3) 필요하면 재랭킹 적용; (4) LLM에 보냅니다.
• 가장 도움이 되는 경우: 합성 및 멀티 문서 쿼리("이 기사들이 X를 어떻게 다루는지 비교합니다"). 팩트 검색("Smith가 어떤 값을 보고했습니까?")은 청크 인덱스만으로 잘 작동합니다 — 요약 우회가 품질 향상 없이 지연시간을 추가합니다.
• 비용 트레이드오프: 인덱스 저장소가 두 배 됩니다(요약은 작지만 인덱스 자체가 중복 인프라입니다). 비라우팅 쿼리의 지연시간이 두 배 됩니다. 이득은 10,000개+ 문서에서 노이즈 감소에 있습니다.
• LlamaIndex에 내장: DocumentSummaryIndex와 RouterQueryEngine이 30줄 구현입니다. ChromaDB 또는 Qdrant를 사용한 맞춤 Python은 ~80–120줄입니다.

100, 1,000, 10,000개 문서에서 측정된 벤치마크

저장소 크기 및 하드웨어 요구사항

• 1,000개 PDF(각 ~12페이지)의 원시 텍스트: ~50–150 MB의 추출된 텍스트. 밀도에 따라 매우 가변적입니다.
• 1,000개 문서에서의 벡터: HNSW 인덱스 오버헤드를 포함하여 디스크에 ~300–400 MB. HNSW 인덱스를 생략하고 브루트 포스 검색을 사용하면 ~120–180 MB(5,000개 문서 미만에서 허용).
• 10,000개 문서에서의 벡터: 디스크에 ~3–5 GB. HNSW 구성에는 현대 CPU에서 10–30분이 소요됩니다.
• 50,000개 문서에서의 벡터: 디스크에 ~15–25 GB. 인덱스 구성 시간이 병목입니다 — 일회성 CPU 작업에 2–4시간을 계획하십시오.
• 쿼리 중 RAM: 밀집 검색은 낮은 지연시간 쿼리를 위해 작업 메모리에 인덱스의 ~30–50%가 필요합니다. 5 GB 인덱스는 HNSW로 8–16 GB RAM으로 편안하게 쿼리됩니다; 브루트 포스는 인덱스 전체를 메모리에 필요합니다.
• 인덱싱 중 RAM: 임베딩 모델 크기(nomic-embed-text의 경우 ~600 MB)의 2–3배 플러스 배치당 텍스트로 급증합니다. 8 GB의 여유 RAM이 인덱싱 패스에 충분합니다.
• GPU vs CPU: 임베딩 처리량은 독립 GPU 또는 Apple Silicon에서 4–8배 빠릅니다. 10,000개+ 문서의 일회성 인덱싱에서 GPU가 1–3시간을 절약합니다. 쿼리 시 임베딩(한 번에 하나의 쿼리)에서는 CPU로 충분합니다.
• 디스크 유형이 중요합니다: NVMe SSD는 5,000개+ 문서에서 실용적인 최소 요건입니다. SATA SSD는 콜드 쿼리 지연시간에 30–100%를 추가합니다; 회전 디스크는 ~2,000개 문서 이상에서 사용할 수 없습니다.

증분 인덱싱 및 중복 제거

• 수집 시 정확한 해시 기반 중복 제거: 원시 파일 바이트의 SHA-256. 해시가 이미 인덱스에 있는 파일을 건너뜁니다. 저렴하고, 동일한 파일을 잡지만 거의 중복(동일한 스캔의 다른 OCR 패스, 형식 변환)을 놓칩니다.
• 콘텐츠 해시 중복 제거: 공백을 제거한 후 추출된 일반 텍스트의 SHA-256. 다른 파일 형식의 동일한 문서를 잡습니다. 수집에서 파일당 ~5 ms를 추가합니다.
• 거의 중복을 위한 MinHash: 동일한 문서의 여러 초안이 쌓이는 법적, 학문적 코퍼스의 경우 MinHash 서명(~128 바이트/문서)을 계산하고 기존 항목의 Jaccard 유사도 임계값 내에 있는 파일을 건너뜁니다.
• 문서 ID는 영구적입니다: 삭제 후 문서 ID를 재사용하지 마십시오. 벡터 스토어는 종종 잠시 고아 벡터를 유지합니다. ID 재사용은 조용한 혼란을 야기합니다. UUID 또는 해시 기반 ID를 사용하십시오.
• 임베더 변경 시 재임베딩: 모든 아키텍처는 임베딩 모델을 변경할 때 완전한 재인덱싱을 강제합니다. 10,000개 문서를 인덱싱하기 전에 최소 1년 동안 약정할 임베더 선택을 계획하십시오.
• 삭제: ChromaDB와 Qdrant는 ID별 포인트 삭제를 지원합니다. LanceDB는 디스크 공간을 회수하기 위한 압축 단계가 필요합니다 — 월별로 코퍼스의 ~5% 이상을 삭제하는 경우 주간 일정을 잡으십시오.

규모에서의 RAG 품질 모니터링

• 소형 골든 세트 구축: 올바른 답을 알고 있는 실제 사용에서 추출한 30–50개의 쿼리. 팩트 검색(5–10개), 합성(5–10개), 교차 문서(5–10개), 엣지 케이스(5–10개), 코퍼스에 없는 쿼리에 대한 알려진 미스(5–10개)를 포함하십시오.
• 쿼리당 세 가지 지표 추적: 검색 재현율(올바른 청크가 top-K에 나타났습니까?), 생성 충실도(응답이 청크와 일치합니까?), 거부율(시스템이 알려진 미스 쿼리에 대해 "코퍼스에 없습니다"를 올바르게 말합니까?).
• 각 중요한 변경 시 재실행: 새 수집 배치, 임베더 변경, 청크 크기 변경, 프롬프트 조정. 이전 실행과 결과를 비교합니다. 검색 재현율이나 응답이 변경된 쿼리를 표시합니다.
• 자동화된 평가 프레임워크로 Trulens 또는 RAGAS. 둘 다 로컬로 실행되고 LlamaIndex와 통합됩니다. 30–50개 쿼리의 수동 점수 매기기도 유효하며 종종 더 정확합니다.
• 지연시간 예산: 시간 경과에 따라 p50 및 p95 쿼리 지연시간을 추적합니다. p95에서 50% 급증은 일반적으로 인덱스가 RAM을 초과했음을 의미합니다 — 다음 아키텍처 수준으로 이동해야 한다는 조기 신호.

자주 묻는 질문

관련 읽기

• AnythingLLM vs PrivateGPT vs Open WebUI: 2026년 최고의 로컬 RAG — 확장하기 전에 데스크톱 RAG 플랫폼을 선택하기 위한 기본 컨텍스트.
• 2026년 로컬 RAG를 위한 최고의 임베딩 모델 — 임베더 선택은 10,000개 문서를 인덱싱하기 전에 가장 중요한 단일 결정입니다.
• 프라이빗 기업 데이터를 위한 로컬 RAG — 개인 규모 RAG가 기업 규정 준수 요구사항을 만날 때의 자연스러운 확장.
• 30분에 PDF에서 로컬 RAG 구축하기 (Ollama + AnythingLLM) — 확장 절벽에 도달하기 전의 기본 수준 설정.
• RAG 설명: AI 응답을 실제 데이터에 고정하는 방법 (2026) — RAG가 무엇인지와 각 검색 구성요소가 중요한 이유에 대한 개념적 기초.
• 2026년 로컬 LLM 하드웨어 가이드 — 10,000개+ 문서 코퍼스를 위한 하드웨어 크기 조정 참조.
• Power Local LLM 허브 — 클러스터 가이드의 전체 라이브러리.