LLM 용어사전

다른 페이지들이 링크로 물어오는 정의 백스톱. 각 항목: 2~4문장 정의 + "실무에서 왜 중요한가" 한 줄. 실무자(연구자 아님) 관점.

토큰 & 토크나이제이션

토큰은 LLM 이 실제로 읽고 생성하는 최소 단위 — 단어가 아니라 서브워드 조각(영어 기준 대략 단어의 ¾, ~750 단어 ≈ 1,000 토큰). 같은 모델은 항상 같은 토크나이저를 쓴다. 희귀어·코드·비영어·공백은 여러 토큰으로 쪼개져 카운트를 예측불가하게 부풀린다. 실무: 토큰이 과금·한도 단위다 — 비용·지연·컨텍스트 예산 전부 토큰으로 센다. 긴 프롬프트는 눈대중 말고 세라. ⚠️ Claude 토큰은 절대 tiktoken 으로 세지 마라 (OpenAI 토크나이저라 ~15~20% 과소집계) — /v1/messages/count_tokens 사용. 자세히 → tokens-and-context-windows

컨텍스트 윈도우

모델이 한 번에 고려할 수 있는 최대 토큰 수 — 시스템 프롬프트 + 대화이력 + 검색문서 + 사용자입력 + 모델 출력의 합. 요즘 ~8K~1M+. 넘으면 앞부분이 버려지거나 에러. 실무: 큰 창은 공짜 용량이 아니다 — 채운 만큼 비용·지연이 늘고, 아주 긴 컨텍스트 중간에 묻힌 정보에서 성능이 떨어진다("lost in the middle"). 버킷이 아니라 예산으로 다뤄라. 자세히 → tokens-and-context-windows

온도(Temperature) · top-p · 샘플링

토큰 선택의 무작위성 제어. Temperature(0~2)는 확률분포를 평탄/날카롭게: 낮으면(0~0.3) 거의 결정론적·집중, 높으면(0.8+) 다양·창의. top-p(뉴클리어스)는 누적확률 p 에 도달하는 최소 토큰집합으로 제한, top-k는 상위 k개로 제한. 실무: 추출·분류·코드·재현성엔 낮은 온도, 브레인스토밍·카피엔 높게. 온도 또는 top-p 하나만 세게 튜닝하라. 온도 0 도 프로덕션에선 완벽 결정론은 드묾.

임베딩 & 벡터 검색

임베딩은 텍스트의 의미를 담은 고정길이 숫자 벡터(예: 768/1536 차원) — 의미가 비슷하면 벡터공간에서 가까이 위치. 벡터 검색은 이를 벡터DB 에 저장하고 쿼리 임베딩에 코사인 유사도로 최근접을 반환 — 키워드가 아니라 의미로 검색. 실무: 대부분 RAG·시맨틱검색의 검색 엔진. 청킹 전략, 임베딩 모델 선택, 그리고 "유사도"를 맞출 뿐 "정확성/최신성"은 아니라는 점이 품질의 레버이자 함정. 자세히 → embeddings-and-vector-search

RAG (Retrieval-Augmented Generation)

답변 시점에 외부 지식을 주입: 쿼리로 관련 문서를 검색(보통 벡터검색) → 프롬프트에 붙임 → 그걸 근거로 답변. 재훈련 없이 사설·최신·도메인 데이터에 접근. 모델은 검색된 텍스트를 읽을 뿐 기억하지 않는다. 실무: "모델이 우리 데이터를 모른다"의 기본 해법이자 grounding+인용으로 hallucination 감소. 지식이 자주(주 단위) 바뀔 때 파인튜닝보다 낫다. 단 천장은 검색 품질 — 쓰레기를 검색하면 쓰레기를 답한다.

파인튜닝 vs 프롬프팅 vs RAG

셋은 각각 무엇을 바꾸는가로 이해: 프롬프팅=지시를 바꿈, RAG=모델이 볼 수 있는 지식을 바꿈, 파인튜닝=훈련을 이어 행동을 바꿈. 실무 규칙: 프롬프팅부터(시간 단위) → 모델이 훈련받지 못한 데이터가 필요하면 RAG → 둘 다 부족할 때만 파인튜닝(일관된 행동/포맷/톤/지연). 실무: 더 나은 프롬프트나 RAG 로 될 걸 파인튜닝하느라 돈을 태우는 팀이 흔하다 — 파인튜닝 파이프라인 TCO 는 잘 만든 RAG 의 10~50배일 수 있고 데이터가 변하면 썩는다.

할루시네이션(Hallucination)

유창하고 자신감 있고 틀린 출력 — 지어낸 사실·인용·API·인용문을 참인 양 제시. LLM 이 검증된 사실을 검색하는 게 아니라 그럴듯한 다음 토큰을 예측하기 때문 — "아는 것"과 "지어낸 것"의 내장 구분이 없다. 톤이 정답과 구별 불가라 가장 위험. 실무: 고위험 도메인에서 grounding(RAG)·인용·검증 없이 날 LLM 출력을 사실로 배포 마라. 완화는 엔지니어링(검색·툴·제약출력·eval)이지 끌 수 있는 설정이 아니다. 자세히 → hallucination

양자화(Quantization)

모델 가중치를 16비트에서 8/4비트 이하로 압축 — 메모리를 크게 줄이고 종종 추론 속도를 높이면서 품질 대부분 보존. 포맷: GGUF(CPU+GPU 하이브리드, llama.cpp/Ollama — Q4_K_M 이 크기/품질 균형 기본값), AWQ/GPTQ(GPU 서빙, vLLM). 실무: 큰 모델을 단일 GPU·노트북·절반 VRAM 에서 돌리게 하는 것 — "배포 불가"와 "로컬 구동"의 차이. 단 수학·코드·추론 중심 작업엔 공격적 4비트를 피하라(품질 손실이 여기서 가장 티남). 자세히 → quantization

추론 / 사고(Reasoning/Thinking) 모델

최종 답 전에 명시적 사고 사슬을 생성하도록 훈련된 모델(o-series, DeepSeek-R1, "thinking" 모드) — 한 방에 답하는("빠른 사고") 대신 추론-시점 연산을 더 써서("느린 사고") 단계별로 푼다. 수학·코딩·논리·다단계 계획에서 일반 모델을 크게 앞선다. 사고 트레이스는 숨겨지거나 요약되지만 그 사고 토큰에 과금된다. 실무: 진짜 어려운 다단계 문제에 쓰고, 단순 조회·포맷팅엔 쓰지 마라(느리고 비싸고 과잉사고). ⚠️ 프롬프팅 규칙이 뒤집힘 → prompting-cheatsheet · 자세히 → reasoning-models

멀티모달리티(Multimodality)

텍스트 외 이미지·오디오·비디오·문서를 공유 표현으로 받거나/생성하는 모델. 스크린샷·PDF·차트·사진을 프롬프트에 바로 넣고 물을 수 있다. 능력은 모델별·방향(이미지 이해 vs 생성)별로 크게 다름. 실무: 문서/영수증 파싱, 스크린샷 디버깅, 차트 읽기 같은 워크플로우를 연다(옛날엔 별도 OCR/비전 파이프라인 필요). 설계 전에 어떤 모달리티가 입력이고 출력인지 정확히 확인하라. 이미지도 토큰을 먹는다. 자세히 → multimodality

컨텍스트 엔지니어링(Context Engineering)

컨텍스트 창에 들어가는 모든 것(시스템 지시·검색문서·툴출력·대화상태·예시)을 체계적으로 조립해 모델이 딱 맞는 정보로 안정적으로 일하게 하는 규율. 프롬프트 엔지니어링이 사는 상위집합 — 프롬프팅이 개별 지시를 짓는다면, 컨텍스트 엔지니어링은 무엇이 창을 채우고 어떻게를 설계. Karpathy: "적절한 정보로 컨텍스트 창을 채우는 섬세한 예술이자 과학." 실무: 에이전트·프로덕션 실패의 대부분은 나쁜 프롬프트가 아니라 컨텍스트 실패(빠짐·낡음·부풀림·잘못된 순서). 단일턴 챗봇 넘어서는 모든 것의 핵심 기술. 자세히 → context-engineering

Evals (평가)

LLM 시스템이 실제로 제 일을 하는지 측정하는 체계적 테스트 — 비결정론적 소프트웨어의 테스트 스위트. 규칙기반/레퍼런스 체크(정확일치·정규식·파싱여부), LLM-as-judge(강한 모델로 채점/분류/비교 — 점수 또는 "어느 쪽이 나은가" 쌍대비교), 고위험/모호 케이스의 사람 검토. 실무: eval 없이는 "감으로" 배포하는 것 — 프롬프트 변경·모델 교체·새 RAG 인덱스가 나아졌는지 나빠졌는지 알 수 없다. LLM-as-judge 는 10만+ 출력을 몇 시간에 근제로 비용으로 평가. 튜닝 시작 전에 작은 eval 셋을 만들어라.

참고

• 프롬프팅 실전 → prompting-cheatsheet · 추론모델 → reasoning-vs-standard-models
• 모델 고르기 → model-choice-decision-guide · API → api-quickstart
• 개념 원본 → 2026-07-23-concepts-glossary-research