LLM과 Token
3줄 요약
- LLM은 입력 token의 흐름을 바탕으로 다음 token을 예측해 출력을 만든다.
- token은 비용, latency, context 길이, 출력 제한을 이해하는 기본 단위다.
- 백엔드 개발자는 token을 문자열 길이가 아니라 운영 비용과 API 제한의 단위로 봐야 한다.
핵심 정리
- LLM은 Large Language Model의 약자로 텍스트와 멀티모달 입력을 처리해 다음 출력을 생성하는 모델이다.
- token은 모델이 처리하는 입력과 출력의 작은 조각이다. 한글, 영어, 코드, 공백에 따라 token 수는 다르게 계산될 수 있다.
- input token은 prompt, context, history, tool result를 포함하고 output token은 모델이 생성한 응답이다.
- token 수가 많아지면 비용과 latency가 늘고, context limit에 걸릴 수 있다.
- token budget은 AI 백엔드 설계에서 request size limit과 비슷한 역할을 한다.
헷갈리는 지점
- 글자 수와 token 수를 같게 생각하기 쉽다. 둘 다 길이를 나타내기 때문이다.
- 핵심은 tokenization 방식에 따라 같은 글자 수라도 token 수가 달라진다는 점이다.
- 운영에서는 provider usage 값을 기준으로 비용을 기록해야 한다.
- context window가 크면 token 문제를 덜 신경 써도 된다고 생각하기 쉽다.
- 핵심은 큰 context가 비용과 latency를 늘리고 관련 없는 정보를 섞을 수 있다는 점이다.
확인 질문
- token이 백엔드 운영에서 중요한 이유는 무엇인가?
- 비용, latency, context limit, output 제한, quota 계산의 기본 단위이기 때문이다.
- input token에는 무엇이 포함되는가?
- system instruction, user input, retrieved context, 대화 이력, tool result, schema 등이 포함될 수 있다.
Sampling과 결정성
3줄 요약
- LLM 출력은 확률적이며 temperature, top-p 같은 sampling 설정이 다양성과 일관성에 영향을 준다.
- 분류, 추출, JSON 생성은 낮은 다양성과 높은 일관성이 중요하다.
- 창작, 브레인스토밍, 초안 생성은 어느 정도 다양성이 도움이 될 수 있다.
핵심 정리
- temperature가 높으면 다양한 답이 나올 가능성이 커지고, 낮으면 더 일관된 답에 가까워진다.
- 같은 모델과 같은 입력이어도 완전히 같은 출력을 항상 보장한다고 보면 안 된다.
- 비즈니스 로직이 모델 결과에 의존할수록 deterministic한 설정과 schema validation, eval이 필요하다.
- 모델 버전 변경은 sampling 설정이 같아도 출력 차이를 만들 수 있다.
- 중요한 판단은 모델 한 번의 자연어 답변에만 맡기지 않는다.
헷갈리는 지점
- temperature를 0으로 두면 완전히 deterministic하다고 생각하기 쉽다.
- 핵심은 provider, 모델, backend 최적화, tie-breaking에 따라 완전 동일성을 보장하지 않을 수 있다는 점이다.
- 중요한 기능은 eval과 validation으로 안정성을 확보한다.
- 창의적 답변이 항상 좋은 답변이라고 생각하기 쉽다.
- 핵심은 업무 자동화에서는 창의성보다 일관성과 검증 가능성이 더 중요할 수 있다는 점이다.
확인 질문
- 분류나 정보 추출 기능에서는 어떤 sampling 성향이 적합한가?
- 낮은 temperature와 structured output처럼 일관성을 높이는 설정이 적합하다.
- 모델 출력의 결정성을 과신하면 안 되는 이유는 무엇인가?
- 모델과 provider 구현, 버전 변화로 같은 입력에서도 출력이 달라질 수 있기 때문이다.
Hallucination과 근거성
3줄 요약
- Hallucination은 모델이 그럴듯하지만 근거 없는 내용을 생성하는 문제다.
- RAG, source 표시, 모르는 경우의 행동, eval은 hallucination을 줄이지만 완전히 없애지는 못한다.
- 백엔드에서는 근거 없는 답변을 제품 실패로 보고 탐지와 완화 경로를 설계해야 한다.
핵심 정리
- LLM은 지식 DB가 아니라 생성 모델이다. 모르는 내용을 확신 있게 말할 수 있다.
- RAG는 외부 문서를 근거로 제공하지만 검색이 틀리거나 context가 부족하면 답변도 틀릴 수 있다.
- source id와 citation은 디버깅과 사용자 신뢰에 중요하다.
- “문서에서 확인되지 않습니다” 같은 실패 응답을 프롬프트와 제품 UX에 넣어야 한다.
- 중요한 영역은 human review, rule check, external validation을 함께 쓴다.
헷갈리는 지점
- hallucination은 모델 성능이 좋아지면 사라진다고 생각하기 쉽다.
- 핵심은 생성 모델의 구조상 근거성 검증은 별도 설계가 필요하다는 점이다.
- 좋은 모델도 잘못된 context를 받으면 잘못 답한다.
- RAG를 쓰면 hallucination이 해결된다고 생각하기 쉽다.
- 핵심은 RAG도 검색 품질과 context 조립에 의존한다는 점이다.
확인 질문
- hallucination을 줄이기 위한 백엔드 장치는 무엇인가?
- RAG, source 표시, context 검증, schema validation, eval, human review다.
- RAG를 써도 잘못된 답변이 나오는 이유는 무엇인가?
- 검색 결과가 틀리거나, 권한/최신성/컨텍스트 조립이 잘못되거나, 모델이 근거를 잘못 해석할 수 있기 때문이다.