LLM(Large Language Model) 완전 정리 - 개념부터 활용까지
LLM의 핵심 개념, Transformer 아키텍처, 학습 과정, 프롬프트 엔지니어링, RAG까지 체계적으로 정리합니다.
여러분이 평생 읽을 수 있는 모든 책·뉴스·웹 페이지를 통째로 읽은 뒤, "다음에 올 단어가 무엇인지" 맞히는 훈련을 수억 번 반복한다면 어떻게 될까요? LLM(Large Language Model)은 바로 그런 방식으로 탄생한 모델입니다. 단어 하나하나를 예측하는 과정에서 언어의 구조, 사실, 논리 추론 능력까지 함께 갖추게 됩니다.
이 글에서 배우는 것
- Transformer·Attention·Multi-Head Attention 이 실제로 무엇을 하는지
- 사전 학습, 미세 조정(Fine-tuning), RLHF 의 단계별 의미
- 토큰화와 컨텍스트 윈도우가 API 비용과 성능에 미치는 영향
- Zero-shot, Few-shot, Chain-of-Thought 프롬프트 엔지니어링 기법
- RAG 의 구조와 기업 환경에서의 도입 고려사항
이 글에서는 LLM의 핵심 개념부터 실제 활용까지 체계적으로 정리합니다.
1. LLM이란 무엇인가
정의와 등장 배경
LLM(Large Language Model)은 수십억~수천억 개의 파라미터를 가진 딥러닝 모델로, 대규모 텍스트 코퍼스를 학습하여 자연어를 이해하고 생성하는 능력을 갖춘 모델입니다.
한 문장으로: LLM 은 "다음 단어 맞히기" 를 반복하다 보니 언어 이해·추론·생성 능력까지 갖추게 된 모델입니다.
LLM 의 등장 배경을 시간순으로 살펴보면 기술이 얼마나 빠르게 발전했는지 실감할 수 있습니다.
| 시기 | 기술 | 특징 |
|---|---|---|
| 2017 | Transformer 논문 발표 | "Attention Is All You Need" — 병렬 처리 가능한 새로운 아키텍처 |
| 2018 | GPT-1 / BERT | 사전 학습(Pre-training) + 미세 조정(Fine-tuning) 패러다임 확립 |
| 2020 | GPT-3 (175B 파라미터) | Few-shot 학습 능력 입증, 범용 언어 모델의 가능성 제시 |
| 2022 | ChatGPT | 대화형 AI의 대중화, RLHF 기법 적용 |
| 2023~2024 | GPT-4, Claude, Gemini, LLaMA | 멀티모달, 긴 컨텍스트, 오픈소스 모델 경쟁 |
| 2025~2026 | Claude 4, GPT-5 등 | 에이전트 기반 자율 작업, 100만+ 토큰 컨텍스트 |
전통적인 NLP와의 차이점
"감성 분석 모델"과 "번역 모델"은 서로 다른 모델이었던 시절이 있습니다. LLM 은 그 패러다임을 완전히 바꿨습니다 — 하나의 모델이 프롬프트 하나로 번역도 하고, 코딩도 하고, 요약도 합니다.
| 구분 | 전통 NLP | LLM |
|---|---|---|
| 학습 방식 | 태스크별 개별 학습 | 대규모 사전 학습 → 미세 조정 |
| 데이터 | 레이블링된 소규모 데이터 | 인터넷 규모의 비정형 텍스트 |
| 모델 크기 | 수백만 파라미터 | 수십억~수천억 파라미터 |
| 범용성 | 단일 태스크 (감성 분석, 개체명 인식 등) | 번역, 요약, 코딩, 추론 등 다양한 태스크 수행 |
| 제로샷 성능 | 학습하지 않은 태스크 수행 불가 | 학습하지 않은 태스크도 프롬프트로 수행 가능 |
2. LLM의 핵심 기술: Transformer 아키텍처
Attention 메커니즘
"그 사람이 방에 들어왔다. 그는 문을 닫았다." 에서 "그는"이 "그 사람"을 가리킨다는 것을 어떻게 알 수 있을까요? Attention 이 바로 이 연결 고리를 찾아내는 메커니즘입니다. 기존 RNN/LSTM 의 순차 처리 한계를 극복하고, 긴 문장에서도 멀리 떨어진 단어 간의 관계를 효과적으로 포착합니다.
Attention의 핵심 수식은 다음과 같습니다:
Attention(Q, K, V) = softmax(QK^T / √d_k) × V
- Q (Query): 현재 토큰이 다른 토큰에 대해 묻는 질의
- K (Key): 각 토큰이 가진 특성 정보
- V (Value): 실제로 전달할 값
- √d_k: 스케일링 팩터 (차원의 제곱근)
Self-Attention과 Multi-Head Attention
Self-Attention 은 같은 문장 안의 모든 단어가 서로 "나와 얼마나 관련 있어?" 를 동시에 묻는 방식입니다. "그 고양이가 매트 위에 앉았다. 그것은 편해 보였다." 에서 "그것" 이 "고양이" 를 가리킨다는 것을 이렇게 파악합니다.
Multi-Head Attention 은 이 Self-Attention 을 여러 헤드로 병렬 수행하여 문법적 관계, 의미적 관계, 위치 관계 등 다양한 관점을 동시에 학습합니다. 마치 여러 명이 같은 문장을 각기 다른 시각으로 읽는 것과 같습니다.
MultiHead(Q, K, V) = Concat(head_1, ..., head_h) × W_O
각 head_i = Attention(QW_i^Q, KW_i^K, VW_i^V)
예를 들어, 8개의 헤드가 있다면 각 헤드는 문법적 관계, 의미적 관계, 위치 관계 등 서로 다른 패턴을 독립적으로 학습합니다.
Encoder vs Decoder 구조
Transformer 아키텍처는 어떤 부분을 쓰느냐에 따라 세 가지 변형이 있습니다. 현재 우리가 쓰는 대부분의 대화형 LLM 은 Decoder-only 구조입니다.
| 구조 | 대표 모델 | 특징 | 주요 용도 |
|---|---|---|---|
| Encoder-only | BERT, RoBERTa | 양방향 컨텍스트 이해 | 분류, 개체명 인식, 감성 분석 |
| Decoder-only | GPT, Claude, LLaMA | 왼쪽→오른쪽 자기회귀 생성 | 텍스트 생성, 대화, 코딩 |
| Encoder-Decoder | T5, BART | 입력 이해 + 출력 생성 | 번역, 요약 |
현재 대부분의 LLM(GPT, Claude, LLaMA, Gemini 등)은 Decoder-only 구조를 채택하고 있습니다. 이 구조는 다음 토큰을 예측하는 자기회귀(Autoregressive) 방식으로 텍스트를 생성합니다.
3. LLM의 학습 과정
LLM 은 하루아침에 만들어지지 않습니다. 세 단계의 학습을 거치면서 점점 더 유용한 모델로 거듭납니다.
사전 학습 (Pre-training)
수십억 달러짜리 첫 번째 단계입니다. 인터넷, 도서, 논문 등 수 TB 의 텍스트를 읽으며 "다음 단어 맞히기" 를 반복합니다. 이 과정에서 언어 구조뿐 아니라 세상 지식까지 자연스럽게 흡수합니다.
학습 목표: 다음 토큰 예측 (Next Token Prediction)
입력: "오늘 날씨가 정말"
예측: "좋다" (확률 0.35), "덥다" (확률 0.20), "춥다" (확률 0.15), ...
사전 학습의 주요 특징:
- 데이터 규모: 수 TB(테라바이트)의 텍스트 데이터
- 연산 비용: 수천
수만 GPU로 수주수개월 학습 - 비지도 학습: 레이블링 없이 텍스트 자체에서 패턴 학습
- 비용: 대형 모델 기준 수백만~수천만 달러
미세 조정 (Fine-tuning)
사전 학습된 모델은 백과사전처럼 지식이 많지만, 특정 작업을 잘 하도록 추가로 훈련하는 것이 미세 조정입니다. 전체를 다시 학습하는 Full Fine-tuning 부터 소비자급 GPU 에서도 가능한 QLoRA 까지 다양한 방법이 있습니다.
| 방식 | 설명 | 장점 |
|---|---|---|
| Full Fine-tuning | 모든 파라미터 업데이트 | 최고 성능 가능 |
| LoRA (Low-Rank Adaptation) | 일부 저랭크 행렬만 학습 | 적은 메모리, 빠른 학습 |
| QLoRA | 양자화 + LoRA | 소비자급 GPU에서도 가능 |
| Instruction Tuning | 지시-응답 쌍으로 학습 | 지시 따르기 능력 향상 |
# LoRA를 이용한 미세 조정 예시 (Hugging Face PEFT)
from peft import LoraConfig, get_peft_model
lora_config = LoraConfig(
r=16, # 저랭크 차원
lora_alpha=32, # 스케일링 팩터
target_modules=["q_proj", "v_proj"], # 적용할 레이어
lora_dropout=0.05,
task_type="CAUSAL_LM"
)
model = get_peft_model(base_model, lora_config)
# 전체 파라미터 대비 약 0.1%만 학습RLHF (Reinforcement Learning from Human Feedback)
"유용하고, 해롭지 않고, 정직한" 모델을 만들기 위해 사람이 직접 응답을 평가하고, 그 피드백으로 모델을 다듬는 과정이 RLHF 입니다. ChatGPT 가 등장했을 때 "말 잘 듣는다" 고 느꼈다면 RLHF 덕분입니다.
RLHF 3단계 프로세스:
- SFT (Supervised Fine-Tuning): 고품질 대화 데이터로 지도 학습
- Reward Model 학습: 사람이 평가한 응답 선호도를 학습하는 보상 모델 구축
- PPO (Proximal Policy Optimization): 보상 모델을 기반으로 강화학습 수행
참고: 최근에는 RLHF 외에도 DPO(Direct Preference Optimization), RLAIF(AI Feedback을 이용한 강화학습) 등 다양한 정렬(Alignment) 기법이 연구되고 있습니다.
4. 토큰화(Tokenization)와 임베딩(Embedding)
토큰화 방식
모델은 텍스트를 그대로 읽지 않습니다. 먼저 텍스트를 "토큰" 이라는 작은 조각으로 나눕니다. 이 조각이 API 비용의 기준이 되므로 실용적으로 중요합니다. 한국어는 영어보다 2~3배 더 많은 토큰을 사용하는 점을 기억해 두세요.
| 방식 | 설명 | 사용 모델 |
|---|---|---|
| BPE (Byte-Pair Encoding) | 빈도 높은 문자 쌍을 반복적으로 병합 | GPT 시리즈 |
| SentencePiece | 언어 독립적 서브워드 토큰화 | LLaMA, T5 |
| WordPiece | BPE 변형, 우도 기반 병합 | BERT |
| Tiktoken | BPE 기반, OpenAI 최적화 구현 | GPT-3.5/4 |
토큰화 결과 예시:
# tiktoken 라이브러리를 이용한 토큰화 예시
import tiktoken
enc = tiktoken.encoding_for_model("gpt-4")
text = "Large Language Models are transforming AI"
tokens = enc.encode(text)
# [27050, 11688, 27972, 527, 46890, 15592] → 6개 토큰
# 한국어 토큰화
text_ko = "대규모 언어 모델은 AI를 변화시키고 있다"
tokens_ko = enc.encode(text_ko)
# 한국어는 영어 대비 약 2~3배 더 많은 토큰으로 분할됨참고: 한국어는 영어 대비 동일한 의미를 표현하는 데 더 많은 토큰을 사용하므로, API 비용과 컨텍스트 활용 효율에 영향을 줍니다.
벡터 임베딩의 개념
임베딩은 단어를 숫자 좌표로 변환하는 과정입니다. 의미가 비슷한 단어끼리 벡터 공간에서 가까이 모이는 덕분에, 모델이 "왕"과 "여왕"의 관계를 수학적으로 계산할 수 있습니다.
"왕" - "남자" + "여자" ≈ "여왕"
"서울" - "한국" + "일본" ≈ "도쿄"
LLM에서 임베딩의 역할:
- 입력 임베딩: 토큰 → 벡터 변환 (모델 입력)
- 위치 임베딩: 토큰의 순서 정보 인코딩
- 출력 임베딩: 벡터 → 토큰 확률 변환 (모델 출력)
컨텍스트 윈도우 (Context Window)
모델이 한 번에 "기억" 할 수 있는 텍스트의 양을 컨텍스트 윈도우라고 합니다. 창이 클수록 긴 문서를 한 번에 처리할 수 있지만, 연산 비용은 토큰 수의 제곱에 비례해 늘어납니다.
| 모델 | 컨텍스트 윈도우 | 비고 |
|---|---|---|
| GPT-3 | 4,096 토큰 | 약 3,000 단어 |
| GPT-4 | 128K 토큰 | 약 96,000 단어 |
| Claude 3.5 | 200K 토큰 | 약 150,000 단어 |
| Claude Opus 4 | 1M 토큰 | 약 750,000 단어 |
| Gemini 1.5 Pro | 1M 토큰 | 약 750,000 단어 |
컨텍스트 윈도우가 클수록 더 긴 문서를 한 번에 처리할 수 있지만, 연산 비용은 토큰 수의 제곱에 비례하여 증가합니다.
5. 주요 LLM 모델 비교
GPT 시리즈 (OpenAI)
ChatGPT 로 LLM 을 대중화시킨 OpenAI 의 시리즈입니다. 지금도 가장 널리 알려진 모델군입니다.
| 모델 | 파라미터 | 주요 특징 |
|---|---|---|
| GPT-3 | 175B | Few-shot 학습의 가능성 입증 |
| GPT-3.5 | 비공개 | ChatGPT의 기반, RLHF 적용 |
| GPT-4 | 비공개 (추정 1.7T MoE) | 멀티모달, 향상된 추론 능력 |
| GPT-4o | 비공개 | 음성/이미지 통합, 빠른 추론 |
Claude (Anthropic)
Anthropic의 Claude는 안전성과 유용성의 균형을 강조하는 모델입니다.
- Constitutional AI: 헌법적 AI 기법으로 안전성 확보
- 긴 컨텍스트: 최대 1M 토큰 지원
- 코딩 능력: 코드 생성, 분석, 디버깅에 강점
- 에이전트 활용: Claude Code 등 도구를 통한 자율적 작업 수행
오픈소스 모델
| 모델 | 개발사 | 파라미터 | 특징 |
|---|---|---|---|
| LLaMA 3 | Meta | 8B / 70B / 405B | 오픈소스, 상업적 사용 가능 |
| Mistral | Mistral AI | 7B / 8x7B (MoE) | 작은 크기 대비 높은 성능 |
| Gemma | 2B / 7B / 27B | 경량 모델, 다양한 크기 제공 | |
| Qwen 2.5 | Alibaba | 0.5B ~ 72B | 다국어, 코드, 수학에 강점 |
참고: MoE(Mixture of Experts)는 전체 파라미터 중 일부 전문가 네트워크만 활성화하여 효율적으로 추론하는 아키텍처입니다. 예를 들어, Mistral 8x7B는 총 46.7B 파라미터를 갖지만 추론 시에는 약 12.9B만 사용합니다.
6. 프롬프트 엔지니어링
프롬프트의 구조와 원칙
같은 모델도 프롬프트를 어떻게 작성하느냐에 따라 결과가 천지 차이입니다. 프롬프트 엔지니어링은 모델에게 무엇을, 어떻게 물어야 원하는 답이 나오는지 설계하는 기술입니다.
효과적인 프롬프트의 구성 요소:
- 역할 지정 (Role): 모델이 수행할 역할 정의
- 맥락 (Context): 배경 정보와 제약 조건
- 지시 (Instruction): 수행할 작업의 명확한 설명
- 예시 (Examples): 원하는 입출력 형태 제시
- 출력 형식 (Format): 응답 구조 지정 (JSON, 표, 목록 등)
Zero-shot / Few-shot / Chain-of-Thought
Zero-shot: 예시 없이 지시만으로 태스크 수행
다음 문장의 감성을 분석하세요: "이 제품 정말 최고입니다!"
→ 긍정
Few-shot: 소수의 예시를 포함하여 태스크 수행
문장: "배송이 빨라서 좋았어요" → 긍정
문장: "화면이 자주 꺼져요" → 부정
문장: "가격은 괜찮은데 품질이 별로예요" → ?
→ 부정
Chain-of-Thought (CoT): 단계별 추론 과정을 유도
Q: 가게에 사과 23개가 있었습니다. 8개를 팔고 12개를 새로 입고했습니다.
현재 사과는 몇 개인가요?
A: 단계별로 풀어보겠습니다.
1. 초기 사과: 23개
2. 판매 후: 23 - 8 = 15개
3. 입고 후: 15 + 12 = 27개
따라서 현재 사과는 27개입니다.
시스템 프롬프트와 역할 지정
시스템 프롬프트는 모델의 전반적인 행동 방식을 정의하며, 대화 시작 시 설정됩니다.
{
"messages": [
{
"role": "system",
"content": "당신은 10년 경력의 데이터 엔지니어입니다. 기술적 질문에 대해 정확하고 실용적인 답변을 제공하세요. 코드 예시를 포함해주세요."
},
{
"role": "user",
"content": "Spark에서 데이터 스큐 문제를 해결하는 방법은?"
}
]
}참고: 시스템 프롬프트는 모델에 따라 지원 방식이 다릅니다. Claude는
system파라미터를, GPT는systemrole 메시지를 사용합니다.
7. RAG (Retrieval-Augmented Generation)
RAG의 필요성과 구조
LLM 은 학습 데이터 이후의 정보를 모르고, 기업 내부 문서도 없습니다. RAG 는 이 한계를 "오픈북 시험" 방식으로 해결합니다 — 답하기 전에 관련 문서를 먼저 찾아보고 그 내용을 참고해서 답하는 거죠.
한 문장으로: RAG = 검색 + LLM 생성 — 모르는 것은 찾아보고 답한다.
LLM 단독 사용의 한계:
- 학습 데이터 이후의 최신 정보를 알 수 없음
- 기업 내부 데이터나 도메인 지식 부재
- 할루시네이션(거짓 정보 생성) 위험
RAG 파이프라인 구조:
벡터 데이터베이스 연동
RAG 에서 검색을 담당하는 것이 벡터 데이터베이스입니다. 규모와 운영 부담에 맞는 옵션을 선택하세요.
| 벡터 DB | 특징 | 적합 환경 |
|---|---|---|
| Chroma | 경량, 임베디드, Python 친화적 | 프로토타입, 소규모 |
| Pinecone | 완전 관리형 SaaS | 운영 부담 최소화 |
| Weaviate | 하이브리드 검색 지원 | 키워드 + 벡터 검색 필요 시 |
| Milvus | 대규모 분산 처리 | 엔터프라이즈, 대용량 |
| pgvector | PostgreSQL 확장 | 기존 PostgreSQL 활용 시 |
# LangChain + Chroma를 이용한 간단한 RAG 구현 예시
from langchain.document_loaders import TextLoader
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain.embeddings import OpenAIEmbeddings
from langchain.vectorstores import Chroma
from langchain.chains import RetrievalQA
from langchain.llms import ChatOpenAI
# 1. 문서 로드 및 분할
loader = TextLoader("company_docs.txt")
docs = loader.load()
splitter = RecursiveCharacterTextSplitter(chunk_size=500, chunk_overlap=50)
chunks = splitter.split_documents(docs)
# 2. 벡터 DB에 저장
embeddings = OpenAIEmbeddings()
vectorstore = Chroma.from_documents(chunks, embeddings)
# 3. RAG 체인 구성
qa_chain = RetrievalQA.from_chain_type(
llm=ChatOpenAI(model="gpt-4"),
retriever=vectorstore.as_retriever(search_kwargs={"k": 3}),
return_source_documents=True
)
# 4. 질의
result = qa_chain.invoke({"query": "우리 회사의 데이터 보존 정책은?"})
print(result["result"])기업 환경에서의 RAG 파이프라인
실제 기업 환경에서 RAG 를 도입할 때는 단순히 벡터 DB 에 문서를 넣는 것 이상의 고려사항이 생깁니다:
- 청킹 전략: 문서를 적절한 크기로 분할 (고정 크기 vs 의미 기반)
- 임베딩 모델 선택: 다국어 지원, 도메인 특화 여부
- 하이브리드 검색: 벡터 검색 + 키워드 검색(BM25) 결합
- 리랭킹 (Re-ranking): 검색 결과를 LLM이나 Cross-Encoder로 재정렬
- 보안: 문서 접근 권한에 따른 검색 결과 필터링
- 평가: 검색 정확도(Recall@K)와 응답 품질 모니터링
8. LLM의 한계와 주의사항
할루시네이션 (Hallucination)
LLM 이 가장 잘 "거짓말" 하는 순간은 모를 때입니다. 모르면 "모른다" 고 해야 하는데, LLM 은 그럴듯한 답을 지어내는 경향이 있습니다. 이것이 할루시네이션입니다.
할루시네이션 유형:
- 사실적 오류: 존재하지 않는 논문이나 통계를 인용
- 논리적 오류: 그럴듯하지만 잘못된 추론
- 일관성 오류: 같은 대화 내에서 모순된 답변
완화 전략:
- RAG를 통한 외부 지식 기반 응답
- 출처 명시 요청 (Citation)
- 온도(Temperature) 파라미터 낮추기
- 응답 검증 파이프라인 구축
편향성 (Bias)
LLM은 학습 데이터에 포함된 편향을 반영할 수 있습니다.
- 사회적 편향: 성별, 인종, 문화적 고정관념
- 언어 편향: 영어 중심 학습으로 비영어권 성능 저하
- 시간적 편향: 학습 데이터의 시점에 따른 정보 편중
비용과 지연시간
LLM 운영에는 상당한 비용과 인프라가 필요합니다.
| 항목 | 고려사항 |
|---|---|
| API 비용 | 입력/출력 토큰 단위 과금 (모델별 상이) |
| 자체 호스팅 | GPU 서버 비용 (A100/H100 등) |
| 지연시간 | 토큰 생성 속도 (TTFT, TPS) |
| 동시 처리 | 배치 처리, 요청 큐 관리 |
| 최적화 | 양자화(Quantization), KV 캐시, 추측적 디코딩 |
참고: TTFT(Time to First Token)는 첫 토큰이 생성되기까지의 시간, TPS(Tokens Per Second)는 초당 생성 토큰 수를 의미합니다.
9. 엔터프라이즈 LLM 활용 사례
문서 요약 및 검색
- 회의록 자동 요약: 녹취록에서 핵심 내용, 액션 아이템 추출
- 기술 문서 검색: 사내 위키, Confluence 등에서 RAG 기반 검색
- 보고서 생성: 데이터 분석 결과를 자연어 보고서로 변환
코드 생성 및 리뷰
- 코드 자동 완성: IDE 통합 코드 어시스턴트 (Claude Code, GitHub Copilot 등)
- 코드 리뷰: PR 기반 자동 코드 리뷰 및 개선 사항 제안
- 레거시 코드 마이그레이션: 구 버전 코드를 최신 프레임워크로 변환
- 테스트 코드 생성: 단위 테스트, 통합 테스트 자동 생성
데이터 파이프라인 자동화
- SQL 생성: 자연어 질의를 SQL로 변환 (Text-to-SQL)
- ETL 파이프라인 설계: 데이터 흐름 설계 및 코드 생성
- 이상 탐지: 로그 분석을 통한 시스템 이상 패턴 감지
- 데이터 품질 검증: 스키마 변경 감지, 데이터 정합성 검사 자동화
마치며 — 핵심 요약
- LLM 은 "다음 단어 예측" 을 반복하며 언어 이해와 추론 능력을 동시에 갖춘 모델입니다.
- Transformer = Attention × 병렬 처리입니다. RNN 의 순차 처리 한계를 극복했고, 오늘날 대부분의 LLM 이 이 구조를 사용합니다.
- 사전 학습 → 미세 조정 → RLHF 의 세 단계를 거쳐 "유용하고 안전한" 모델이 만들어집니다.
- 한국어는 영어보다 약 2~3배 많은 토큰을 사용합니다. API 비용 설계 시 반드시 고려하세요.
- 할루시네이션을 막으려면 RAG 를 도입하고, 출처 명시를 요청하며, Temperature 를 낮추세요.
- 프롬프트 엔지니어링은 모델을 바꾸지 않고 성능을 높이는 가장 빠른 방법입니다. Zero-shot → Few-shot → CoT 순서로 시도해 보세요.
LLM 은 빠르게 발전하고 있습니다. 이 글의 개념을 이해해 두면 새로운 모델이 나와도 빠르게 파악할 수 있을 겁니다.
References
- Vaswani, A. et al. (2017). "Attention Is All You Need." NeurIPS
- Brown, T. et al. (2020). "Language Models are Few-Shot Learners." NeurIPS
- Ouyang, L. et al. (2022). "Training language models to follow instructions with human feedback." NeurIPS
- Hu, E. et al. (2021). "LoRA: Low-Rank Adaptation of Large Language Models." ICLR
- Lewis, P. et al. (2020). "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks." NeurIPS
- Wei, J. et al. (2022). "Chain-of-Thought Prompting Elicits Reasoning in Large Language Models." NeurIPS
- Touvron, H. et al. (2023). "LLaMA: Open and Efficient Foundation Language Models." arXiv
— Data Dynamics 엔지니어링 팀