LLM 면접은 암기가 아니라 분포를 말하는 시험이다
최근 LLM 면접을 준비하면 묘한 차이가 보인다. 공부한 단어는 많다. temperature, top-k, top-p, BLEU, RAG, fine-tuning. 단어만 보면 다 아는 것 같다. 문제는 면접장에서다. 한 줄 정의로 답하면 바로 부족하다.
“temperature가 뭐예요?”
“무작위성을 조절하는 파라미터입니다.”
맞는 말이다. 문제는 그 다음이다. 면접관이 묻는 건 단어 뜻이 아니다. 그 값이 확률분포를 어떻게 바꾸는지, 어떤 제품에서는 낮춰야 하는지, 어떤 작업에서는 조금 올릴 수 있는지, 그 선택이 환각·반복·비용에 어떤 영향을 주는지까지 보고 싶어 한다.
Habr의 LLM 면접 체크리스트는 이 지점을 정확히 찌른다. 언어 모델링, 다음 토큰 예측, greedy decoding, temperature, top-k, top-p, BLEU, ROUGE, perplexity, LLM-as-a-Judge를 다룬다. 핵심은 용어 목록이 아니다. “이걸 아느냐”보다 “확률분포 위에서 실제로 무슨 일이 일어나는지 설명할 수 있느냐”에 가깝다.
최근 AI Engineer 면접 글과 커뮤니티 경험담까지 보면 질문 의도는 더 분명해진다. 요즘 면접은 “트랜스포머 구조를 설명해보라”에서 끝나지 않는다. foundation model 위에 신뢰 가능한 시스템을 만들 수 있는지, RAG가 왜 틀리는지, eval을 어떻게 설계하는지, 비용과 지연 시간을 어떻게 줄이는지, 에이전트가 멋대로 결제하지 않게 어떻게 막는지를 묻는다.
기준은 간단하다.
면접 답변은 정의에서 끝나면 안 된다. 선택, 트레이드오프, 실패 모드, 측정 방법까지 같이 말해야 한다.
LLM은 한 번에 글을 쓰지 않는다
LLM 기본 질문은 여전히 나온다.
“LLM은 한 스텝에서 무엇을 예측하나?”
“텍스트를 생성합니다”에서 멈추면 부족하다. 모델은 매 스텝마다 다음 토큰에 대한 확률분포를 낸다. 그중 하나를 고르고, 다시 입력 뒤에 붙이고, 또 다음 토큰을 고른다.
LLM의 글쓰기는 거대한 while loop에 가깝다. 다음 토큰 예측 함수 노트에 적어둔 것처럼, 모델은 답을 DB에서 꺼내는 것이 아니라 “지금까지의 텍스트 다음에 올 토큰”을 확률로 예측한다.
이 구분이 중요하다. 모델이 검색하지 않고 생성한다는 것을 이해해야 환각도 이해된다. 모델은 “사실”을 직접 확인하는 장치가 아니라, 그럴듯한 다음 토큰을 만드는 장치다. 그러니 모르는 사실에 대해서도 그럴듯하게 말할 수 있다. 면접에서 이 대목을 놓치면 뒤의 모든 답변이 흔들린다.
“decoder-only와 encoder-only는 언제 쓰나?”도 자주 이어진다.
encoder-only 모델은 문장 표현, 분류, 검색 임베딩 쪽에 잘 맞는다. decoder-only 모델은 미래 토큰을 보지 않으면서 다음 토큰을 생성한다. encoder-decoder는 번역과 요약 같은 text-to-text 작업에서 오래 쓰였다. 범용 챗봇과 코드 생성은 대체로 decoder-only 쪽이 중심이다.
여기서 필요한 건 모델 이름 자랑이 아니다. “생성할 것인가, 표현을 뽑을 것인가, 검색에 쓸 것인가”를 작업 기준으로 나누는 것이다.
temperature는 창의성 노브가 아니다
Habr 글에서 가장 블로그화하기 좋은 부분은 디코딩 전략이다. 면접관은 이런 식으로 묻는다.
“temperature는 무엇을 바꾸나?”
T를 올리면 다양해진다는 말만으로는 부족하다. temperature는 확률분포의 모양을 바꾸고, 그 결과 후보 토큰의 선택 가능성이 달라진다.
법률, 의료, 고객지원처럼 실패 비용이 큰 작업에서는 낮은 temperature가 맞을 때가 많다. 아이디어 발산이나 문체 변주라면 조금 높일 수 있다. 물론 높인다고 창의성이 자동으로 올라가는 것은 아니다. 분포가 너무 평평해지면 창의성이 아니라 헛소리가 나온다.
추론과 환각 - 샘플링 노트에 쓴 것처럼, 환각은 단순 버그가 아니라 이 생성 메커니즘의 자연스러운 결과다. temperature를 0에 가깝게 둔다고 사실성이 생기는 것도 아니다. 틀린 답을 매번 똑같이 말할 수도 있다.
“top-k와 top-p는 어떻게 다른가?”라는 질문도 거의 세트로 붙는다.
top-k는 상위 k개 토큰만 남기는 방식이다. 구조는 단순하다. 문제는 고정값이라는 점이다. 어떤 문맥에서는 후보 3개면 충분하고, 어떤 문맥에서는 50개를 봐야 할 수도 있다.
top-p는 누적 확률 기준으로 후보 집합을 만든다. 분포가 뾰족하면 후보가 적고, 분포가 평평하면 후보가 많아진다. 그래서 top-p는 분포 모양에 더 잘 적응한다.
“왜 항상 가장 높은 확률 토큰만 고르면 안 되나?”
이 질문에는 greedy decoding의 장단점을 같이 말해야 한다. greedy는 빠르고 안정적이다. JSON 추출, 라벨 분류, 결정적 변환처럼 형식이 고정된 작업에는 맞을 수 있다. 열린 글쓰기나 대화에서는 반복, 단조로움, 국소 최적 문제가 생긴다. 매 순간 가장 좋아 보이는 토큰을 고른다고 전체 문장이 좋아지는 것은 아니다.
결국 답은 작업 쪽으로 돌아온다. 설정값은 정답이 아니라 도메인별 선택이다.
BLEU가 낮다고 나쁜 답은 아니다
LLM 면접에서 평가 지표를 물으면 많은 사람이 이름부터 나열한다. BLEU, ROUGE, METEOR, BERTScore, perplexity. 먼저 물어야 할 것은 “무엇을 재려는가”다.
“BLEU와 ROUGE가 최신 LLM 답변 평가에 약한 이유는?”
BLEU와 ROUGE는 참조 답안과의 표면적 겹침에 크게 기대는 지표다. 번역이나 요약처럼 참조 텍스트가 비교적 명확한 시대에는 쓸모가 있었다. 자유 형식 QA에서는 같은 의미를 다른 말로 쓰는 답이 낮게 나오고, 참조와 단어가 겹치지만 사실은 틀린 답이 높게 나올 수 있다.
예를 들어 고객지원 챗봇이 “환불은 7일 안에 가능합니다”라고 해야 하는데, 모델이 “일주일 내 취소가 허용됩니다”라고 답했다면 BLEU는 낮게 나올 수 있다. 같은 문장을 포함했더라도 뒤에 잘못된 예외 조건을 붙이면 표면 지표는 그 위험을 잘 못 본다.
“perplexity가 낮으면 좋은 챗봇인가?”
그렇지 않다. perplexity는 모델이 텍스트를 얼마나 덜 놀랍게 보는지에 가깝다. 사전학습 적합도나 언어모델 비교에는 쓸 수 있지만, instruction following, 안전성, 출처 일치, 사용자 문제 해결률을 보장하지 않는다. 토크나이저나 평가 코퍼스가 다르면 비교도 조심해야 한다.
“LLM-as-a-Judge는 언제 쓰나?”
대규모 사람 평가를 매번 할 수 없을 때, 스크리닝과 회귀 감지에 쓸 수 있다. judge 모델도 편향에서 자유롭지 않다. 코드처럼 실행 가능한 작업은 judge보다 테스트가 더 낫다. JSON 구조는 스키마로 검증해야지, LLM에게 “맞는지 봐줘”만 시키면 안 된다.
실전에서는 여러 지표를 같이 봐야 한다. 오프라인 golden set을 만들고, retrieval recall과 answer faithfulness를 보고, 사람 평가나 side-by-side를 일부 섞고, 제품에서는 해결률, 재문의율, 티켓 재오픈, 이탈 같은 지표를 같이 본다. 면접관이 듣고 싶은 것은 지표 이름이 아니라 측정 설계다.
RAG를 벡터 DB 한 줄로 설명하면 떨어진다
최근 AI Engineer 면접에서 가장 흔한 질문은 대체로 이런 모양이다.
“5만 개 고객센터 문서로 환각하지 않는 지원 챗봇을 만들어보라.”
약한 답은 빠르다.
“문서를 벡터 DB에 넣고, 질문을 임베딩해서, 관련 문서를 GPT에 넣겠습니다.”
이 답은 틀리지는 않아도 거의 아무것도 말하지 않는다. 좋은 답은 파이프라인을 순서대로 짚는다.
먼저 문서가 어떤 형태인지 본다. HTML인지 PDF인지, 표가 많은지, 제품별 문서인지, 권한이 섞여 있는지, 매일 바뀌는지 확인한다. 그다음 ingestion과 parsing을 설계한다. 제목, 섹션, 날짜, 제품군, locale, 권한 같은 메타데이터를 살려야 한다.
청킹도 단순히 1,000자씩 자르는 문제가 아니다. 제목과 절 단위로 나눌지, overlap을 얼마나 둘지, 표와 코드 블록을 어떻게 처리할지, FAQ 문서는 질문과 답을 같이 묶을지 따져야 한다. 실제 RAG는 chunking이 recall을 망가뜨리는 일이 많다.
검색은 dense vector만이 답이 아니다. 키워드가 중요한 도메인에서는 BM25 같은 sparse 검색과 dense 검색을 섞고, top-k 후보를 넓게 뽑은 뒤 reranker로 다시 줄인다. context assembly에서는 토큰 예산 안에 중복을 제거하고, 출처를 붙이고, 서로 충돌하는 문서를 처리해야 한다.
생성 단계에서는 “문서에 없으면 모른다고 말하기”가 필요하다. 이것은 프롬프트 문구 하나로 끝나지 않는다. 검색 결과가 비었을 때의 refusal path, 근거 문서 citation, 답변 후 검증, 로그 기반 실패 리뷰가 같이 있어야 한다.
“문서가 매일 바뀌고 서로 충돌하면 어떻게 하나?”
부족한 답은 계속 모델을 바꾸려 한다. 좋은 답은 retrieval과 데이터 레이어로 간다. 문서 버전, 최신성, 정책 우선순위, 폐기된 문서 필터, 충돌 시 clarification 질문, 관리자 검수 플로우를 말한다.
“200쪽 PDF와 질문이 들어오면 답이 나오기까지 어떤 일이 일어나나?”
이 질문은 트릭이 없다. 업로드, 파싱, 청킹, 임베딩, 검색, rerank, context 조립, 프롬프트 구성, 생성, 인용 반환까지 엔터 키 이후 타임라인을 말할 수 있는지 보는 질문이다. 컨텍스트 윈도우가 커졌다고 이 문제가 사라지는 것도 아니다. 긴 문서를 통째로 넣으면 비용과 지연이 커지고, 중요한 정보가 중간에서 묻히기도 한다.
여기서 면접관이 자주 던지는 추가 질문이 있다.
“retrieval은 괜찮은데 답이 30% 틀린다. 이제 뭐 하겠나?”
여기서 바로 더 큰 모델로 가면 부족하다. 먼저 “틀림”을 정의한다. 검색 결과가 틀렸는지, 근거는 맞는데 모델이 무시했는지, 출처는 맞지만 추론이 틀렸는지, 질문 자체가 모호한지 나눈다. 측정 없이 개선은 없다.
RAG냐 fine-tuning이냐는 취향 문제가 아니다
“왜 fine-tuning 대신 RAG를 골랐나?”
이 질문은 지식 질문이 아니라 의사결정 질문이다.
RAG는 지식이 자주 바뀌고, 출처가 필요하고, 롤백과 감사가 중요할 때 유리하다. 회사 내부 문서, 고객지원 정책, 가격표, 제품 매뉴얼처럼 최신성과 근거가 중요한 경우다. 잘못된 문서가 들어가도 인덱스를 갱신하거나 특정 문서를 제외할 수 있다.
fine-tuning은 지식 주입보다 행동 조정에 더 잘 맞는 경우가 많다. 특정 말투, 응답 형식, 도메인별 판단 패턴, tool call 포맷을 안정적으로 따르게 할 때 LoRA/PEFT 같은 방식을 고려할 수 있다. 그만큼 데이터 준비와 평가, 배포와 롤백 비용이 따라온다.
프롬프트로 충분한 문제도 많다. 작은 규칙, 예시 몇 개, 구조화 출력 정도라면 fine-tuning부터 꺼내는 것이 과할 수 있다. 면접에서는 “fine-tuning은 마지막 수단일 수 있다”는 말이 더 현실적이다.
“컨텍스트가 200k면 RAG 필요 없지 않나?”라는 질문도 나온다. 이때는 비용, 지연, 긴 컨텍스트에서의 검색 품질, 권한 분리, 출처 관리로 답하면 된다. 문서를 많이 넣을 수 있다는 것과, 필요한 문서를 안정적으로 찾아 근거를 남긴다는 것은 다른 문제다.
데모는 쉬운데 운영은 어렵다
면접에서 가장 중요한 블록은 화려하지 않다. production과 evaluation이다.
“지연 시간과 비용을 어떻게 줄이나?”
모델 이름 하나로 끝내면 부족하다. 작은 모델로 분류하거나 검증하고, 큰 모델은 필요한 요청에만 쓴다. 프롬프트와 검색 결과를 캐시한다. streaming으로 첫 토큰 체감 지연을 줄인다. retrieval top-k와 context 길이에 상한을 둔다. retry storm을 막고, fallback을 준비한다. first-token latency와 전체 완료 시간을 구분한다.
“토큰 요금이 한 달에 3배 뛰었는데 코드는 안 바뀌었다. 무엇을 보나?”
트래픽 증가만 답하면 부족하다. 평균 입력 길이가 늘었는지, retrieval이 불필요한 문서를 너무 많이 붙이는지, 재시도 루프가 생겼는지, 평가 배치가 프로덕션 키를 쓰고 있는지, 특정 고객의 문서가 비정상적으로 긴지 본다. 관측 가능성이 답의 절반이다.
“무엇을 로그에 남기나?”
민감정보를 마스킹한 입력, retrieval hit와 score, 조립된 context, 모델 원문 출력, 파싱 결과, latency, cost per request, eval score 시계열을 남긴다. 단, 개인정보와 비밀정보를 그대로 저장하면 안 된다. LLM 운영 로그는 디버깅 자산이면서 동시에 보안 리스크다.
이 지점에서 시니어와 주니어가 갈린다. 데모는 누구나 만든다. 출시 후 회귀를 잡고, 비용을 제한하고, 실패를 분류하고, 다시 개선하는 루프를 가진 사람은 적다.
에이전트 질문은 LangChain 사용법이 아니다
에이전트 질문은 점점 더 자주 나온다.
“여행 예약 에이전트가 사람 승인 없이 결제하지 않게 설계하라.”
이 질문은 프레임워크 이름을 묻는 것이 아니다. 가드레일을 묻는다. 결제 API는 human-in-the-loop 단계로 분리해야 한다. tool allowlist를 두고, 결제 전에는 사용자가 최종 확인해야 한다. step budget과 max iteration을 둬서 루프를 막고, 같은 tool을 반복 호출하면 중단한다. 결제 요청은 idempotent해야 하고, audit log가 남아야 한다.
하네스 노트에 적어둔 것처럼, 모델은 텍스트만 만든다. 실제 파일을 읽고, API를 호출하고, 결제를 실행하는 것은 하네스다. 에이전트 설계의 핵심은 모델이 아니라 이 실행 레이어다.
“prompt injection을 어떻게 막나?”
완벽한 답은 없어도 방향은 있다. retrieved text를 신뢰하지 않는다. 시스템 지시와 외부 문서 내용을 분리한다. tool 출력은 구조적으로 검증한다. 민감 액션은 별도 승인 단계로 둔다. “이전 지시를 무시하라” 같은 문구에 프롬프트 문구로만 대응하지 않는다. 방어는 문장이 아니라 구조다.
“에이전트가 루프에 빠지거나 API timeout이 나면?”
timeout, circuit breaker, max tool call count, 동일 tool 반복 감지, 부분 실패 상태 공개, idempotent한 읽기 요청에만 재시도. 이 답변은 LLM 지식이라기보다 운영 시스템 지식이다. 그래서 더 중요하다.
면접관이 싫어하는 답
최근 채용 글과 커뮤니티 경험담에서 반복되는 레드 플래그는 비슷하다.
“그냥 프롬프트를 잘 쓰면 됩니다.”
이 말은 하드한 신뢰성 문제의 아키텍처가 아니다. 프롬프트는 필요해도 데이터 파이프라인, 검색 품질, 평가, 보안, 비용 제어를 대체하지 못한다.
“eval은 아직 안 해봤고, 보면 압니다.”
비결정적 시스템에서 가장 위험한 답이다. LLM 제품은 같은 코드라도 입력, 모델 버전, 검색 결과, 프롬프트 길이에 따라 다르게 흔들린다. 느낌으로 운영할 수 없다.
“Pinecone, LangChain, GPT-5, Claude를 씁니다.”
도구 이름만 나열하면 부족해 보인다. 왜 그 도구를 골랐는지, 어떤 한계가 있었는지, 다른 선택지는 왜 버렸는지 말해야 한다.
“PDF 챗봇을 만들었습니다.”
이 문장만으로는 부족하다. 왜 RAG를 골랐는지, fine-tuning을 왜 안 했는지, chunking은 어떻게 했는지, hallucination을 어떻게 줄였는지, 비용을 어떻게 봤는지까지 가야 한다.
잘하는 사람은 조금 느리게 답한다. 바로 기술명으로 뛰지 않고, 먼저 문제의 실패 비용과 측정 방법을 잡는다.
공개용 Habr 체크리스트
Habr 원문에는 면접 대비용 질문이 길게 붙어 있다. 그대로 외우기보다, 공개 글에서는 아래 정도로 압축해 들고 가는 편이 낫다. 이 리스트에 답할 수 있으면 “용어를 봤다”가 아니라 “면접에서 말할 수 있다”에 가까워진다.
언어 모델링부터 확인한다.
- 언어 모델링은 정확히 무엇을 예측하는 일인가?
- next token prediction을 왜 다중 분류 문제처럼 볼 수 있나?
- 텍스트는 어떻게 다음 토큰 확률분포로 바뀌나?
- hidden state, logits, probability는 각각 어디에 놓이나?
- softmax는 왜 필요한가?
- cross-entropy loss는 무엇을 줄이는가?
- 왜 LLM 학습에는 고전적인 수작업 라벨이 덜 필요한가?
아키텍처와 학습은 이렇게 묻는다.
- encoder-only, encoder-decoder, decoder-only는 어떤 작업에 맞나?
- 현대 챗봇과 코드 생성 모델은 왜 decoder-only가 많은가?
- causal mask는 무엇을 막기 위한 장치인가?
- GPT식 학습과 BERT식 학습은 무엇이 다른가?
- teacher forcing은 학습에서 어떤 역할을 하나?
- 학습은 병렬로 되는데 생성은 왜 순차적으로 진행되나?
생성 전략은 면접의 핵심이다.
- 한 번의 autoregressive generation step에서는 무슨 일이 일어나나?
- 학습 때와 추론 때의 입력은 어떻게 다른가?
- coherence와 diversity는 왜 서로 긴장 관계에 있나?
- 왜 항상 가장 높은 확률 토큰을 고르면 안 되나?
- greedy decoding은 언제 좋고 언제 위험한가?
- random sampling은 왜 이상한 토큰을 뽑을 수 있나?
- temperature를 낮추거나 높이면 분포가 어떻게 바뀌나?
- top-k와 top-p는 후보 집합을 어떻게 다르게 자르나?
- temperature, top-k, top-p는 함께 쓸 수 있나?
- beam search는 greedy와 무엇이 다른가?
- 반복 생성은 왜 생기고, repetition penalty는 무엇을 막나?
평가 지표는 마지막 방어선이다.
- 생성 품질 평가는 왜 분류 정확도보다 어렵나?
- Exact Match는 어떤 작업에만 맞나?
- BLEU와 ROUGE는 각각 무엇을 잘 보고, 무엇을 놓치나?
- 낮은 perplexity가 좋은 챗봇을 보장하지 않는 이유는?
- BERTScore는 왜 paraphrase에 더 강한가?
- LLM-as-a-Judge는 언제 유용하고 어떤 bias를 조심해야 하나?
- 왜 한 가지 지표만으로 LLM을 평가하면 안 되나?
- offline eval과 제품 지표를 어떻게 함께 볼 것인가?
어떻게 준비할까
Habr 체크리스트는 기본기 트레이닝으로 좋다. 위 질문을 손으로 설명해본다. 이건 암기하라는 뜻이 아니다. 각 개념이 어떤 실패와 연결되는지 말할 수 있어야 한다.
그 위에 작은 RAG 프로젝트를 하나 만든다. 문서 20개라도 된다. ingest, parse, chunk, embed, retrieve, rerank, answer, cite를 한 번 끝까지 돌린다. 그리고 golden set 20~50개를 만들어 프롬프트나 검색 설정을 바꿀 때마다 회귀를 본다.
비용도 말로 연습해야 한다. 요청당 평균 input token이 얼마인지, output token이 얼마인지, 하루 요청 수가 늘면 비용이 어떻게 커지는지, cache hit rate가 올라가면 얼마나 줄어드는지 대략 계산해본다. 정확한 숫자보다 계산 습관이 중요하다.
에이전트는 실패 시나리오를 적어본다. 루프, timeout, 잘못된 JSON, prompt injection, 권한 없는 tool 호출, 결제 같은 irreversible action. 이걸 막는 구조를 말할 수 있어야 한다.
한국어 커뮤니티에는 최근 30일 안에 강한 신규 정리글이 많지 않았다. 영어권 채용 글, Reddit 경험담, Habr 기본기를 합치면 준비 범위는 꽤 분명해진다. 한쪽은 확률분포와 평가 지표를 묻고, 다른 한쪽은 RAG와 운영을 묻는다. 둘은 따로가 아니다. 같은 면접의 앞뒤다.
마지막 질문은 하나다
LLM 면접은 “GPT가 뭐의 약자인가”에서 끝나지 않는다. 다음 토큰 분포를 이해하고, 샘플링 트레이드오프를 도메인에 맞게 고르고, BLEU만 믿지 않고 평가 파이프라인을 짓고, RAG와 에이전트를 출처, 비용, 실패 모드와 함께 설계하는지를 본다.
면접관이 듣고 싶은 것은 교과서 정의가 아니다.
왜 이 선택을 했는가.
무엇이 깨질 수 있는가.
어떻게 알아챌 것인가.
이 세 문장을 모든 답변 뒤에 붙이면, “RAG 써봤어요”와는 답의 수준이 달라진다.
LLM 면접은 암기가 아니라 분포를 말하는 시험이다. 그리고 더 정확히는, 그 분포가 현실의 제품 안에서 어디서 깨지는지 말하는 시험이다.
용어 정리
- temperature: Temperature는 logits를 softmax에 넣기 전에 조정해 확률분포를 뾰족하게 만들거나 평평하게 만드는 값이다. 낮으면 보수적이고 반복적일 수 있고, 높으면 다양해지는 대신 불안정해질 수 있다.
- top k: Top-k sampling은 확률 상위 k개 토큰만 후보로 남기고 나머지를 버리는 생성 방식이다.
- top p: Top-p, 또는 nucleus sampling은 확률이 높은 토큰부터 누적해 합이 p를 넘는 최소 후보 집합을 만든 뒤 그 안에서 샘플링하는 방식이다.
- bleu: BLEU는 생성문과 참조문 사이의 n-gram precision을 보는 고전적 자동 평가 지표다. 번역 평가에서 유명하다.
- rag: RAG는 Retrieval-Augmented Generation의 약자다. 모델이 답하기 전에 외부 문서나 DB에서 관련 근거를 찾아 컨텍스트로 넣는 방식이다.
- fine tuning: Fine-tuning은 이미 학습된 모델을 특정 데이터나 작업에 맞게 추가 학습하는 것이다. 최신 지식 주입보다 행동 양식, 출력 형식, 도메인 패턴 조정에 더 자주 맞는다.
- greedy: Greedy decoding은 매 스텝마다 가장 확률이 높은 토큰 하나를 고르는 방식이다. 빠르고 안정적이지만 반복과 단조로움에 빠지기 쉽다.
- rouge: ROUGE는 참조 답안의 n-gram이나 longest common subsequence가 생성문에 얼마나 포함됐는지 보는 평가 지표다. 요약 평가에서 자주 쓰였다.
- perplexity: Perplexity는 모델이 주어진 텍스트를 얼마나 “놀랍게” 보는지에 가까운 값이다. 낮을수록 모델이 그 텍스트를 더 그럴듯하게 본다는 뜻이지만, 지시 수행이나 사실성을 보장하지는 않는다.
- llm judge: LLM-as-a-Judge는 더 강한 LLM을 평가자로 써서 답변 점수, 선호도, 기준 충족 여부를 판정하게 하는 방식이다.
- logits softmax: Logits는 softmax 전의 원점수이고, softmax는 이 값을 합이 1인 확률분포로 바꾼다. vocab은 모델이 선택할 수 있는 토큰 목록이다.
- architecture: Encoder-only는 입력 전체를 양방향으로 읽는 표현 모델에 가깝고, decoder-only는 이전 토큰만 보고 다음 토큰을 만드는 생성 모델에 가깝다. encoder-decoder는 입력 시퀀스를 읽고 출력 시퀀스를 생성하는 구조다.
- meteor: METEOR는 BLEU보다 유연하게 어형 변화, 동의어, 단어 순서 등을 일부 고려하려는 평가 지표다.
- bertscore: BERTScore는 표면 단어 겹침보다 임베딩 기반 의미 유사도를 보려는 평가 지표다.
- bleu rouge: BLEU는 precision 쪽, ROUGE는 recall 쪽 감각이 강하다. 둘 다 의미, 사실성, 출처 충실성을 직접 보장하지는 않는다.
- llm judge bias: 대표적으로 먼저 나온 답을 선호하는 position bias, 긴 답을 선호하는 verbosity bias, 자기 모델 계열 답을 좋게 보는 편향이 문제될 수 있다.
- ingestion: Ingestion은 원문 데이터를 시스템에 넣는 과정이고, parsing은 PDF, HTML, 표, 코드 블록 같은 원본 구조를 검색 가능한 텍스트와 메타데이터로 푸는 과정이다.
- chunking: Chunking은 긴 문서를 검색과 컨텍스트 주입에 맞게 작은 조각으로 나누는 과정이다. 너무 작으면 맥락이 깨지고, 너무 크면 검색 정확도와 비용이 나빠질 수 있다.
- dense sparse: Dense 검색은 임베딩 벡터 유사도로 의미가 가까운 문서를 찾고, sparse 검색은 BM25처럼 단어 매칭 신호를 강하게 쓴다.
- reranker: Reranker는 넓게 가져온 후보 문서를 다시 정밀하게 재정렬해 최종 컨텍스트에 넣을 문서를 고르는 모델이나 단계다.
- lora peft: LoRA는 전체 가중치를 다 바꾸지 않고 작은 저랭크 어댑터만 학습하는 PEFT 기법이다. PEFT는 parameter-efficient fine-tuning의 약자다.
- latency: Streaming은 답을 한 번에 끝까지 만든 뒤 보여주는 대신 생성되는 토큰을 순차적으로 보여주는 방식이다. First-token latency는 첫 글자가 보이기까지의 시간이다.
- human loop: Human-in-the-loop는 모델이나 에이전트가 고위험 결정을 바로 실행하지 않고 사람 승인 단계를 반드시 거치게 하는 설계다.
- idempotent: Idempotent한 작업은 같은 요청을 여러 번 보내도 결과가 중복으로 망가지지 않는 작업이다. 결제, 예약, 삭제처럼 되돌리기 어려운 액션에서는 특히 중요하다.
댓글
댓글 쓰기