koriweb
95cd8bb891
- 코드 그라운딩: 기술 주제 문서의 '적용 사례'에 실제 레포 구현 위치
(file:line)+커밋 자동 주입 (예: 문서 청킹 전략→connectai/src/retrieval/chunker.ts).
멱등 마커(CODE-GROUNDING)로 재실행 시 갱신.
- MOC: 39개 클러스터 폴더에 _MOC.md 학습지도 생성(진입점+통찰 주석).
도구: Datacollect/scripts/{code_grounding,moc_generator}.mjs
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
98 lines
8.1 KiB
Markdown
98 lines
8.1 KiB
Markdown
---
|
|
id: llm
|
|
title: "LLM"
|
|
category: "10_Wiki/Topics"
|
|
status: "draft"
|
|
verification_status: "conceptual"
|
|
canonical_id: ""
|
|
aliases: ["Large Language Model", "거대 언어 모델"]
|
|
duplicate_of: ""
|
|
source_trust_level: "B"
|
|
confidence_score: 0.85
|
|
created_at: 2026-06-08
|
|
updated_at: 2026-06-08
|
|
review_reason: ""
|
|
merge_history: []
|
|
tags: ["research", "RAG 아키텍처 및 파이프라인 기초"]
|
|
raw_sources: ["NotebookLM Synthesis"]
|
|
applied_in: ["NVIDIA Generative AI Examples GitHub 리포지토리", "LangChain Framework", "LlamaIndex Framework"]
|
|
github_commit: ""
|
|
---
|
|
|
|
# [[LLM]]
|
|
|
|
## 🎯 한 줄 통찰 (One-line insight)
|
|
고정된 파라미터 지식의 한계를 넘어, 실시간으로 검색된 외부 컨텍스트를 합성하여 신뢰할 수 있는 응답을 생성하는 RAG 시스템의 핵심 생성 엔진 [1, 2].
|
|
|
|
## 🧠 핵심 개념 (Core concepts)
|
|
1. **생성기 (Generator):** 사용자 쿼리와 검색된 관련 문서를 결합하여 문맥적으로 적절한 응답을 도출하는 RAG의 최종 단계 구성 요소이다 [1, 3, 4].
|
|
2. **지식 제한 시점 (Knowledge Cutoff):** 모델 학습에 사용된 데이터의 마지막 시점 이후 정보에 대해서는 알지 못하는 태생적 한계를 의미한다 [2, 5, 6].
|
|
3. **할루시네이션 (Hallucination):** 배경 지식이 부족한 상태에서 사실과 다른 그럴듯한 거짓 정보를 생성하는 현상이다 [2, 7].
|
|
4. **컨텍스트 창 (Context Window):** 모델이 한 번에 처리할 수 있는 데이터(토큰)의 양으로, 정보 주입의 물리적 한계로 작용한다 [8, 9].
|
|
|
|
## 🧩 추출된 패턴 (Extracted patterns)
|
|
- **증강을 통한 생성 (Generation via Augmentation):** 단순 추론이 아닌, 검색된(Retrieved) 데이터를 프롬프트에 주입(Augmented)하여 생성(Generation) 효율을 극대화하는 패턴이다 [4, 10, 11].
|
|
- **데이터 비매개변수화 (Non-parametric Memory):** 모델의 가중치를 수정하지 않고 외부 지식 베이스를 활용하여 지식을 업데이트하는 설계 방식이다 [2, 12].
|
|
- **성능-비용 트레이드오프:** 모델의 크기와 컨텍스트 창 용량에 따라 추론 비용과 정확도 사이의 균형을 맞추는 의사결정 패턴이 관찰된다 [13-15].
|
|
|
|
## 📖 세부 내용 (Details)
|
|
LLM은 방대한 공개 도메인 데이터를 학습하여 인간과 유사한 자연어 생성 능력을 갖추었으나, 조직 내부의 독점 데이터나 실시간 정보에는 접근할 수 없는 제약이 있다 [2, 16]. RAG 아키텍처 내에서 LLM은 **Generator** 역할을 수행하며, **Retriever**가 외부 지식 데이터베이스(벡터 저장소 등)에서 찾아온 관련 청크들을 컨텍스트로 주입받아 이를 기반으로 '사실에 근거한 답변(Grounded Response)'을 생성한다 [1, 17, 18].
|
|
|
|
이러한 방식은 고가의 모델 재학습이나 미세 조정(Fine-tuning) 없이도 최신 지식을 반영할 수 있게 하며, 출처(Citation)를 명시하여 사용자의 신뢰를 높일 수 있다 [7, 19, 20]. 특히 기업 환경에서는 보안이 중요한 독점 데이터를 모델 가중치에 포함하지 않고도 안전하게 활용할 수 있는 이점을 제공한다 [21-23].
|
|
|
|
LLM의 성능을 극대화하기 위해 **프롬프트 엔지니어링** 기술이 사용되며, "제공된 컨텍스트 내에서만 답변하라"는 식의 제약 조건을 통해 할루시네이션을 억제한다 [24-26]. 최근에는 수백만 토큰을 처리할 수 있는 긴 컨텍스트 모델이 등장하고 있으나, 여전히 효율성과 비용 측면에서 RAG를 통한 정밀한 정보 주입이 필수적이다 [27-29].
|
|
|
|
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
|
- **컨텍스트 창의 확장:** 최근 Llama 4 Scout 등은 최대 1,000만 토큰의 컨텍스트 창을 지원하며 RAG의 필요성에 대한 논의를 불러일으키고 있으나, 비용 및 'Lost in the Middle(정보가 중간에 위치할 때의 성능 저하)' 현상으로 인해 여전히 청킹과 검색 전략은 유효하다 [27, 30, 31].
|
|
- **모델 크기와 할루시네이션:** GPT-4o와 같은 더 강력한 모델이 오히려parametric memory(학습된 지식)를 과도하게 사용하여 더 자신감 있게 할루시네이션을 유발할 수 있다는 관찰 결과가 있으며, 이 경우 오히려 경량 모델(SLM)이 신뢰성 면에서 유리할 수 있다 [32, 33].
|
|
|
|
## 🛠️ 적용 사례 (Applied in summary)
|
|
- **NVIDIA Generative AI Examples:** NGC 카탈로그의 컨테이너를 통해 가속화된 RAG 파이프라인에서 LLM이 추론 마이크로서비스로 구동된다 [34, 35].
|
|
- **LangChain:** `RetrievalQA` 체인을 통해 LLM과 리트리버를 결합하여 워크플로우를 자동화한다 [36, 37].
|
|
- **LlamaIndex:** `VectorStoreIndex`의 `as_query_engine()` 메서드를 통해 인덱스와 LLM을 직접 연결하여 응답을 합성한다 [36, 38, 39].
|
|
- **JetBlue BlueBot:** 기업 데이터를 보강한 오픈 소스 모델을 사용하여 부서별 권한에 따른 맞춤형 정보를 제공한다 [40].
|
|
|
|
## ✅ 검증 상태 및 신뢰도
|
|
- **상태:** draft
|
|
- **검증 단계:** conceptual (실제 기업용 챗봇 및 프레임워크 적용 사례 다수 존재)
|
|
- **출처 신뢰도:** B (IBM, NVIDIA, Databricks 등 공식 기술 블로그 및 전문 보고서 기반)
|
|
- **중복 검사 결과:** 신규 생성 (New discovery)
|
|
|
|
|
|
## 🔗 관련 문서 링크 (Related document links)
|
|
|
|
### 상위/유사 개념
|
|
#### [아키텍처/기반 기술]
|
|
- [[RAG]]
|
|
- 연결 이유: LLM의 지식 제한과 할루시네이션을 해결하는 상위 시스템 아키텍처임 [2, 41].
|
|
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: LLM이 외부 지식을 수용하는 구조적 메커니즘 [17].
|
|
- [[임베딩 모델]]
|
|
- 연결 이유: 텍스트를 LLM이 이해하고 검색할 수 있는 수치적 벡터로 변환하는 기초 기술임 [42, 43].
|
|
|
|
#### [구현/활용 도구]
|
|
- [[LangChain]]
|
|
- 연결 이유: LLM을 다양한 도구 및 데이터 소스와 연결하는 대표적인 오케스트레이션 프레임워크임 [44, 45].
|
|
- [[LlamaIndex]]
|
|
- 연결 이유: 데이터 수집 및 인덱싱을 통해 LLM을 데이터 소스에 최적화하여 연결함 [39, 46].
|
|
|
|
### 심층 후속 질문 (Deeper Research Questions)
|
|
- LLM의 컨텍스트 창이 무한대에 가까워질 경우, RAG 아키텍처는 어떻게 진화할 것인가? [27, 47]
|
|
- 미세 조정(Fine-tuning)과 RAG를 결합했을 때 얻을 수 있는 시너지는 무엇인가? [13, 48, 49]
|
|
- LLM 판사(LLM-as-a-judge)를 활용한 평가 방식의 신뢰도는 어떻게 보장하는가? [50-52]
|
|
- 'Lost in the Middle' 현상을 극복하기 위한 청킹 및 프롬프트 전략은 무엇인가? [31, 53]
|
|
- 멀티모달 LLM이 RAG 파이프라인에서 이미지와 텍스트를 처리하는 방식은 어떻게 다른가? [54, 55]
|
|
|
|
### 실무 적용 맥락 (Practical Application Contexts)
|
|
- **Implementation:** 프레임워크(LangChain, LlamaIndex)를 사용하여 LLM API를 엔드포인트로 연결하고 프롬프트 템플릿을 구성함 [36, 38, 56].
|
|
- **System Design:** 지연 시간과 비용을 고려하여 단순 쿼리는 LLM 자체 지식을 사용하고, 복잡한 쿼리는 RAG를 거치는 어댑티브 라우팅 설계 가능 [57, 58].
|
|
- **Operation / Maintenance:** 모델 업데이트 대신 외부 지식 베이스를 갱신하여 최신성을 유지하며, RAGAS 등의 도구로 정기적인 성능 모니터링 수행 [20, 59, 60].
|
|
- **Learning Path:** LLM의 기본 동작 원리 이해 → 프롬프트 엔지니어링 → RAG 파이프라인 구축 → 모델 평가 및 최적화 순으로 학습 권장 [61, 62].
|
|
|
|
### 인접 주변 주제 (Adjacent Topics)
|
|
- [[벡터 데이터베이스]]
|
|
- 확장 방향: LLM이 효율적으로 정보를 검색할 수 있는 저장소의 성능 비교 및 선택 가이드 [1, 12].
|
|
- [[에이전틱 RAG]]
|
|
- 확장 방향: LLM이 스스로 검색 여부와 도구 사용을 결정하는 자율적 제어 루프 [63, 64].
|
|
|
|
## 📝 변경 이력 (Change history)
|
|
- 2026-06-08: Initial draft generated via Datacollector_MAC P-Reinforce engine. (RAG 아키텍처 및 파이프라인 기초 연구 데이터 기반 합성) |