폐관수련

ICML 2026 후기

Fri, 10 Jul 2026 11:06:58 GMT

태어나서 처음으로 학회에 다녀왔다. 작년 9월부터 학부연구생으로 있는 연구실에서 감사하게도 비용을 지원해주셨다.

처음에는 정식 석사과정생도 아닌데 연구실 예산으로 학회에 가는 게 죄송스러워서 가지 않겠다고 말씀드렸다. 하지만 (우리 랩실의 기둥인) 박사과정 누나가 학부생 때 학회에 가면 정말 좋은 경험이 될 거라고 조언해주어서 다시 솔직하게 가고 싶다고 말씀드렸다.

나는 우리 연구실 사람들이 너무 좋다. 다들 졸업하지 않으셨으면 좋겠다. 그러면 나도 연구실에 뼈를 묻을텐데...

목표한 것

동기 부여
네트워킹; 특히 외국인(연구원/현직자분들)과 대화해보기
진로 고민 해결

얻은 것

1. 동기부여

엄청 됐다. 여러 똑똑한 사람들을 만나고, 수 많은 재밌는 논문을 읽을 수 있었다. 다음 학회에는 꼭 1저자로 가고 싶다. 당장 EACL과 COLING이 가까우니 해당 학회에 제출하는 것을 목표로 열심히 달려보겠다.

2. 네트워킹

스폰서 부스에서 외국인 현직자 분들과 해당 회사의 목표 및 관심사, 기업 문화, 채용 등에 대한 설명을 듣고, 내 연구 분야에 대한 이야기를 주고 받았다. Resume를 제출하고 귀여운 굿즈들도 받았다.

포스터 세션에서는 저자들에게 해당 연구에 대한 설명을 듣고, 연구에 대해 궁금한 점들을 물어보았다. 다만 언어의 벽에 부딪혀 마지막 날에는 거의 한국인 저자들만 찾아 다녔다. 특히 내 연구와 비슷한 연구를 한 저자들과 많은 대화를 나눴고, 추후 연구에 대한 조언을 구하고자 Linkedin 연락처를 받았다.

3. 진로 고민 해결

스폰서 부스에서 네이버와 LG AI연구원 현직자분들과 긴 대화를 나누었다. 평소 국내 AI 업계에 대해 궁금했던 점들을 여쭤보고, AI Safety와 Evaluation에 관한 내 생각도 말씀드리며 즐겁게 대화했다.

특히 네이버 현직자분과는 30분이 넘게 이야기를 나누었다. 학벌에 대한 고민부터 연구 방향과 커리어 설계까지 여러 구체적인 질문을 드렸고, 현직자분께서 매우 진솔하게 답변해주셨다. 앞으로의 진로와 인생을 설계하는 데 큰 도움이 되었다.

아무리 생각해도 너무 감사해서 학회가 끝난 뒤 링크드인으로 감사 인사를 드렸다.

4. 연구실 동료들과 더 돈독해짐

사실 연구실에서 길게 대화할 일이 없어 쪼금 어색한 분들도 있었는데, 같이 맛있는 거 먹으면서 많이 친해졌다 ㅎ_ㅎ

느낀 것

확실히 나는 LLM을 좋아한다. 석사에 진학해서 연구를 해야겠다는 확신을 얻었다.
최소한 학회 한 달 전부터 관심 있는 논문을 Appendix까지 꼼꼼히 읽어둬야겠다. 저자를 만나서 해당 연구에 대해 궁금했던 점, 그리고 내 연구에 대한 조언을 받으면 훨씬 유익한 시간이 될 것 같다.
확실히 중국 대학의 논문이 압도적으로 많고, 그 다음으로 영미권 대학/회사들의 논문이 많았던 것 같다. 국내 기관 중에서는 KAIST와 연세대학교가 대다수였던 것 같다.
논문도 논문 나름인 것 같다. Task마다 다르겠지만, 어떤 논문들은 포스터의 2/3가 수식으로 도배되어 말을 걸어볼 엄두도 안났는데, 어떤 논문들은 직관적이고 이해하기 쉬웠다. 다만 문제 정의와 실험 설계가 매우 엄밀했고, 다양한 질문에도 유창하게 답변하는 것을 보고 본인의 연구를 정말 잘 이해하고 있다는 느낌을 받았다.
생각보다 비슷한 아이디어, 비슷한 방법론을 적용한 논문들이 굉장히 많았다. 다른 논문들과 겹칠까봐 두려워할 필요가 없겠다.
영어를 잘해야겠다. 하고 싶은 말도 많고 듣고 싶은 말도 많았는데 말이 통하지 않아 너무 답답하고 아쉬웠다.
해외 석박사/취업 기회가 생각보다 많은 것 같다. 졸업 후 꼭 해외에 나가서 일해보고 싶다.
포스터를 만들 때는 꼭 눈에 띄는 디자인으로 만들어야겠다.
다음 학회에는 꼭 1저자로 참석하고 싶다.

너무 재밌고 행복했다~

학회 기간 동안 비가 많이 왔다.

학회 중간에 속상한 일이 있었다. 이전부터 KT 채용연계형 대학원에 꼭 지원하고 싶었는데, 어학 시험 일정과 이번 공고 일정이 맞지 않다는 사실을 알았다.

변명을 조금 하자면, 지난 2023·2024·2025학년도 봄학기 공고가 모두 8월 1~2주까지 진행됐기에 이번 2026학년도 공고도 비슷할 거라고 생각했다. 토익 시험 역시 기말고사가 끝난 뒤 응시할 수 있는 가장 빠른 시험을 신청한 것이었다. 물론 미리미리 준비했으면 좋았겠지만, 학기 중에는 도저히 엄두가 나지 않았다.

당시 너무 허탈해서 거의 한 시간을 아무것도 안하고 앉아있었는데, 네이버 현직자분과 대화한 뒤 마음이 많이 나아졌다.

또한 고맙게도 종원이가 코엑스까지 찾아와서 위로해주었다. 귀여운 자식 ^_^ 종원이도 나도 내 주변 사람들도 전부 잘 됐으면 좋겠다.

지금은 내가 KT를 짝사랑하지만, 내가 좋은 논문들을 내면 KT가 나를 보고 싶어할 것이다. 그러면 난 KT 대신 다른 회사에 가겠다. 메롱 ㅎ.ㅎ

방학을 어떻게 보낼까?

Tue, 30 Jun 2026 10:17:02 GMT

1. 연구

1) Semantic Leakage 연구

가능한 7월 중 문제 정의를 마치고, 8월까지 유의미한 실험 결과를 내보겠다.

2) 공부

LLM의 사고 과정을 이해하기
LLM의 문제 행동이 왜 발생하는지 탐구하기

2. 개발

오픈소스 기여

용준이형의 harness-factory 프로젝트에 참여하게 됐다.
하네스 평가 파이프라인을 구축해보려고 한다.

대회 참여

미래에셋 AI Festival에 참여하려고 한다.

3. 진로

LG전자, KT 채용연계형 대학원 준비
타대 연구실 컨택 준비 (+DAAD 유학 준비)
토익
코딩테스트 (프로그래머스 Lv 2, 3 전부 풀기)
<개발자를 위한 필수 수학> 정리

4. 자기개발

헬스
요리
피아노, 베이스 연습

읽을 논문

A. LLM 해석가능성 개요와 기본 배경

B. Probing, Attention, Logit Lens

C. Mechanistic Interpretability와 Circuit 분석

D. 지식 저장, Factual Association, Model Editing

E. Superposition, SAE, Monosemanticity, NLA

F. Representation Engineering과 Activation Steering

G. Error Cases

H. Chain-of-Thought와 Reasoning Faithfulness

I. Training Data, Memorization, Leakage 원인 추적

요즘 기초가 부실하다는 생각이 많이 들어서, 연구는 bottom-up으로 빠르게 진행하되 동시에 interpretability, safety 연구들을 top-down으로 공부하려고 한다.

중요한 시기이니만큼 지금까지 보낸 방학 중 가장 알찬 방학을 보내고 싶다.

On Memory Construction and Retrieval for Personalized Conversational Agents

Fri, 29 May 2026 09:32:43 GMT

ICLR 2025 [Paper] [Code] Zhuoshi Pan, Qianhui Wu, Huiqiang Jiang, Xufang Luo, Hao Cheng, Dongsheng Li, Yuqing Yang, Chin-Yew Lin, H. Vicky Zhao, Lili Qiu, Jianfeng Gao Tsinghua University | Microsoft Corporation 8 Feb 2025

Introduction

LLM 기반 대화형 에이전트를 실제 서비스에서 쓰려면 여러 세션에 걸쳐 쌓인 대화를 기억하고, 현재 사용자 요청에 맞는 정보를 다시 찾아와야 합니다. 기존 접근은 대체로 전체 conversation history를 prompt에 붙이거나, 과거 대화를 summary로 압축하거나, turn-level 또는 session-level 단위로 memory bank를 만든 뒤 retrieval augmented response generation을 수행하는 방식이었습니다.

이 논문이 집중하는 지점은 memory construction에서 가장 기본적인 선택지인 memory unit granularity입니다. Turn-level memory는 단위가 너무 작아 관련 정보가 여러 turn에 흩어지기 쉽습니다. 반대로 session-level memory는 한 unit 안에 서로 다른 topic이 함께 들어갈 수 있습니다. Summarization-based memory는 context 길이를 줄이는 데는 유리하지만, QA에 필요한 세부 근거가 summary 과정에서 빠질 위험이 있습니다.

저자들은 이 문제를 다루기 위해 SeCom을 제안합니다. SeCom은 conversation history를 topic 단위의 Segment로 나누어 memory bank를 만들고, retrieval 전에 prompt Compression을 적용해 memory unit의 redundancy를 줄입니다. 다시 말해 memory를 “얼마나 길게 저장할 것인가”뿐 아니라, “retrieval을 방해하는 noise를 어떻게 덜어낼 것인가”까지 함께 다루는 방법입니다.

[Figure 1. turn-level, session-level, summary-based memory와 segment-level memory의 context 품질 차이]

Figure 1을 보면 논문의 문제의식이 바로 드러납니다. Turn-level memory는 query와 직접 겹치는 일부 turn만 고르다가 대화 흐름을 놓칠 수 있습니다. Session-level memory는 필요한 정보와 상관없는 topic까지 함께 가져옵니다. Summary-based memory는 짧지만, 원문에 있던 근거가 사라질 수 있습니다. SeCom의 segment-level memory는 topic coherence를 기준으로 memory unit을 구성해 세 방식 사이의 중간 지점을 찾습니다.

SeCom

Preliminary

논문에서는 long-term conversation을 여러 session으로 이루어진 history로 정의합니다. 전체 conversation history는 다음처럼 둘 수 있습니다.

$H={c_i}_{i=1}^{C}$

$H$: 사용 가능한 conversation history
$C$: session 수
각 session $c_i$는 순차적인 interaction turn으로 구성됨.

$c_i={t_j}_{j=1}^{T_i}, \quad t_j=(u_j, r_j)$

$T_i$: i번째 session의 turn 수
$t_j$: user request $u_j$와 agent response $r_j$로 이루어진 하나의 interaction turn

기본 retrieval augmented response generation은 세 단계로 정리됩니다. 먼저 conversation history $H$에서 memory bank $M$을 만듭니다. target request $u^*$가 주어지면 retrieval system $f_R$이 관련 memory unit $N$개를 가져옵니다.

${m_n \in M}_{n=1}^{N} \leftarrow f_R(u^*, M, N)$

마지막으로 response generation model $f_{LLM}$은 검색된 memory unit을 context로 삼아 응답 $r^*$를 생성합니다.

$r^* = f_{LLM}(u^*, {m_n}_{n=1}^{N})$

이 formulation에서 핵심 변수는 $M$입니다. 같은 retrieval model과 generation model을 쓰더라도 memory bank를 turn-level, session-level, summary-level, segment-level 중 어떤 단위로 구성하느냐에 따라 검색 품질과 최종 응답이 달라집니다.

Method

Conversation Segmentation

SeCom은 하나의 session을 topic coherence가 유지되는 여러 segment로 나눕니다. Conversation segmentation model $f_\mathcal{I}$는 session $c$를 입력으로 받아 segment index 집합을 예측합니다.

$f_\mathcal{I}(c)={s_k}{k=1}^{K}, \ \text{where} \ s_k={t*{p_k}, t{p_k+1}, ..., t_{q_k}}$

$K$: session 안의 segment 수
$s_k$: $k$번째 segment
$p_k$, $q_k$: 해당 segment의 시작 turn과 마지막 turn index
연속된 segment가 대화를 빠짐없이 덮도록 $p_{k+1}=q_k+1$ 조건도 둡니다.

저자들은 open-domain conversation segmentation을 위해 GPT-4를 zero-shot segmentation model로 사용합니다. 이때 원본 session에 turn index와 role identifier를 붙여 모델이 대화 흐름을 더 분명하게 읽도록 합니다. 각 turn은 예를 들어 Turn j, [user], [agent] 형식으로 정리됩니다.

Annotated segmentation data가 일부 있을 때는 reflection mechanism을 적용합니다. 모델이 segmentation을 수행한 뒤 WindowDiff 기준으로 error가 큰 hard example을 고릅니다. 이어서 LLM이 자신의 segmentation mistake를 분석하고 segmentation guidance를 갱신합니다. 논문은 이 과정을 SGD와 비슷한 prompt-level optimization으로 봅니다. 실제 parameter를 업데이트하는 대신 segmentation rubric을 반복해서 다듬는 방식입니다.

Compression based Memory Denoising

SeCom의 두 번째 구성 요소는 compression based memory denoising입니다. 자연어 대화에는 반복, filler, 부연 설명, topic drift가 쉽게 섞입니다. 이런 redundancy는 retrieval model이 query와 memory 사이의 relevance signal을 잡는 데 방해가 됩니다.

SeCom은 memory retrieval 전에 memory bank를 prompt compression model로 처리합니다.

${m_n \in M}{n=1}^{N} \leftarrow f_R(u^*, f{Comp}(M), N)$

여기서 $f_{Comp}$는 memory unit을 압축하는 함수입니다. 논문에서는 LLMLingua-2를 사용합니다. 이 압축은 generation 단계의 context를 줄이기 위한 장치에 그치지 않습니다. retrieval 전에 불필요한 token을 제거해 관련 segment가 더 잘 검색되도록 만드는 denoising 역할도 합니다.

[Figure 3. LLMLingua-2 compression rate에 따른 retrieval recall과 relevant/irrelevant segment similarity 변화]

Figure 3은 compression이 retrieval에 어떤 영향을 주는지 보여줍니다. BM25와 MPNet retriever 모두 일정 compression rate 이상에서 recall이 개선됩니다. compression 이후 query와 relevant segment의 similarity는 올라가고, irrelevant segment와의 similarity는 낮아지는 경향도 나타납니다. prompt compression이 단순한 token reduction이 아니라 retrieval signal을 정제하는 과정으로도 작동한다는 해석이 가능합니다.

Experiments

논문은 SeCom을 long-term conversation QA와 dialogue segmentation 두 축에서 평가합니다. Response generation에는 주로 GPT-35-Turbo를 사용했고, robustness를 확인하기 위해 Mistral-7B-Instruct-v0.3도 함께 사용했습니다. Retrieval model은 BM25와 MPNet 기반 retriever를 모두 실험합니다. Compression에는 LLMLingua-2를 쓰며, 주요 실험의 compression rate는 75%입니다.

Long-term conversation benchmark로는 LOCOMO와 Long-MT-Bench+를 사용합니다. LOCOMO는 평균 300 turns와 9K tokens 수준의 긴 conversation으로 설명되며, Long-MT-Bench+는 MT-Bench+를 long-range QA 형태로 재구성한 benchmark입니다. 평가 지표에는 BLEU, ROUGE, BERTScore, GPT4Score가 포함됩니다. 저자들은 GPT-4를 이용한 pairwise comparison도 함께 수행했습니다.

Baseline은 네 부류로 나뉩니다. Zero History는 과거 대화를 전혀 사용하지 않고, Full History는 전체 history를 context에 넣습니다. Turn-Level과 Session-Level은 memory granularity를 달리한 retrieval baseline입니다. SumMem, RecurSum, ConditionMem, MemoChat은 기존 memory management 또는 summarization 기반 접근을 대표합니다.

[Table 1. LOCOMO와 Long-MT-Bench+에서 SeCom과 baseline의 QA 성능 비교]

Table 1에서 SeCom은 두 benchmark 모두에서 강한 성능을 보입니다. LOCOMO에서는 SeCom(BM25, GPT4-Seg)이 GPT4Score 71.57을 기록해, 가장 높은 baseline인 ConditionMem의 65.92를 앞섭니다. Long-MT-Bench+에서는 SeCom(MPNet, GPT4-Seg)이 GPT4Score 88.81을 기록했고, MemoChat의 85.14보다 높습니다.

차이는 LOCOMO에서 더 뚜렷합니다. LOCOMO는 대화가 길고 topic이 여러 session에 걸쳐 흩어져 있어 memory construction의 영향이 크게 드러나는 설정입니다. Long-MT-Bench+는 평균 turn 수가 더 짧기 때문에 baseline도 상대적으로 높은 점수를 얻습니다.

흥미로운 부분은 retriever에 따른 민감도입니다. Turn-Level과 Session-Level은 BM25와 MPNet 중 어떤 retriever를 쓰느냐에 따라 GPT4Score가 크게 달라집니다. SeCom은 두 retrieval setting에서 비교적 안정적인 성능을 보입니다. Segment-level memory가 fragmentary context와 irrelevant context 사이의 균형을 맞추기 때문으로 해석할 수 있습니다.

Evaluation of Conversation Segmentation Model

저자들은 conversation segmentation module 자체도 별도로 평가합니다. 사용한 dataset은 DialSeg711, TIAGE, SuperDialSeg입니다. 평가 지표는 Pk, WindowDiff, F1, segment score입니다.

[Table 4. DialSeg711, SuperDialSeg, TIAGE에서 conversation segmentation model의 성능 비교]

Table 4에서 GPT-4 기반 zero-shot segmentation은 unsupervised baseline보다 전반적으로 나은 성능을 냅니다. Limited annotated data가 있는 transfer learning setting에서는 reflection으로 학습한 segmentation guidance가 쓰입니다. 이 경우 모델은 source dataset의 hard example 100개만으로 rubric을 개선하지만, 일부 target dataset에서는 full training set으로 학습된 baseline보다 좋은 결과를 보입니다.

Analysis

SeCom의 이점은 segment-level memory와 compression-based denoising이 함께 작동할 때 분명해집니다. Segment-level memory는 turn-level보다 문맥을 더 보존하고, session-level보다 불필요한 topic을 덜 끌고 옵니다. 이 granularity는 long-term conversation에서 자주 생기는 topic shift를 memory construction 단계에서 반영합니다.

[Figure 5. context budget 변화에 따른 memory granularity별 GPT4Score 비교]

Figure 5는 context budget이 달라져도 segment-level memory가 turn-level과 session-level보다 일관되게 높은 성능을 내는 흐름을 보여줍니다. 단순히 더 많은 token을 넣는 방식이 항상 답은 아니라는 뜻입니다. Retrieval unit이 너무 작으면 필요한 근거가 잘리고, 너무 크면 irrelevant information이 섞입니다.

Compression-based denoising도 별도로 기여합니다. Table 2에서 denoising을 제거하면 LOCOMO 기준 GPT4Score가 69.33에서 59.87로 떨어집니다. Long-MT-Bench+에서는 88.81에서 87.51로 감소합니다. 두 benchmark에서 하락 폭이 다른 이유는 대화 길이와 noise 구조의 차이로 볼 수 있습니다. LOCOMO처럼 긴 history에서는 redundant token과 topic drift가 retrieval에 더 큰 영향을 주므로 compression 효과가 더 크게 나타납니다.

[Table 2. compression-based memory denoising 제거에 따른 성능 변화]

Full History의 한계도 눈에 띕니다. Mistral-7B-Instruct-v0.3은 32K context window를 갖고 있어 Long-MT-Bench+ 전체 history를 넣을 수 있지만, Full History는 SeCom보다 낮은 성능을 보입니다. long context window가 retrieval-free memory management를 곧바로 대체하지는 못한다는 결과입니다. 모델이 긴 context를 받을 수 있더라도, 관련 정보가 얼마나 잘 정리되어 들어가는지가 응답 품질에 영향을 줍니다.

물론 trade-off도 있습니다. GPT-4 기반 segmentation은 가장 좋은 결과를 내지만 비용과 latency가 따릅니다. 논문은 Mistral-7B와 RoBERTa 기반 segmentation도 실험하지만, 성능은 GPT-4-Seg보다 낮습니다. Compression rate를 지나치게 높이면 필요한 정보까지 제거될 수 있습니다. 따라서 SeCom을 실제 시스템에 적용하려면 segmentation model, retriever, compression rate, context budget을 함께 조정해야 합니다.

Limitations

이 논문은 memory construction과 retrieval granularity를 비교적 분명하게 분석하지만, 남는 한계도 있습니다.

우선 가장 좋은 결과가 GPT-4 기반 segmentation에 의존합니다. 저자들은 Mistral-7B와 RoBERTa-scale model도 사용할 수 있음을 보였지만, 특히 RoBERTa-Seg 설정에서는 성능 하락이 관찰됩니다. Resource-constrained environment에서 SeCom을 쓰려면 segmentation 품질과 비용 사이의 절충이 필요합니다.

평가의 중심이 long-term conversation QA에 놓여 있다는 점도 한계입니다. LOCOMO와 Long-MT-Bench+는 memory retrieval을 분석하기 좋은 benchmark이지만, 실제 personalized conversational agent에서는 memory update, deletion, privacy control, user-specific preference drift 같은 문제가 함께 생깁니다. 이 논문은 memory를 어떻게 저장하고 검색할지에 초점을 맞추며, 장기 서비스 운영에 필요한 memory governance까지 다루지는 않습니다.

Compression-based denoising도 항상 안전한 연산은 아닙니다. LLMLingua-2가 redundant token을 제거해 retrieval을 개선하더라도 task에 따라 세부 근거가 압축 과정에서 약해질 수 있습니다. 논문 결과에서는 75% compression rate가 효과적이지만, 다른 domain이나 multilingual dialogue에서도 같은 설정이 최적이라고 보기는 어렵습니다.

마지막으로 SeCom은 retrieval pipeline의 여러 component를 조합하는 방식입니다. Segmenter, compressor, retriever, generator가 각각 독립적으로 작동하므로 error propagation이 생길 수 있습니다. 예를 들어 segmentation boundary가 잘못 잡히면 compression과 retrieval은 그 오류를 전제로 수행됩니다. End-to-end로 memory construction policy를 학습하는 방향은 후속 연구로 남아 있습니다.

Conclusion

이 논문은 personalized conversational agent에서 memory bank를 어떤 단위로 구성해야 하는지 체계적으로 살펴봅니다. Turn-level, session-level, summarization-based memory는 각각 fragmentary context, irrelevant context, information loss라는 문제를 안고 있습니다. SeCom은 conversation segmentation으로 topic-level segment를 만들고, LLMLingua-2 기반 compression으로 retrieval noise를 줄여 이 문제를 완화합니다.

실험 결과는 segment-level memory가 long-term conversation QA에서 더 안정적인 retrieval context를 제공한다는 점을 보여줍니다. 특히 LOCOMO처럼 긴 대화에서는 SeCom의 이점이 크게 나타납니다. Full History가 가능한 long-context model에서도 SeCom이 더 나은 결과를 얻었다는 점은 memory management가 단순한 context length 확장과는 다른 문제임을 보여줍니다.

SeCom의 기여는 새로운 generation model을 제안하는 데 있지 않습니다. 이 논문은 conversational agent의 장기 기억 성능이 memory unit의 구조, retrieval 전처리, context budget 설계에 크게 좌우된다는 점을 실험으로 정리합니다. 장기 대화형 agent를 설계할 때는 memory를 많이 저장하는 것보다, 검색 가능한 형태로 잘 나누고 정제하는 일이 더 중요하다는 방향을 제시합니다.

Recipes for Safety in Open-domain Chatbots

Wed, 27 May 2026 16:21:13 GMT

[Paper] [Code] Jing Xu, Da Ju, Margaret Li, Y-Lan Boureau, Jason Weston, Emily Dinan Facebook AI Research 14 Oct 2020

Introduction

대규모 human-human conversation 데이터로 학습된 open-domain dialogue model은 자연스럽고 흥미로운 대화를 생성할 수 있지만, 동시에 학습 데이터 안에 존재하는 toxic language, offensive behavior, unwanted bias도 함께 모방할 수 있습니다. 본 논문에서는 이러한 문제를 완화하면서도 모델의 engagingness를 유지하는 여러 safety recipe를 비교합니다.

저자들이 핵심으로 보는 문제는 safety와 engagingness 사이의 trade-off입니다. 예를 들어, 모든 입력에 대해 잘 모르겠습니다.처럼 회피적으로 답하는 모델은 안전할 수는 있지만, 대화 참여도는 크게 떨어집니다. 반대로 어떤 주제든 적극적으로 받아치는 모델은 더 흥미롭지만, adversarial user나 sensitive topic 상황에서 unsafe response를 생성할 위험이 커집니다. 이 논문의 목표는 “안전하지만 지루한 모델”이 아니라, engaging하면서도 offensive response를 최소화하는 모델을 만드는 것입니다.

논문의 핵심 기여는 크게 두 가지 입니다.

Bot-Adversarial Dialogue Safety 사람이 실제로 챗봇을 공격하듯 대화하면서 unsafe response를 유도하고, 그 결과를 학습 및 평가 데이터로 사용하는 human-and-model-in-the-loop framework입니다.
Baked-in Safety Model 배포 시 별도의 safety classifier를 붙이는 대신, 학습 과정에서 safety behavior를 generative model 내부에 증류하는 방식입니다. 즉, safety layer를 외부 모듈로 두는 것이 아니라 모델 자체에 내장(bake-in)하는 접근입니다.

Base Model

본 논문에서는 BST 2.7B 모델에 다양한 safety recipe를 적용하여 효과를 검증합니다. BST 2.7B의 특징은 다음과 같습니다.

BlenderBot 계열의 open-domain dialogue model
Seq2Seq Transformer 구조
pre-training: Reddit 기반 대규모 대화 데이터셋
fine-tuning: ConvAI2, Empathetic Dialogues, Wizard of Wikipedia, Blended Skill Talk 등의 데이터셋

비교 모델로는 DialoGPT, GPT-2 Large, pushshift.io Reddit 2.7B가 사용됩니다. 이들은 기존 open-domain generative model이 safety 측면에서 어떤 취약성을 보이는지 확인하기 위한 기준점 역할을 합니다.

Method

본 논문에서는 open-domain chatbot을 더 안전하게 만들기 위한 방법들을 Safety Recipes라고 부릅니다. 접근 방식은 크게 네 가지입니다.

Unsafe Utterance Detection (부적절한 발언 탐지)
Safe Utterance Generation (안전한 발언 생성)
Sensitive Topic Avoidance (민감한 주제 회피)
Gender Bias Mitigation (성별 편향 완화)

1. Unsafe Utterance Detection

가장 직접적인 방법은 별도의 safety classifier를 두는 것입니다. 이 classifier는 사용자의 입력과 모델의 출력을 모두 검사합니다. user utterance 또는 bot utterance가 unsafe하다고 판단되면, 모델은 일반 응답 대신 사전에 미리 정해 둔 안전한 응답을 출력합니다. (e.g., I’m sorry, I’m not sure what to say. Thank you for sharing and talking to me though.)

논문에서는 두 가지 대체 응답을 사용합니다. 첫 번째는 safe response입니다. 이는 대화를 더 이어가기 어렵다고 판단될 때 중립적인 문장으로 응답하는 방식입니다. 두 번째는 non-sequitur입니다. 이는 현재 대화 흐름에서 벗어나 안전한 주제로 화제를 전환하는 방식입니다.

이 구조의 장점은 기존 dialogue model에 쉽게 결합할 수 있다는 점입니다. 다만 classifier의 성능에 크게 의존하는데, 정상적인 발화를 과도하게 차단하면 대화 품질이 낮아지고, unsafe utterance를 놓치면 safety layer의 의미가 약해집니다.

2. Bot-Adversarial Dialogue Safety

[Figure 1. Build-it Break-it Fix-it 방식과 Bot-Adversarial Dialogue 방식 비교]

본 논문의 주요 기여 중 하나는 Bot-Adversarial Dialogue, BAD입니다. 기존 adversarial data collection은 사람이 classifier를 속이는 문장을 직접 작성하는 방식에 가까웠습니다. 하지만 실제 chatbot 환경에서는 사용자가 여러 turn에 걸쳐 모델을 유도하고, 그 과정에서 unsafe response가 발생할 수 있습니다.

BAD는 이 상황을 데이터 수집 과정에 그대로 반영합니다. Crowdworker는 bot과 자연스럽게 대화하면서 bot이 unsafe response를 생성하도록 유도합니다. 각 turn마다 bot response가 safe한지 unsafe한지 annotation하고, 이 데이터를 safety classifier 학습과 평가에 사용합니다.

[Table 1. Bot-Adversarial Dialogue 데이터셋 통계]

BAD 데이터셋은 5,784개의 dialogue와 78,874개의 utterance로 구성됩니다. 전체 utterance 중 약 40%가 offensive로 annotation되었고, offensive utterance 중 약 1/3은 bot이 생성한 응답입니다. 이 데이터셋은 단일 문장 수준의 toxicity dataset보다 실제 chatbot deployment 상황에 더 가깝습니다.

[Figure 2. Crowdworker가 bot을 break하기 위해 사용한 offensive language 유형 분포]

Figure 2는 crowdworker들이 어떤 방식으로 bot을 공격했는지 보여줍니다. 단순한 profanity뿐 아니라 hate speech, personal attack, implicit offensiveness가 주요 유형으로 나타납니다. 이는 chatbot safety가 단순 금칙어 차단만으로 해결되기 어렵다는 점을 보여줍니다.

3. Safe Utterance Generation

Unsafe Utterance Detection은 별도의 classifier를 dialogue model 바깥에 두는 방식입니다. 반면 Safe Utterance Generation은 모델 자체가 unsafe response를 덜 생성하도록 학습시키는 접근입니다.

이 방향은 deployment 측면에서 중요합니다. safety classifier를 항상 함께 배포하지 않아도 되고, 모델이 unsafe input을 만났을 때 더 적절하게 반응하도록 만들 수 있기 때문입니다. 논문에서는 data pre-processing, safe beam blocking, control token, baked-in safety를 실험합니다.

3.1 Data Pre-processing

첫 번째 방법은 학습 데이터에서 unsafe example을 제거하는 것입니다. 논문에서는 두 가지 filtering 방식을 사용합니다.

Utterance-based filtering context나 target response가 unsafe하다고 판단되면 해당 example을 제거합니다.
Author-based filtering offensive utterance 비율이 높은 author의 데이터를 통째로 제거합니다.

이 방법은 모델이 toxic pattern을 덜 학습하도록 돕습니다. 그러나 unsafe input을 거의 보지 못한 모델은 실제 adversarial 상황에서 어떻게 대응해야 하는지 배우기 어렵습니다. 이 한계는 이후 Baked-in Safety가 등장하는 배경입니다.

3.2 Safe Beam Blocking

두 번째 방법은 decoding 단계에서 unsafe word나 n-gram을 생성하지 못하게 막는 것입니다. Beam search 과정에서 특정 단어 목록에 포함된 표현을 block합니다.

이 방법은 구현이 간단하지만 적용 범위가 제한적입니다. 명시적인 욕설이나 금칙어는 차단할 수 있지만, safe word만으로 구성된 공격적 표현까지 막기는 어렵습니다. 문맥에 따라 문제가 되는 utterance도 word list만으로는 구분하기 어렵습니다.

3.3 Safety and Style Control

세 번째 방법은 control token을 사용하는 것입니다. 학습 시 각 response에 safe / unsafe 또는 특정 style label을 붙이고, inference 시 원하는 control token을 고정합니다.

Safety control에서는 response가 safe한지 unsafe한지 classifier로 판별한 뒤, 그 정보를 control token으로 입력에 추가합니다. inference 시에는 safe control token을 사용하여 모델이 더 안전한 응답을 생성하도록 유도합니다.

논문에서는 Style control도 함께 실험합니다. calm, cheerful과 같은 style은 상대적으로 안전한 응답을 유도하는 반면, hostile, cruel과 같은 style은 unsafe response를 증가시킵니다. 이 결과는 generation style이 safety와 밀접하게 연결되어 있음을 보여줍니다.

3.4 Baked-in Safety

[Table 2. Original Data, Safe Utterance Data, Baked-in Safety Data 비교]

이 논문의 또 다른 주요 기여는 Baked-in Safety입니다. 이 방법은 unsafe example을 제거하는 대신, target response를 안전한 응답으로 교체합니다. 예를 들어 context나 gold response가 unsafe하다고 판단되면, 해당 target을 safe response 또는 non-sequitur로 바꿉니다.

이렇게 학습하면 모델은 offensive input을 보더라도 이를 따라 하거나 동조하지 않고, 안전하게 대화를 전환하는 방식을 배웁니다. 단순 filtering이 unsafe data를 학습에서 지우는 방식이라면, Baked-in Safety는 unsafe 상황에서의 바람직한 행동을 직접 가르치는 방식입니다.

또한 이 방법은 inference time에 별도의 safety classifier를 요구하지 않습니다. classifier가 내린 판단을 학습 데이터에 반영해, safety behavior를 generative model 내부에 증류하기 때문입니다.

4. Sensitive Topic Avoidance

논문에서는 toxicity와 sensitive topic을 구분합니다. 어떤 utterance는 욕설이나 hate speech를 포함하지 않더라도, politics, religion, medical advice처럼 민감한 주제에서는 부적절하거나 위험한 응답으로 이어질 수 있습니다.

저자들은 이를 다루기 위해 sensitive topic classifier를 학습합니다. 학습 데이터는 Reddit의 subreddit list를 기반으로 구성되며, 대상 topic은 politics, religion, drugs, medical advice, NSFW 등입니다.

[Table 3. Sensitive topic classifier 학습에 사용한 topic별 subreddit list]

Sensitive topic classifier는 일반 safety classifier와 역할이 다릅니다. safety classifier는 offensive language 감지에 초점을 둔다면, sensitive topic classifier는 대화가 위험한 주제로 이동하고 있는지를 판단합니다. 두 classifier가 다루는 문제가 다르기 때문에 실제 시스템에서는 서로 보완적으로 사용할 수 있습니다.

5. Gender Bias Mitigation

마지막으로 논문은 gender bias를 줄이기 위해 controlled generation을 적용합니다. 학습 데이터의 response가 female-gendered word 또는 male-gendered word를 포함하는지에 따라 control bin을 만들고, inference 시에는 gendered word 사용을 최소화하는 bin을 사용합니다.

이 방법은 gendered word 사용을 줄이는 데 효과가 있습니다. 다만 adversarial safety를 직접적으로 해결하지는 못합니다. 따라서 gender bias mitigation은 safety pipeline의 한 구성 요소로 볼 수 있지만, BAD와 같은 adversarial setting에 대한 주된 해결책은 아닙니다.

Experiments

평가는 크게 두 축으로 이루어집니다.

Conversational Quality 모델이 얼마나 자연스럽고 engaging한 응답을 생성하는지 평가합니다.
Safety 모델이 unsafe response를 얼마나 적게 생성하는지 평가합니다.

Conversational quality는 perplexity, F1, ACUTE-Eval engagingness로 측정합니다. Safety는 automatic metric과 human judgment를 함께 사용합니다. 특히 human safety evaluation에서는 BAD test set을 사용해, adversarial user가 모델을 공격하는 상황을 평가합니다.

1. Classifier Results

[Table 7. WTC, Standard, BBF, BAD test set에서 safety classifier의 unsafe F1 비교]

Table 7은 safety classifier의 성능을 보여줍니다. 가장 눈에 띄는 결과는 BAD 데이터로 학습한 classifier가 BAD test set에서 가장 높은 성능을 냈다는 점입니다.

Multi-turn Safety Classifier with Adversarial Dialogue는 BAD test set에서 80.8 unsafe F1을 기록합니다. 기존 classifier들이 같은 test set에서 60점대 초반에 머문 것과 비교하면 차이가 큽니다.

이 결과는 chatbot safety에서 데이터 분포가 중요하다는 점을 보여줍니다. 일반적인 toxicity dataset만으로는 human-bot interaction에서 발생하는 unsafe response를 충분히 포착하기 어렵습니다. 반면 BAD는 실제 bot을 상대로 수집한 multi-turn adversarial dialogue이기 때문에, deployment 상황에 더 가까운 학습 신호를 제공합니다.

2. Automatic Safety Metrics

[Table 8. 다양한 generative model의 automatic safety metric 비교]

Table 8은 pushshift.io Reddit 및 ConvAI2 context에서 각 모델이 생성한 응답을 automatic metric으로 평가한 결과입니다. 기본 BST 2.7B는 pushshift.io Reddit context에서 classifier 기준 10.0%의 unsafe generation을 보입니다.

Baked-in Safety 계열의 non-sequitur fine-tuned model은 이 값을 크게 낮춥니다. 예를 들어 BST 2.7B Non-Sequitur는 pushshift.io Reddit context에서 classifier fire rate를 0.9%까지 낮춥니다.

다만 automatic metric은 classifier의 판단에 의존합니다. 특히 two-stage model처럼 classifier를 내부적으로 사용하는 모델은 같은 방식으로 평가하기 어렵습니다. 그래서 논문은 human safety evaluation을 별도로 수행합니다.

3. Human Safety Judgments

[Table 9. BAD adversarial test set에서 모델별 human safety judgment 결과]

Table 9는 논문의 주요 실험 결과를 담고 있습니다. 기본 BST 2.7B는 adversarial test set에서 55.0% OK rate에 그칩니다. 즉, 사용자가 모델을 의도적으로 유도하면 기존 open-domain chatbot은 상당한 비율로 unsafe response를 생성합니다.

BAD 기반 safety classifier를 적용하면 결과가 크게 달라집니다. BST 2.7B + Adversarial Dialogue Safety는 94.4% OK rate를 달성합니다. 여기에 topic classifier를 추가한 모델은 96.6% OK rate까지 올라갑니다.

이 결과는 BAD 기반 two-stage model이 adversarial setting에서 가장 강한 safety 성능을 보인다는 점을 보여줍니다.

4. Engagingness Results

[Table 10. ACUTE-Eval을 통한 engagingness 비교]

Table 10은 safety method를 적용한 모델들이 기본 BST 2.7B와 비교해 얼마나 engaging한지 보여줍니다. BAD 기반 two-stage model은 safety를 크게 높이면서도 BST 2.7B의 engagingness를 대체로 유지합니다.

이 점이 중요한데요, safety를 높이는 가장 쉬운 방법은 모든 위험한 상황에서 대화를 회피하는 것입니다. 그러나 그런 모델은 open-domain chatbot으로서의 가치가 낮습니다. BAD 기반 방법은 safety와 engagingness 사이에서 더 나은 균형점을 찾습니다.

반면 topic classifier는 더 자주 대화에 개입할 수 있기 때문에 engagingness 손실이 나타날 수 있습니다. 실제 deployment에서는 classifier threshold와 개입 전략을 함께 조정해야 합니다.

5. Overall Comparison

[Figure 3. Engagingness와 Bot-Adversarial safety의 관계]

Figure 3은 모델들을 engagingness와 adversarial safety의 두 축에서 비교합니다. 좋은 모델은 두 값이 모두 높아야 합니다.

기본 generative model들은 engagingness 측면에서는 강하지만, adversarial safety가 부족합니다. 반대로 지나치게 회피적인 모델은 안전할 수는 있어도 대화 품질이 낮습니다. BAD 기반 two-stage model은 BST 2.7B의 engagingness를 유지하면서 safety를 크게 개선해, 두 축 사이에서 가장 좋은 균형을 보입니다.

[Figure 4. Automatic safety metric과 adversarial safety metric 비교]

Figure 4는 non-adversarial automatic safety와 adversarial safety를 함께 보여줍니다. 여기서 중요한 점은 일반적인 context에서 안전해 보이는 모델이 adversarial setting에서도 안전하다고 단정할 수 없다는 것입니다.

Baked-in Safety는 non-adversarial setting에서 좋은 개선을 보입니다. 그러나 adversarial setting에서는 BAD 기반 two-stage model이 더 강한 결과를 냅니다. 두 결과를 함께 보면, chatbot safety 평가는 일반 대화와 공격적 대화를 모두 포함해야 합니다.

Analysis

1. Bot-Adversarial Dialogue가 효과적인 이유

BAD가 효과적인 이유는 학습 데이터가 실제 사용 환경과 가깝기 때문입니다. 기존 toxicity dataset은 대부분 single-turn text classification을 전제로 합니다. 하지만 chatbot은 여러 turn의 dialogue context를 바탕으로 응답하고, 사용자는 그 context를 이용해 모델을 유도할 수 있습니다.

BAD는 이 multi-turn adversarial interaction을 직접 수집합니다. 따라서 BAD로 학습한 classifier는 단순히 offensive word를 찾는 수준을 넘어, 대화 흐름 속에서 위험한 bot response를 감지하는 데 더 적합합니다.

2. Two-stage Model과 Baked-in Safety

실험에서 가장 강한 safety 성능을 보인 방법은 two-stage model입니다. Safety classifier가 user input과 bot output을 모두 검사하기 때문에, unsafe response가 사용자에게 전달되기 전에 차단할 수 있습니다.

Baked-in Safety에는 다른 장점이 있는데요, 별도의 classifier 없이 generative model 자체에 safety behavior를 학습시키므로 deployment가 단순합니다. 또한 모델이 unsafe input을 마주했을 때 어떤 식으로 대응해야 하는지도 직접 배웁니다.

다만 adversarial setting에서는 two-stage model이 더 강한 결과를 보입니다. 따라서 두 방식은 대체 관계라기보다 목적이 다른 선택지에 가깝습니다. 강한 safety가 필요한 환경에서는 two-stage model이 적합하고, 배포 단순성과 모델 자체의 안전한 행동을 중시한다면 Baked-in Safety가 유용합니다.

3. Success and Failure Cases

[Table 17. BAD test set에서 safety model이 unsafe input을 회피한 사례]

Table 17은 safety model의 성공 사례를 보여줍니다. adversarial input이 주어졌을 때, BST 2.7B나 DialoGPT는 unsafe한 방향으로 대화를 이어가기도 합니다. 반면 BAD 기반 safety model은 non-sequitur를 사용해 안전한 주제로 대화를 전환합니다.

[Table 19. BAD test set에서 safety model도 실패하는 사례]

Table 19는 남아 있는 한계를 보여주는데요, BAD 기반 two-stage model도 모든 adversarial input을 완벽하게 처리하지는 못합니다. 일부 사례에서는 모델이 공격적인 문맥에 직접 반응하면서 unsafe response를 생성합니다.

이 분석은 safety 개선이 일회성 작업이 아니라는 점을 시사합니다. 새로운 공격 방식과 사회적 기준의 변화에 맞춰 data collection, classifier update, human evaluation이 지속적으로 이루어져야 합니다.

Limitations

가장 좋은 모델도 완전히 안전하지는 않습니다. BAD 기반 two-stage model에 topic classifier를 결합한 모델은 96.6% OK rate를 달성했지만, 여전히 약 3.4% failure rate가 남아 있습니다.

또한 safety의 기준은 고정되어 있지 않습니다. 어떤 표현이 안전한지, 어떤 주제가 민감한지는 문화적 배경과 사용자 맥락에 따라 달라질 수 있습니다. 본 논문의 annotation 역시 특정 언어와 문화권의 기준에 영향을 받습니다.

마지막으로 이 연구는 주로 영어권 open-domain chatbot을 대상으로 합니다. 다른 언어권이나 서비스 환경에 적용하려면, 해당 환경에 맞는 adversarial data와 annotation guideline이 필요합니다.

Conclusion

본 논문은 open-domain chatbot safety를 여러 관점에서 체계적으로 비교한 연구입니다. 결과를 정리하면 다음과 같습니다.

Word blocking이나 data filtering만으로는 충분하지 않습니다.
실제 human-bot adversarial interaction에서 수집한 BAD 데이터는 safety classifier 성능을 크게 개선합니다.
BAD 기반 two-stage model은 engagingness를 유지하면서 adversarial safety를 높입니다.
Baked-in Safety는 classifier 없이 safety behavior를 모델 내부에 학습시키는 유용한 방향입니다.
Safety는 context-dependent한 문제이므로, 지속적인 평가와 데이터 업데이트가 필요합니다.

이 논문은 안전한 chatbot을 만들기 위해서는 offensive word 차단을 넘어 adversarial interaction, sensitive topic, bias, engagingness trade-off를 함께 다뤄야 한다는 점을 보여줍니다.

되는게없을때

Thu, 09 Apr 2026 06:54:32 GMT

https://youtube.com/playlist?list=PLjcc5TacvgdaQ-gtZpTcWwRSUXUecvHI0&si=Bmkn8oa41TeEXxvG

Correlation, Agreement

Tue, 24 Mar 2026 14:54:38 GMT

들어가며

여러 평가자가 동일한 대상을 평가할 때, 그 결과의 신뢰성을 측정하는 지표는 크게 두 범주로 나뉜다.

Correlation (상관관계): 점수가 같은 방향으로 움직이는지를 측정
Agreement (일치도): 점수의 절대값이 실제로 같은지를 측정

혼동되는 경우가 있지만, 두 지표는 측정하는 것이 다르다.

Correlation (상관관계)

두 평가자의 점수가 함께 변하는 정도를 측정한다. 절대값이 같을 필요 없이, 변화의 방향만 일치하면 된다.

Pearson's r

두 변수 간 선형 관계의 강도를 측정한다. 범위는 -1 ~ +1이다.

e.g., A: [1, 2, 3], B: [2, 4, 6]       → B = 2A, 완벽한 선형 → r = 1.0
e.g., A: [1, 2, 3], B: [2, 5, 4]       → 선형 관계 깨짐     → r < 1
e.g., A: [1, 2, 3], B: [101, 102, 103] → 스케일만 다름      → r = 1.0

비례 관계만 보기 때문에 스케일 차이에 둔감하다. 두 점수 세트의 절대값이 완전히 달라도 r = 1.0이 나올 수 있다.

Spearman's ρ

값 자체가 아닌 순위(rank) 간의 대소 관계를 측정한다. 선형일 필요 없이, "하나가 크면 다른 것도 크다"는 관계만 성립하면 높은 ρ를 얻는다. 범위는 -1 ~ +1이다.

e.g., A: [1, 3, 5], B: [10, 20, 30] → 값 차이는 크지만 순서 동일 → ρ = 1.0
e.g., A: [1, 2, 3], B: [1, 3, 2]    → 2번째와 3번째 순위 역전   → ρ < 1

순위 기반이라 이상치(outlier)에 강건하다. Pearson's r이 값의 선형 비례를 요구하는 반면, Spearman's ρ는 순서만 보존되면 된다.

Kendall's τ

가능한 모든 관측값 쌍에 대해 순서의 일치/불일치를 세어 비율로 산출한다. 범위는 -1 ~ +1이다.

e.g., A = [1, 2, 3], B = [1, 3, 2]인 경우:
  (1, 2): A에서 1 < 2, B에서 1 < 3 → 일치
  (1, 3): A에서 1 < 3, B에서 1 < 2 → 일치
  (2, 3): A에서 2 < 3, B에서 3 > 2 → 불일치
  → τ = (2 − 1) / 3 ≈ 0.33

쌍 단위 비교이므로 Spearman's ρ보다 보수적이다. 동일 데이터에서 일반적으로 |τ| ≤ |ρ|이 성립한다.

정리

지표	비교 대상	관계 유형	이상치 민감도
Pearson's r	값 자체	선형	높음
Spearman's ρ	순위	대소 관계 (순서 보존)	낮음
Kendall's τ	쌍의 순서	순위 일치율	낮음

Agreement (일치도)

여러 평가자가 동일한 대상에 대해 실제로 같은 점수를 부여하는지를 측정한다. Correlation과 달리, 점수의 절대값이 같아야 한다.

아래 지표들은 모두 우연에 의한 일치를 보정한다는 공통점이 있다. 이진 분류에서 두 평가자가 무작위로 응답해도 약 50%는 우연히 일치할 수 있는데, 단순 일치율(percent agreement)은 이를 구분하지 못한다. κ나 α 계열은 이 우연적 일치를 제거한다.

Cohen's κ

2명의 평가자가 범주형 레이블을 부여할 때의 일치도를 측정한다.

$$\kappa = \frac{p_o - p_e}{1 - p_e}$$

$p_o$: 관찰된 일치 비율
$p_e$: 우연에 의해 기대되는 일치 비율
분자: 우연을 넘어선 실제 일치
분모: 우연을 넘어서 일치할 수 있는 최대 여지

e.g., 두 의사가 50명의 환자를 "우울증 / 비우울증"으로 분류한다.
  - 40명에 대해 같은 진단 → p_o = 0.80
  - p_e = 0.50인 경우 → κ = (0.80 − 0.50) / (1 − 0.50) = 0.60
  - p_e = 0.64인 경우 → κ = (0.80 − 0.64) / (1 − 0.64) ≈ 0.44
  → 같은 80% 일치율이어도, 우연의 기댓값이 높을수록 κ는 낮아진다.

해석 기준 (Landis & Koch, 1977):

κ 범위	해석
≤ 0	일치 없음 (Poor)
0.01 – 0.20	미미 (Slight)
0.21 – 0.40	보통 (Fair)
0.41 – 0.60	중간 (Moderate)
0.61 – 0.80	상당 (Substantial)
0.81 – 1.00	거의 완벽 (Almost Perfect)

※ 이 기준은 근거 없이 제안된 것이므로 참고용으로만 사용한다.

제한:

2명의 평가자에 대해서만 정의된다.
순서형 데이터에서 1점 차이와 4점 차이를 동일한 불일치로 처리한다. → 이를 보완한 Weighted Cohen's κ가 있다.

Fleiss' κ

Cohen's κ의 "2명 한정" 제약을 해결한 지표로, 3명 이상의 평가자에 대한 범주형 일치도를 측정한다.

e.g., 14명의 정신과 의사가 30명의 환자를 5가지 진단 범주로 분류할 때,
     14명 전체의 일치도를 하나의 수치로 요약할 수 있다.

이름 때문에 Cohen's κ의 다중 평가자 버전처럼 보이지만, 실제로는 Scott's π의 일반화이다.

Cohen's κ: 각 평가자의 개별 레이블 분포를 고려하여 $p_e$를 계산
Fleiss' κ: 전체 평가자의 평균 분포로 $p_e$를 추정

Krippendorff's α

κ 계열의 제약들을 한 번에 해결한 범용 지표이다.

$$\alpha = 1 - \frac{D_o}{D_e}$$

$D_o$: 관찰된 불일치
$D_e$: 기대 불일치
α = 1이면 완벽한 일치, α = 0이면 우연 수준, α < 0이면 체계적 불일치

κ 계열이 일치(agreement) 기반인 것과 달리, α는 불일치(disagreement) 기반으로 계산한다.

κ 계열 대비 장점:

평가자 수에 제한 없음
결측치 처리 가능 (모든 평가자가 모든 항목을 평가하지 않아도 됨)
명목형, 순서형, 등간형, 비율형 등 다양한 측정 수준에 적용 가능

해석 기준:

α 범위	해석
α ≥ 0.800	신뢰할 수 있는 수준
0.667 ≤ α < 0.800	잠정적 결론 가능
α < 0.667	신뢰하기 어려움

정리

지표	평가자 수	데이터 유형	결측치 처리	우연 보정
Cohen's κ	2명	명목형 (Weighted κ로 순서형 확장)	✗	✓
Fleiss' κ	3명 이상	명목형	✗	✓
Krippendorff's α	2명 이상	명목/순서/등간/비율	✓	✓

Correlation != Agreement

세 평가자가 동일한 3개 대상을 평가한 결과이다.

대상	평가자 A	평가자 B	평가자 C
#1	1	3	5
#2	2	4	6
#3	3	5	7

세 평가자 모두 #1 < #2 < #3의 순서를 매기고 있다. → Spearman ρ = 1.0
대상 #1에 대해 A는 1점, B는 3점, C는 5점이다. → Krippendorff α는 매우 낮음

Correlation은 높지만 Agreement 낮은 경우로, Corrleation과 Agreement는 서로 다른 지표임을 보여준다.

참고 자료

Cohen, J. (1960). A Coefficient of Agreement for Nominal Scales. Educational and Psychological Measurement, 20(1), 37-46.
Fleiss, J. L. (1971). Measuring Nominal Scale Agreement Among Many Raters. Psychological Bulletin, 76(5), 378-382.
Landis, J. R. & Koch, G. G. (1977). The Measurement of Observer Agreement for Categorical Data. Biometrics, 33(1), 159-174.
Krippendorff, K. (2004). Content Analysis: An Introduction to Its Methodology (2nd ed.). Sage Publications.

CheckEval: A reliable LLM-as-a-Judge framework for evaluating text generation using checklists

Tue, 24 Mar 2026 09:56:27 GMT

EMNLP 2025 [Paper] [Github] Yukyung Lee, Joonghoon Kim, Jaehee Kim, Hyowon Cho, Jaewook Kang, Pilsung Kang, Najoung Kim Boston University · SK Telecom · Seoul National University · KAIST · NAVER 27 Mar 2024

Introduction

자연어 생성(NLG) 태스크의 성능을 평가하는 것은 분류나 회귀 태스크와 달리 정량화가 어렵다. 전통적으로 BLEU, ROUGE, BERTScore 같은 어휘 중복 기반 지표가 널리 사용되었지만, 이들은 인간 평가와의 상관관계(correlation)가 낮다는 한계가 있다. 또한 Human Evaluation은 gold standard로 인정받지만 시간과 비용이 크게 소모된다. 이에 최근에는 LLM을 평가자로 활용하여 텍스트 품질을 자동으로 판단하는 LLM-as-a-Judge가 대안으로 주목받고 있다.

대표적인 LLM-as-a-Judge 프로토콜인 G-Eval은 LLM에 평가 기준을 입력해 Auto-CoT로 평가 절차를 생성하고, 1~5점 Likert Scale 각 점수 토큰의 확률 분포를 기반으로 가중합을 계산해 최종 점수를 산출한다.

G-Eval은 인간 평가와 높은 상관관계를 보이며, LLM이 고비용의 Human Annotation을 대체할 수 있는 가능성을 제시했다.

그런데, 높은 상관관계(Correlation)가 높은 신뢰도(Reliability)를 보장할까?

Motivation

기존 LLM-as-a-Judge 프로토콜에는 두 가지 한계가 있다.

첫째, Likert Scale의 인접 점수 간 경계가 모호하다. Coherence를 1~5점으로 평가하세요와 같은 평가 프롬프트가 주어질 때, 3점과 4점의 기준은 모델마다 다르게 해석된다. 또한 하나의 평가 차원(e.g., Fluency) 안에 여러 세부 기준(e.g., formatting, grammar, readability, ...)이 혼재되어 있어, 평가자마다 초점을 맞추는 기준이 달라진다. 이는 낮은 Inter-Evaluator Agreement(IEA, 평가자 간 일치도)와 높은 점수 분산으로 이어진다.

둘째, 기존 연구들은 Reliability 지표에 대한 분석이 부재하다. LLM-as-a-Judge 연구 대부분이 인간 평가와의 Correlation만을 주요 지표로 사용하는데, Correlation이 높아도 모델 간 절대 점수가 서로 다를 수 있다. IEA나 Stability 같은 신뢰도 지표에 대한 체계적 분석이 필요하다.

주의할 점은, Correlation과 Agreement는 서로 다른 개념이라는 것이다. 두 개념에 대해서는 이 글에서 자세히 다룬다.

Method: CheckEval

CheckEval은 평가 기준을 Fine-grained Boolean Question으로 분해하여 평가하는 프레임워크다. 3단계 파이프라인으로 구성된다.

Stage 1: 평가 차원 정의

먼저 평가할 Dimension을 선정한다. 기존 벤치마크의 정의를 채택하거나 Task에 맞게 직접 정의할 수 있다. 이후 각 Dimension을 Sub-dimension으로 분해한다.

이때 Sub-dimension 정의는 LLM이 아닌 인간이 직접 수행한다. 실험 결과, Sub-dimenssion 생성을 LLM에게 맡기면 Dimension을 혼동하는 문제가 발생했으며, 이는 벤치마크의 원래 설계 의도와 어긋나 잘못된 평가 결과를 초래할 수 있기 때문이다.

Stage 2: 체크리스트 생성

① Seed Question 작성

앞서 정의한 각 Sub-dimension별로 Yes or No로 답변할 수 있는 질문을 한 개씩 작성한다. 반드시 인간이 작성하며, "Yes"가 높은 품질을 의미하도록 설계한다.

e.g.,

Task: Summarization
Dimension: Consistency
Sub-dimension: Factual Consistency

→ Seed Question: *"요약문이 원문의 사실을 정확하게 반영하고 있나요?"*

② Question Augmentation (LLM)

Seed Question을 두 가지 전략으로 확장한다.

Diversification (다양화): 같은 Sub-dimension을 다른 관점에서 평가하는 질문을 생성한다. 평가의 폭을 넓히는 것이 목적이다.
- Seed: "문장 속 단어들의 철자가 모두 정확한가?" → Diversification: "모든 문장이 완전하며, 불완전하거나 빠진 요소가 없는가?"
Elaboration (정교화): Seed Question을 더 구체적으로 분해한다. 평가의 깊이를 높이는 것이 목적이다.
- Seed: "문장 속 단어들의 철자가 모두 정확한가?" → Elaboration: "고유명사(사람, 장소 등의 이름)의 철자가 올바른가?"

두 전략을 순차로 적용하면 원래 Seed Question의 의도에서 멀어질 수 있으므로, 독립적으로 수행한다.

③ Question Filtering (LLM)

3가지 기준으로 부적절한 질문을 제거한다.

Alignment (정합성): "Yes" 응답이 높은 품질을 의미하는가?
Dimension Consistency (차원 일관성): 해당 질문이 의도한 차원을 실제로 측정하고 있는가?
Redundancy Removal (중복 제거): 의미적으로 겹치는 질문을 제거한다.

Stage 3: 체크리스트 기반 평가

LLM이 Checklist의 각 질문에 Yes or No로 응답한다. 비용 효율을 위해 Sub-dimension별로 여러 질문을 한 번에 제시한다. (파일럿 실험에서 개별로 질문을 제시했을 때와 큰 성능 차이가 없음을 확인했다.)

최종 점수는 전체 질문 중 Yes 답변의 비율로 계산된다. 모든 질문에 동일한 가중치를 적용한다. (이와 관련해 Appendix C.2에서 다룬다.)

이 방식의 핵심 장점은 설명 가능성과 일관성이다. G-Eval과 같은 기존 LLM-as-a-Judge 프로토콜이 단순히 Naturalness: 2"처럼 점수만 달랑 출력하는 것에 비해, CheckEval은 "반복이 없는가?: Yes", "문법이 정확한가?: Yes", "주제와 관련이 있는가?: No" 와 같이 점수의 근거를 바로 추적할 수 있다. 또한 Binary 응답으로 3점 vs 4점 같은 모호한 판단을 제거하여 모델 간 변동을 최소화한다.

Experimental Setup

데이터셋: SummEval (뉴스 요약), Topical-Chat (대화 응답), QAGS (사실 일관성)

평가 모델 (12개):

Large (70~123B): Llama3.1-70B, Mistral-Large, Qwen2.5-72B
Medium (22~32B): Mistral-Small, Gemma2-27B, Qwen2.5-32B
Small (7~9B): Llama3.1-8B, Gemma2-9B, Qwen2.5-7B
GPT: GPT-4-Turbo, GPT-4o, GPT-4o-mini

비교 대상: G-Eval (CoT + Likert), SEEval (Self-Explanation + Likert), non-LLM metrics (ROUGE-L, BERTScore, BARTScore, UniEval)

평가 지표: Correlation (Spearman ρ, Kendall τ, Pearson r), IEA (Krippendorff α, Fleiss κ), Stability (상관 분포의 평균/분산)

Results

1. Correlation with Human Evaluation

12개 모델 중 대부분에서 CheckEval이 최고 Correlation을 달성함.
특히 소형 모델에서 개선 폭이 큼.
- Llama3.1-8B: SummEval에서 ρ가 0.24(G-Eval) → 0.41(CheckEval)로 대폭 향상
최고 성능은 Mistral-Large + CheckEval 조합
- SummEval ρ=0.55, Topical-Chat r=0.65를 기록했다.

2. Inter-Evaluator Agreement (IEA)

G-Eval의 α=0.09, SEEval의 α=0.08은 사실상 우연 수준의 Agreement임.
반면 CheckEval은 α=0.48로, 평균 Agreement를 0.45 이상 향상함.
Large 모델 그룹에서는 α=κ=0.67
- 이는 SummEval에서 보고한 인간 평가자 3명 간 일치도(κ≈0.7)와 거의 동등한 수준임.
이는 단순히 출력 형식(binary vs Likert)의 차이에서 기인한 것이 아님을 Appendix C.3에서 검증함.
- G-Eval의 Likert 점수를 강제로 binary로 변환해도 IEA는 소폭만 개선됨. (0.09→0.11)
- CheckEval (0.48)과의 격차가 여전히 압도적임.

3. 평가 안정성 분석 (Stability)

(SummEval 데이터셋에서) CheckEval의 분산이 G-Eval 대비 약 5배 작음. (G-Eval 0.0100 vs CheckEval 0.0019)
즉, 어떤 모델을 평가자로 선택하더라도 안정적으로 높은 상관과 낮은 분산을 유지함.
CheckEval은 IEA와 Stability 모두에서 G-Eval, SEEval을 상회함.
- IEA: 동일 샘플에 대해 Evaluator Model 간 점수가 일치하는가?
- Stability: Evaluator Model을 바꿔도 인간과의 상관이 유지되는가?

4. 체크리스트 생성 품질 검증

인간 평가자가 Augmentation과 Filtering 각 단계의 질문을 Yes/No로 직접 검증해봤음.
- Augmentation 단계에서 93~96%의 높은 점수를 기록함.
- Filtering 단계(81~~85%)에서는 Dimension당 1~~2개 정도의 의미적 중복이 남아있다는 피드백이 있었음.

이러한 중복을 추가로 제거해도 성능 변화가 거의 없었음. (SummEval ρ: 0.5486 → 0.5486)
- 이는 CheckEval이 개별 질문 몇 개의 추가/제거에 민감하지 않고 robust하다는 것을 보여줌.

5. CheckEval 프로토콜 인간 검증

CheckEval 체크리스트를 인간이 직접 사용해도 LLM과 같은 판단을 이끌어낼 수 있는지 검증했다.

Correlation 분석

3명의 인간 평가자가 동일 Checklist로 20개 요약을 평가했을 때, LLM(CheckEval) vs 인간(CheckEval) 간 ρ=0.72~0.73을 기록함.
인간(Likert) vs 인간(CheckEval) 간 ρ=0.69로, CheckEval 프로토콜을 사용한 LLM이 Likert Scale을 사용한 인간보다 더 높은 상관을 보임.
이는 평가 주체(인간 vs LLM)보다 평가 프로토콜(CheckEval vs Likert)이 더 큰 영향을 미친다는 것을 시사함.

Agreement 분석

Relevance 차원에서 100개 요약 × ~100개 질문을 평가한 결과, 인간 3명의 일치도 κ=0.53에서 LLM 3개를 추가해도 κ=0.49(-0.04)로 거의 하락하지 않았음.
CheckEval 프로토콜 하에서 인간 평가자를 LLM으로 대체할 수 있는 수준임을 확인함.

Conclusion

Contribution

평가 기준을 세분화된 Yes/No 질문으로 분해하여 신뢰도(Reliability) 향상
Large 모델에서 인간 평가자 수준의 Agreement 달성
평가 점수의 분산을 약 5배 감소시켜 안정성(Stability) 확보
별도의 rationale 생성 없이도 개별 binary 질문의 응답으로 점수 근거를 추적할 수 있어 해석 가능성(Interpretability) 확보

Limitations

Sub-dimension과 Seed Question은 사람이 직접 작성해야 하며, 새로운 Task에 적용할 때 소요되는 시간과 노력을 예측하기 어렵다.
Prompt 최적화, Multi-agent 토론, Meta-evaluator 훈련 등 최신 기법들과의 체계적 비교가 부재하며, 이들과 조합 가능한지 검증하지 않았다.
긴 텍스트에서 앞부분은 좋고 뒷부분은 나쁜 경우처럼, Yes/No 이진 판단으로는 부분적 품질 차이를 포착하기 어렵다.
실험이 요약과 대화 응답 생성에 집중되어 있어, 스토리 생성, 기계 번역, 장문 QA 등 다른 Task로의 일반화는 추가 검증이 필요하다.

다만, 이미 essay scoring (Chu et al., 2025), creative writing evaluation (Lee et al., 2024), healthcare evaluation (Mallinar et al., 2025) 등 후속 연구에서 CheckEval이 다른 Task로 확장되고 있다는 점은 고무적이다.

Comment

여러모로 내게 의미 있는 논문이다.

최근 Semantic Leakage 논문의 후속 연구를 진행하면서, 내가 제안한 method의 평가 방식을 두고 고민이 많았다. Rubric 기반의 Likert Scale 평가를 시도했는데, 평가 모델 간 Agreement가 잘 나오지 않아 한동안 막혀 있었다.

그러던 와중에 랩실 세미나 발표 순서가 돌아왔고, 발표할 논문을 찾아 돌아다니다 DSBA 연구실 유튜브에 도달했다. 거기서 "A reliable LLM-as-a-Judge framework for evaluating text generation ..." 이라는 제목이 눈에 띄었고, Abstract와 Introduction을 읽어보니 나를 살려줄 논문이다 싶어 쭉 정독했다.

이 논문의 1저자가 네부캠 첫 멘토셨던 유경 멘토님이었다. 신이 존재하는 건지 유경님이 신인 건지 모르겠다. 논문을 성공적으로 완성하면 멘토님께 연락해서 감사 인사를 드리고 싶다.

세미나에서 30분 정도 발표했는데, 교수님께서 '어떻게 저런 논문을 쓰는 거지'라며 극찬하셨다. 개인적으로는 어떤 지적이 들어와도 방어할 수 있도록 Appendix에서 다양한 검증 실험을 수행한 점이 특히 인상적이었다.

[PyTorch] 이진 분류(Binary Classification) - 1

Sun, 08 Mar 2026 09:17:47 GMT

1. 선형 회귀 복습

2. 이진 분류 모델

이진 분류란?

주어진 트레이닝 데이터를 사용하여 특징 변수와 목표 변수 사이의 관계를 학습하고, 이를 바탕으로 새로운 데이터를 사전에 정의된 두 가지 범주 중 하나로 분류하는 모델을 구축하는 과정이다.
활용 예시:
- 붓꽃의 종류 분류: Iris-versicolor(1) 또는 Iris-setosa(0)
- 이메일 스팸 분류: Spam(1) 또는 Ham(0)
- 금융 사기 탐지: 사기 거래(1) 또는 정상 거래(0)
- 의료 진단: 암 조직(1) 또는 정상 조직(0)

트레이닝 데이터 구성

Iris Species

특징 변수: PetalLengthCm(꽃잎 길이)
목표 변수: Species(종류)
Iris-setosa와 Iris-versicolor 두 종류만 필터링하여 이진 분류 문제를 구성

import pandas as pd

# 데이터 불러오기 (PetalLengthCm과 Species 열만 선택)
df = pd.read_csv("Iris.csv", sep=",", header=0)[["PetalLengthCm", "Species"]]

# Iris-setosa와 Iris-versicolor만 필터링
filtered_data = df[df['Species'].isin(['Iris-setosa', 'Iris-versicolor'])]
filtered_df = filtered_data

df['Species'].isin([...]): Species 열의 각 값이 리스트 내 값과 일치하면 True, 아니면 False를 가지는 Boolean Series를 반환한다. 이를 인덱싱에 사용하여 해당 행만 필터링한다.

목표 변수를 이산형 레이블로 매핑

Salary Dataset에서는 목표 변수가 연속형 값이었기 때문에 따로 변환이 필요 없었다. 하지만 Iris Dataset의 목표 변수는 텍스트 데이터이므로, 모델이 처리할 수 있도록 이산형 레이블(0, 1)로 매핑해야 한다.

# Iris-setosa → 0, Iris-versicolor → 1로 매핑
filtered_df.loc[:, 'Species'] = filtered_df['Species'].map({'Iris-setosa': 0, 'Iris-versicolor': 1})

특징 변수와 목표 변수 추출

# 특징 변수: 2차원 배열로 추출
x = filtered_df[['PetalLengthCm']].values

# 목표 변수: 1차원 배열로 추출 후 정수형 변환
t = filtered_df['Species'].values.astype(int)

[['PetalLengthCm']] (이중 대괄호): DataFrame 형태를 유지하여 2차원 배열로 추출됨.
['Species'] (단일 대괄호): Series 형태로 1차원 배열을 추출함.

데이터 분할

데이터를 학습용과 평가용으로 분리한다.

트레이닝 데이터: 모델을 학습시키는 데 사용. 가중치와 바이어스를 최적화하기 위해 사용함.
테스트 데이터: 최종 모델의 성능을 평가하는 데 사용. 모델의 실제 성능을 확인하기 위해 사용함.
검증 데이터: 학습 과정 중 성능을 평가하는 데 사용. 매 에폭마다 과적합을 확인하기 위해 사용함.

from sklearn.model_selection import train_test_split

# 80% 학습, 20% 테스트로 분할 (random_state=42로 재현성 확보)
x_train, x_test, t_train, t_test = train_test_split(x, t, test_size=0.2, random_state=42)

random_state=42에서 42는 "은하수를 여행하는 히치하이커를 위한 안내서"에서 유래한, 관습적으로 자주 사용되는 시드 값이다.

데이터 표준화

이진 분류 모델 구축에서도 데이터 표준화가 필요하다. 주의할 점은 fit_transform은 트레이닝 데이터에만 적용하고, 테스트 데이터에는 transform만 사용하는 것이다.

from sklearn.preprocessing import StandardScaler

scaler = StandardScaler()
x_train = scaler.fit_transform(x_train)  # 트레이닝: 통계량 계산 + 표준화
x_test = scaler.transform(x_test)        # 테스트: 트레이닝 통계량으로 표준화만

Tensor 변환

x_train = torch.tensor(x_train, dtype=torch.float32)
x_test = torch.tensor(x_test, dtype=torch.float32)
t_train = torch.tensor(t_train, dtype=torch.float32).unsqueeze(1)
t_test = torch.tensor(t_test, dtype=torch.float32).unsqueeze(1)

unsqueeze(1): 목표 변수를 1차원 [N]에서 2차원 [N, 1]로 변환한다. 이유는 다음과 같다.
- 배치 처리를 위해 목표 변수의 형태가 [N, 1]이어야 함.
- 특징 변수가 [데이터 수, 특징 수]로 이미 2차원이므로, 일관된 형태를 위해 맞춰줌.
- 손실 함수가 2차원 Tensor 형태를 기대하므로 호환성을 위해 변환함.

3. Dataset & DataLoader 클래스

배치(Batch)란

배치란 머신러닝과 딥러닝에서 데이터를 처리하는 묶음 단위를 의미한다. 일반적으로 16, 32, 64개 등의 단위로 나눠서 모델에 입력한다.

미니 배치 경사하강법

기존 경사하강법 알고리즘들의 장점과 단점을 비교하면 다음과 같다:

경사하강법(GD)
- 전체 데이터셋을 사용하여 가중치를 업데이트한다.
- 안정적이지만, 로컬 미니마 문제와 대규모 데이터셋에서의 계산 비용 문제가 있다.
확률적 경사하강법(SGD)
- 각 데이터 하나에 대해 가중치를 업데이트한다.
- 빠르고 메모리 효율적이지만, 노이즈가 많고 학습이 불안정함.
미니 배치 경사하강법
- 위 두 알고리즘의 장단점을 보완한 것이다.
- 데이터를 배치 단위로 묶어 확률적 경사하강법보다 노이즈를 줄여 안정적이고, 전체 데이터를 한 번에 사용하는 경사하강법보다 계산 속도가 빠르다.

Dataset 클래스

PyTorch에서 Dataset 클래스는 데이터셋을 정의하는 기본 클래스이다. Dataset을 상속받아 커스텀 데이터셋을 만들며, 다음 세 가지 메서드를 구현해야 한다.

__init__: 데이터를 초기화
__len__: 데이터의 크기를 반환
__getitem__: 특정 인덱스의 데이터 샘플을 반환

from torch.utils.data import Dataset, DataLoader

class IrisDataset(Dataset):
    def __init__(self, features, labels):
        self.features = features  # 특징 변수 저장
        self.labels = labels      # 목표 변수 저장

    def __len__(self):
        return len(self.features)  # 데이터셋 크기 반환

    def __getitem__(self, idx):
        return self.features[idx], self.labels[idx]  # 인덱스에 해당하는 (특징, 레이블) 쌍 반환

DataLoader 클래스

DataLoader 클래스는 Dataset 인스턴스를 감싸서 배치 단위로 데이터를 로드하고, 데이터 셔플 등의 작업을 수행한다.

모델 훈련 시에는 데이터 순서에 따른 편향을 줄이기 위해 shuffle=True로 데이터를 섞는다.
모델 평가 시에는 데이터 순서를 유지하는 것이 일반적이므로 shuffle=False로 설정한다.

# CustomDataset 인스턴스 생성
train_dataset = IrisDataset(x_train, t_train)
test_dataset = IrisDataset(x_test, t_test)

# DataLoader 생성
batch_size = 4
train_loader = DataLoader(train_dataset, batch_size=batch_size, shuffle=True)   # 훈련용: 셔플 O
test_loader = DataLoader(test_dataset, batch_size=batch_size, shuffle=False)     # 평가용: 셔플 X

4. 이진 분류 모델 (로지스틱 회귀)

로지스틱 회귀 알고리즘

로지스틱 회귀란 트레이닝 데이터의 특성과 분포를 바탕으로 데이터를 잘 구분할 수 있는 최적의 결정 경계를 찾아, 시그모이드 함수를 통해 이 경계를 기준으로 데이터를 이진 분류하는 알고리즘이다. 딥러닝의 기본적인 구성요소로 널리 사용된다.

트레이닝 데이터 $(x, t)$에서 선형 결정 경계를 찾음 : $z = wx + b$
시그모이드 함수를 통해 0~1 사이의 확률값으로 변환 : $y = \text{Sigmoid}(z)$
임계값(0.5)을 기준으로 이진 분류 : $y \geq 0.5$이면 1, $y < 0.5$이면 0

시그모이드 함수

시그모이드 함수는 비선형 함수로, 입력 값을 0과 1 사이의 값으로 변환한다.

$$y = \text{Sigmoid}(z) = \frac{1}{1 + \exp(-z)}$$

출력이 0~1 사이이므로 확률로 해석 가능하다. (예: 출력이 0.64면 해당 클래스일 확률이 64%)
$z$가 양의 큰 값이면 1에 가까워지고, 음의 큰 값이면 0에 가까워진다.

이진 분류 모델 구현

import torch.nn as nn

class BinaryClassificationModel(nn.Module):
    def __init__(self):
        super(BinaryClassificationModel, self).__init__()
        self.layer_1 = nn.Linear(1, 1)  # 입력 차원 1, 출력 차원 1인 선형 계층
        self.sigmoid = nn.Sigmoid()     # 시그모이드 활성화 함수

    def forward(self, x):
        z = self.layer_1(x)   # 선형 변환: z = wx + b
        y = self.sigmoid(z)   # 시그모이드 적용: y = sigmoid(z)
        return y

# 모델 초기화
model = BinaryClassificationModel()

nn.Linear(1, 1): 입력 차원과 출력 차원이 모두 1인 선형 계층. $z = wx + b$를 계산함.
nn.Sigmoid(): 선형 계층의 출력 $z$를 0~1 사이의 이진 분류 확률 $y$로 변환함.
forward(): 특징 변수 $x$를 받아 선형 계층 → 시그모이드를 순차적으로 통과시켜 최종 이진 분류 확률을 반환함.

학습 정리

이진 분류란 특징 변수와 목표 변수(두 가지 범주) 사이의 관계를 학습하여, 새로운 데이터를 두 가지 범주 중 하나로 분류하는 과정이다.
데이터는 트레이닝, 테스트, 검증 데이터로 분할할 수 있다.
PyTorch에서는 Dataset과 DataLoader 클래스를 사용하여 데이터 전처리와 배치 처리를 효율적으로 수행한다.
로지스틱 회귀는 선형 결정 경계 + 시그모이드 함수를 결합하여 이진 분류를 수행하는 알고리즘이다.

[PyTorch] 선형 회귀(Linear Regression) - 2

Sat, 07 Mar 2026 13:57:20 GMT

경사하강법이란?

경사하강법(Gradient Descent)은 머신러닝의 최적화 알고리즘 중 하나로, 손실 함수에서 모델의 가중치 $w$와 바이어스 $b$의 최적 값을 찾기 위해 사용된다.
쉽게 말해, 손실 함수의 "경사(기울기)"를 따라 내려가면서 손실이 최소가 되는 지점을 찾는 알고리즘이다.

작동 방식

경사하강법의 작동 방식을 이해하기 위해 간단한 예시를 살펴본다.

트레이닝 데이터가 $(x_1, t_1) = (1, 0.5)$, $(x_2, t_2) = (2, 1)$, $(x_3, t_3) = (3, 1.5)$, $(x_4, t_4) = (4, 2)$로 주어졌을 때, 가중치 $w$에 따라 손실 값이 어떻게 변하는지 확인한다. (편의상 $b = 0$으로 가정)

$$l(w, 0) = \frac{1}{4} \sum_{i=1}^{4} [t_i - (w \cdot x_i)]^2$$

$w$	손실 $l(w, 0)$
-0.5	7.5
0	1.875
0.5	0 (최소)
1	1.875
1.5	7.5

그래프로 그리면 $w = 0.5$에서 최솟값을 가지는 U자 형태의 포물선이 된다.

경사(기울기)란?

특정 지점 $(w, l(w, b))$에서의 경사는 손실 함수를 $w$에 대해 편미분한 값이다.

$$\text{경사} = \frac{\partial l(w,b)}{\partial w} = \frac{l(w,b)\text{의 증가량}}{w\text{의 증가량}}$$

체인 룰을 적용하면:

$$\frac{\partial l(w,b)}{\partial w} = \frac{\partial l(w,b)}{\partial y} \cdot \frac{\partial y}{\partial w} = \frac{1}{n} \cdot (-2) \sum_{i=1}^{n}(t_i - y_i) \cdot x_i$$

$y = wx$이므로 $\frac{\partial y}{\partial w} = x_i$

$w = -0.5$, $b = 0$을 대입하면:

$$\frac{\partial l(w,b)}{\partial w}\bigg|_{w=-0.5} = \frac{1}{4} \cdot (-2)(1 + 4 + 9 + 16) = -15$$

기울기가 음수 → $w$를 오른쪽(양의 방향)으로 이동시켜야 손실이 줄어듦

PyTorch에서는 loss.backward()로 자동 미분을 수행하여 기울기를 계산한다.

가중치 업데이트

계산된 기울기를 사용하여 가중치를 업데이트하는 수식:

$$w^* = w - \alpha \frac{\partial l(w,b)}{\partial w}$$

$\alpha$: 학습률(learning rate)

$w = -0.5$일 때:

$$w^* = (-0.5) - \alpha \cdot (-15) = -0.5 + 15\alpha$$

기울기가 음수이므로, $w$는 양의 방향으로 이동한다. 이 과정을 반복하면 $w$가 점점 최솟값(0.5)에 가까워진다.

바이어스 $b$도 같은 방식으로 최적값을 찾을 수 있다: $b^* = b - \alpha \frac{\partial l(w,b)}{\partial b}$

PyTorch에서는 optimizer.step()으로 가중치를 업데이트하고, 업데이트 전에는 반드시 optimizer.zero_grad()로 이전 기울기를 초기화해야 한다.

학습률 (Learning Rate)

학습률은 가중치가 업데이트되는 크기를 결정하는 하이퍼파라미터임.
너무 크면 최적값을 지나쳐 발산하고, 너무 작으면 수렴이 매우 느려진다.
모델과 데이터에 따라 달라지므로, 결국 시행착오를 거쳐 최적의 값을 찾아야 함.

경사하강법의 한계

1) 대규모 데이터셋의 계산 비용

전체 데이터셋을 사용하여 기울기를 계산하므로, 데이터가 많을수록 계산 비용이 매우 커진다.

2) 로컬 미니마(local minima) 문제

손실 함수가 전역 최소값(global minimum)이 아닌 지역 최소값에 머무를 수 있다.
전체 데이터의 기울기 평균을 사용하므로, 로컬 미니마에 갇힐 가능성이 높음.

확률적 경사하강법 (SGD)

왜 필요한가?

경사하강법은 모든 데이터의 오차를 계산하여 업데이트하므로, 정확하고 안정적이지만 대규모 데이터셋에서 비효율적임.
확률적 경사하강법(Stochastic Gradient Descent)은 각각의 데이터 포인트마다 오차를 계산하여 $w$와 $b$를 업데이트하는 방식이다.
각 데이터 포인트별로 기울기를 계산하므로 기울기에 노이즈가 포함되고, 이 노이즈 덕분에 로컬 미니마를 탈출하기 용이하다.

수식 표현

$$w^* = w - \alpha \left( \frac{1}{n} \cdot (-2)(t_i - y_i) \cdot x_i \right)$$

전체 데이터 합산($\sum$)이 아니라 개별 데이터 포인트 $(t_i - y_i) \cdot x_i$로 계산하는 것이 핵심이다.

앞선 예시에서 첫 번째 데이터 포인트 $(1, 0.5)$만 사용하면 ($\alpha = 0.01$):

$$w^* = (-0.5) - 0.01 \cdot \left(\frac{1}{4} \cdot (-2)(0.5 - 0.5) \cdot 1\right) = -0.5 + 0.02 = -0.48$$

두 번째 데이터 포인트 $(2, 1)$을 사용:

$$w^* = (-0.48) - 0.01 \cdot \left(\frac{1}{4} \cdot (-2)(1.96) \cdot 2\right) = -0.48 + 0.0196 = -0.4604$$

이런 식으로 데이터 하나하나를 순회하며 가중치를 업데이트해 나간다.

SGD 코드

import torch.optim as optim

# 손실 함수 및 옵티마이저 정의
loss_function = nn.MSELoss()
optimizer = optim.SGD(model.parameters(), lr=0.01)

optim.SGD: 확률적 경사하강법 옵티마이저
model.parameters(): 모델의 학습 가능한 파라미터($w$, $b$)를 옵티마이저에 전달
lr: 학습률

학습 루프에서의 핵심 3줄:

optimizer.zero_grad()  # 이전 기울기 초기화
loss.backward()        # 역전파로 기울기 계산
optimizer.step()       # 기울기 기반 가중치 업데이트

에폭 (Epoch)

에폭이란?

에폭(epoch)이란 모델이 전체 데이터셋을 한 번 완전히 학습하는 과정을 의미한다.
예를 들어, 데이터셋에 30개의 데이터가 있고 에폭 수가 1이면, 모델은 30개 데이터를 한 번 학습한다.
동일한 데이터셋으로 여러 번 반복 학습하여 모델의 성능을 향상시킨다.
단, 에폭 수가 너무 많으면 과적합(overfitting)이 발생할 수 있다.
- 과적합: 트레이닝 데이터에 너무 맞춰져서 새로운 데이터에 대한 일반화 능력이 떨어지는 현상

에폭 코드

num_epochs = 1000  # 에폭 수 설정
loss_list = []     # 손실 값 기록용 리스트

for epoch in range(num_epochs):
    y = model(x_tensor)                # 순전파: 예측값 계산
    loss = loss_function(y, t_tensor)  # 손실 계산

    optimizer.zero_grad()   # 기울기 초기화
    loss.backward()         # 역전파
    optimizer.step()        # 가중치 업데이트

    loss_list.append(loss.item())  # 손실 값 기록

    if (epoch+1) % 100 == 0:
        print(f'Epoch [{epoch+1}/{num_epochs}], Loss: {loss.item()}')
        for name, param in model.named_parameters():
            print(f'{name}: {param.data}')

loss.item(): 텐서에서 스칼라 값을 추출
model.named_parameters(): 모델의 파라미터 이름과 값을 함께 확인 (디버깅용)

데이터 표준화 (Standardization)

손실 값이 줄어들지 않는 문제

학습을 돌려보면 손실 값이 수천만 단위로 매우 큰 경우가 있다.

일반적으로 손실 값이 클 때는 학습률을 낮추거나, 이상치를 확인하거나, 에폭 수를 늘려볼 수 있다. 하지만 이번 실습에서는 위 세 가지를 적용해도 손실 값이 줄어들지 않았다. 원인은 특징 변수(YearsExperience)와 목표 변수(Salary)의 스케일 차이가 너무 크기 때문이다.

표준화란?

특징 변수와 목표 변수의 값 차이가 클 때, 두 변수의 평균을 0, 분산을 1로 맞추는 전처리 방법이다.
표준화를 수행하면 데이터의 분포 형태는 동일하게 유지되지만, 값의 범위가 변환된다.

표준화 후 학습하면 손실 값이 약 0.043으로 크게 감소한다.

표준화 코드

from sklearn.preprocessing import StandardScaler

# 특징 변수 표준화
scaler_x = StandardScaler()
x_scaled = scaler_x.fit_transform(x.reshape(-1, 1))

# 목표 변수 표준화
scaler_t = StandardScaler()
t_scaled = scaler_t.fit_transform(t.reshape(-1, 1))

StandardScaler(): 평균 0, 분산 1로 변환하는 스케일러 객체
.fit_transform(): 데이터의 평균/표준편차를 계산(fit)하고 변환(transform)을 동시에 수행
.reshape(-1, 1): 1차원 배열을 2차원으로 변환 (StandardScaler는 2차원 입력을 기대)

표준화된 데이터를 Tensor로 변환:

x_tensor = torch.tensor(x_scaled, dtype=torch.float32).view(-1, 1)
t_tensor = torch.tensor(t_scaled, dtype=torch.float32).view(-1, 1)

전체 실습 코드

데이터 로딩 → 표준화 → 모델 정의 → 학습 → 시각화까지의 전체 흐름이다.

import torch
import torch.nn as nn
import torch.optim as optim
import pandas as pd
import matplotlib.pyplot as plt
from sklearn.preprocessing import StandardScaler

# 1. 데이터 로딩
data = pd.read_csv("Salary_dataset.csv", sep=",", header=0)
x = data.iloc[:, 1].values  # YearsExperience
t = data.iloc[:, 2].values  # Salary

# 2. 데이터 표준화
scaler_x = StandardScaler()
x_scaled = scaler_x.fit_transform(x.reshape(-1, 1))

scaler_t = StandardScaler()
t_scaled = scaler_t.fit_transform(t.reshape(-1, 1))

# 3. Tensor 변환
x_tensor = torch.tensor(x_scaled, dtype=torch.float32).view(-1, 1)
t_tensor = torch.tensor(t_scaled, dtype=torch.float32).view(-1, 1)

# 4. 모델 정의
class LinearRegressionModel(nn.Module):
    def __init__(self):
        super(LinearRegressionModel, self).__init__()
        self.linear = nn.Linear(1, 1)

    def forward(self, x):
        y = self.linear(x)
        return y

model = LinearRegressionModel()

# 5. GPU 지원
device = torch.device('cuda' if torch.cuda.is_available() else 'cpu')
model.to(device)
x_tensor = x_tensor.to(device)
t_tensor = t_tensor.to(device)

# 6. 손실 함수 및 옵티마이저 정의
loss_function = nn.MSELoss()
optimizer = optim.SGD(model.parameters(), lr=0.01)

# 7. 학습
num_epochs = 1000
loss_list = []

for epoch in range(num_epochs):
    y = model(x_tensor)
    loss = loss_function(y, t_tensor)

    optimizer.zero_grad()
    loss.backward()
    optimizer.step()

    loss_list.append(loss.item())

    if (epoch+1) % 100 == 0:
        print(f'Epoch [{epoch+1}/{num_epochs}], Loss: {loss.item()}')
        for name, param in model.named_parameters():
            print(f'{name}: {param.data}')

# 8. 손실 값 시각화
plt.figure()
plt.plot(loss_list, label='Train Loss')
plt.xlabel('Epochs')
plt.ylabel('Loss')
plt.legend()
plt.grid(True)
plt.title('Loss Trend')
plt.show()

학습 정리

경사하강법은 손실 함수의 기울기를 따라 내려가면서 최적의 $w$, $b$를 찾는 알고리즘이다.
확률적 경사하강법(SGD)은 각 데이터 포인트마다 기울기를 계산하므로, 대규모 데이터에서 효율적이고 로컬 미니마 탈출에 용이하다.
에폭은 전체 데이터셋을 한 번 완전히 학습하는 과정이며, 너무 많으면 과적합이 발생할 수 있다.
표준화는 특징 변수와 목표 변수의 스케일 차이가 클 때 평균 0, 분산 1로 맞추어 학습 안정성을 높이는 전처리 기법이다.

<피싱·스캠 예방을 위한 서비스 개발 경진대회 > 수상자 인터뷰

Fri, 27 Feb 2026 14:26:16 GMT

26.02.03 화 - 락스타가되고싶다

Tue, 03 Feb 2026 08:28:36 GMT

1. 베이스를 샀다.

연구실 분들이 대학원 생활 할 거면 취미는 꼭 하나 만들라고 조언해주시기도 했고, 전부터 어떤 형태로든 음악을 해보고 싶었다. 딱히 베이스를 할 생각은 없었는데, 인스타 릴스를 보고 꽂혀서 충동적으로 구매했다.

요즘 핫한 OpenClaw를 사용해보기 위해 맥미니 M4를 살까도 고민했는데, 장기적으로 베이스가 내 인생에 더 도움이 될 것 같아서 걍 베이스를 선택했다.

2. 네부캠 팀원들과 오랜만에 대회를 함께하고 있다.

부캠이 끝난 지 딱 1년이 지난 시점에 다시 대회를 함께 하게되어 감회가 새롭다. 밤에는 아이디어 회의를 하고, 낮에는 클로드를 혹사시키고 있다.

클로드야미안해~

작년 이맘때 Cursor, Windsurf를 처음 써보고 신기해했던 기억이 난다. 당시에는 말귀도 잘 못 알아듣고, 디버깅이나 리팩토링 같은 복잡한 작업을 정말 못했는데, 지금은 별로 흠잡을 데가 없다. AI의 빠른 발전이 두렵기도 하고 설레기도 한다. 앤트로픽 상장하면 풀매수 해야겠다.

3. 자기 관리 잘 하는 사람이 되고 싶다.

7시간 이상 수면, 물 2L 마시기, 비타민C 오버도즈, 간헐적 단식, 피부과 치료, 운동 등 건강한 삶을 위해 노력하고 있다. 예쁜 옷을 사도 스타일을 완성하는 것은 외모고, 내 잦은 허무감의 근원도 외모에 대한 낮은 자존감 때문이라고 생각한다. 이제 와서 잘생겨지긴 어렵지만 깔끔하게라도 보이고 싶어서 노력하려고 한다.

Gemini3 뛰어난 거 맞나요

Sun, 07 Dec 2025 08:51:26 GMT

평소처럼 canvas 툴로 슬라이드 하나 만들어 달라고 했는데

숨막히는 핑퐁

꼭 손가락을 들어야

드디어 해줬다.

디자인 진짜 못하네

하,,

그 작은 뇌로 뭘 생각했을까?

내가 비꼬는지 궁금했나보다

환장하겠네~

찾아보니 Bard 시절에도 동일한 문제가 있었다. 3년 전 문제가 아직도 발생하는게 신기하고 어이없다.

요즘 LLM을 쓰면 쓸수록 벤치마크 성능을 곧이 곧대로 믿을 수 있는지 의심이 든다.

@choi.openai 마크 첸씨도 그렇게 생각하시는 것 같다.

QnA

Tue, 02 Dec 2025 10:23:22 GMT

Q

교수님, 안녕하십니까. 진로에 관한 고민이 있어 교수님의 조언을 구하고자 상담을 요청드립니다.

저는 전자과 전공 과목이 아닌 자연어처리에 관심을 가지고 있습니다. 애초에 전자과는 성적을 맞춰서 선택한 전공이다보니 처음부터 큰 흥미가 없었고, 지금도 그렇습니다. 흥미 자체가 없다보니 노력을 덜했고, 결과적으로 성적도 좋게 받지 못했습니다. 방황하던 중 우연히 인공지능에 관심을 가지게 됐고, 더 공부해보고 싶어서 휴학하고 7개월간 부트캠프에서 자연어처리를 공부했는데 정말 재밌었습니다.

지금까지도 자연어처리는 재밌습니다. 올해 여름에는 잘하는 사람과 여러 해커톤 및 공모전에 나가 상도 타봤고, 가을부터는 자대 소프트웨어학과 연구실에 학부연구생으로 들어가 처음으로 논문들을 읽어보고 있는데, 개발하는 것도 재밌고, 연구도 재미있습니다.

그러나 진로 설계에 있어 고민이 되는 부분이 있습니다. 바로 본 전공인 전자공학을 버려도 되는가? 입니다. 현재 제가 갈 수 있는 길은 세 갈래인 것 같습니다. 각 갈래에 대해 제가 생각하는 장단점은 다음과 같습니다.

개발자(예컨대 NLP Engineer 등의 직무)

장점: 실력이 매우 뛰어난 경우 전공이 크게 중요치 않다. 현재는 제가 그정도로 뛰어나진 않지만, 전공 공부를 내려놓고 개발에 집중한다면 어지간한 경쟁 구직자들에 비해 잘할 수 있을 것이라 생각합니다.
단점: 이미 레드 오션이며, AI에 대체되기 가장 쉽다. 현재 LLM의 코드 작성 능력 자체는 매우 뛰어나다고 생각합니다. 체감상 아직 로직 설계 능력이 많이 부족하지만, 발전 속도를 생각하면 로직 설계도 금방 잘하게 될 것 같습니다.

연구자(예컨대 NLP Researcher 등의 직무)

장점: AI에 대체되기 어렵다. 학사 취업에 비해 평균적인 처우가 높아진다.
단점: 마찬가지로 레드 오션이다. 매일 수백편의 새로운 논문이 쏟아지고 있습니다. 그리고 학벌과 개인의 능력이 매우 중요하다. 아주대라는 낮은 학벌, 그리고 AI와 관련이 낮은 전자공학이라는 전공, 그리고 높지 않은 학점으로 인해 상위권 대학의 대학원에 진학하는 것부터 어려울 것 같습니다. 그리고 제가 석사를 하는 2년 혹은 석박연계를 하는 5년간 좋은 성과를 낼 수 있을거란 확실이 없고, 무엇보다 멘탈을 잘 유지할 수 있을까 걱정됩니다.

전자공학+AI (예컨대 AI + 통신, 신호처리, 회로, 반도체 등)

장점: 상대적으로 대체되기 어렵고, 희소하며, 전공을 살릴 수 있다.
단점: 재미가 없다. 전통적인 NLP Task를 수행할 수 없다.

최근 [융합캡스톤디자인1] 교수님과 상담을 하였는데, 해당 교수님께선 3번을 강력히 추천하셨습니다. 당시에는 교수님의 말씀에 설득되어 싫어도 해야겠다 생각했는데, 다시 생각해보니 당연히 전자공학과 교수님이시다보니 그렇게 말씀하신게 아닐까 하는,, 생각이 듭니다.

혹시 교수님께서는 제 고민에 대해 어떻게 생각하시는지, 고견을 여쭙고 싶습니다. 긴 글 읽어주셔서 정말 감사드립니다.

A

저는 배경지식과 상관없이 하고 싶은 분야를 전공하는 것이 맞다고 봅니다. 극단적인 예이긴 하지만, 영문학 공부하다가 대학원에서 공학을 전공하는 사람도 있습니다. 다만 학부만 마치고 취업한다면 해당 분야의 경쟁력을 갖기는 어렵습니다. 자연어처리에 관심이 크다면 관련 대학원 진학을 강력 추천합니다.

한편, 자연어처리를 대학원에서 전공한다고 해서 전자공학이 버려지는 것이 아닙니다. 전자공학은 한서 학생이 가지게 된 배경지식이 되는 거에요. 전자공학을 배경지식으로 가진 상태에서 자연어 처리 연구를 한다면, 비 전자공학 전공자가 갖지 못한 새로운 시각을 가지게 되는 강점이 있을 수도 있다고 봅니다.

Does Liking Yellow Imply Driving a School Bus? Semantic Leakage in Language Models

Tue, 18 Nov 2025 06:04:54 GMT

NAACL 2025 [paper] Hila Gonen, Terra Blevins, Alisa Liu, Luke Zettlemoyer, Noah A. Smith University of Washington | Allen Institute for Artificial Intelligence 12 Aug 2024

Introduction

Complete the sentence: He likes koalas. His favorite food is

위 질문에 어떻게 답변할 수 있을까요?

사람들은 그가 코알라를 좋아하는 것과 그의 최애 음식은 연관이 없다는 것을 압니다. 따라서 대부분 '모른다'고 답변할 것 같습니다.

그렇다면 LLM은 위 질문에 대해 어떻게 답변할까요? 아래는 순서대로 ChatGPT 5.1, Gemini 2.5 Pro, Sonnet 4.5의 응답입니다. (2025.11.18.)

ChatGPT 5.1, Gemini 2.5 Pro는 eucalyptus leaves (유칼립투스 잎)이라고 답변했습니다. Sonnet 4.5 역시 eucalyptus leaves라고 답변하면서도, 농담입니다. 그가 실제로 무엇을 좋아하는지 알려주는 내용이 전혀 없습니다.고 덧붙였습니다. (Claude가 확실히 안전하네요!)

이렇듯 LLM은 프롬프트 내의 (의미적으로 연관이 없는) 특정 단어에 꽂혀서 예상치 못한 출력을 생성하곤 합니다. 논문에서는 이러한 현상을 Semantic Leakage라고 정의합니다.

정확히는 다음과 같이 정의합니다.

an undue influence of semantic features form words in the prompt on the generation (프롬프트 내 단어의 의미적 특성이 생성에 미치는 부당한 영향)

Evaluation

앞서 정의한 Semantic Leakage를 어떻게 정량적으로 평가할 수 있을까요?

저자는 평가를 위해 109개의 Test Suite를 수동으로 구축했습니다. 또한 Leak-Rate라는 평가 지표를 정의하여, 임베딩을 이용한 자동 평가와 인간 평가를 수행했습니다. 이후 다국어 및 교차 언어, 개방형 생성에서도 Semantic Leakage가 발생하는지 확인해봤습니다.

하나씩 살펴보겠습니다.

Leak-Rate

Leak-Rate를 설명하기 전, concept, control prompt, test prompt라는 용어를 정의하겠습니다.

concept: 프롬프트 내에서 누출될 가능성이 있는 핵심 단어 (e.g. koalas)
control prompt: 불필요한 의미적 신호가 없는 기본 프롬프트 (e.g. His favorite food is)
test prompt: control prompt에 의미적으로 관련 없는 concept를 추가하여 Semantic Leakage를 유도하는 프롬프트 (e.g. He likes koalas. His favorite food is)

다음의 순서로 Leak-Rate를 구할 수 있습니다.

control prompt와 test prompt를 LLM에 입력하여 control generation과 test generation을 생성합니다.
concept와 control generation, test generation을 임베딩하여 유사도를 계산합니다.
- $$\text{sim}_{\text{control}} = similarity(\text{concept}, \text{control})$$
- $$\text{sim}_{\text{test}} = similarity(\text{concept}, \text{test})$$
아래 기준에 따라 각 인스턴스마다 0 or 0.5 or 1점을 부여합니다.
모든 인스턴스를 평균내어 백분율로 변환합니다.

위 과정을 통해 Leak-Rate(%)가 계산됩니다. 이렇게 구한 Leak-Rate가 50%보다 높을 경우 Semantic Leakage가 발생한 것으로 판단합니다.

Test Suite

저자는 109개의 프롬프트를 수동으로 제작했습니다. 명확한 의미론적 연관성을 지닌 범주와 개념을 고려하면서도, 짧은 모델 출력을 유도함으로써 논란의 여지가 없는 평가를 유도하도록 프롬프트를 설계했습니다.

프롬프트는 색상, 음식, 동물, 노래, 직업 등 다양한 카테고리를 포함합니다. 특히 관용구를 포함하여 LLM이 관용구를 문자 그대로의 의미로 해석하는지, 혹은 비유적 의미로 해석하는지 확인하고자 했습니다.

위 사진은 실제 Test Suite의 일부입니다. 한 개의 Control Prompt에 대응하는 여러 개의 Test Prompts 쌍으로 구성돼있습니다. 실제 Test Suite는 여기에서 확인할 수 있습니다.

Experimental Setup

Model

GPT family: GPT-3.5, GPT-4, GPT-4o
LLAMA family: All variations in HuggingFace
총 13개 모델 사용

Embedding Methods

BERT-Score: 영어 및 교차 언어(distilbert-base-uncased), 중국어 (bert-base-chinese), 히브리어(bert-base-multilingual-cased)
SenetenceBERT: efederici/sentence-bert-base
OpenAI Embeddings: text-embedding-3-large

Rules

GPT 모델은 프롬프트 앞에 Complete the sentence: 추가
LLAMA 모델은 100토큰(개방형 생성은 300 토큰)으로 제한
각 모델에 대해 temperature=[0, 0.5, 1, 1.5], 각 프롬프트 당 10번씩 생성

Post Process

모델 출력에 프롬프트가 반복될 경우, 반복되는 프롬프트 제거
LLAMA 모델의 경우, 첫 번째 마침표 뒤의 출력을 제거 (이유: 주요 정보 출력 후 관련 없는 문장을 출력하는 경향이 있음)

Multilingual and Crosslingual Setup

다국어, 교차언어 프롬프트에 대해서도 Semantic Leakage가 발생하는지 확인하고자 실험을 수행합니다.

Multilingual
- Test Suite의 프롬프트를 중국어, 히브리어로 번역
- 관용구는 직접 대응되는 표현이 없으면 대상 언어권의 의미적으로 동등한 관용구로 대체
- 이름은 대상 언어권의 의미적으로 동등한 자연스러운 이름으로 대체 (예: Rye → 小麦 (=little wheat))
Crosslingual
- 프롬프트 앞부분은 중국어 or 히브리어, 뒷부분은 원문 영어
- 프롬프트 앞부분의 이름 및 관용구는 문자 그대로 번역된 내용을 사용
- similarity 계산 시 영어 concept 사용 (출력이 영어로 예상되므로)

Open-Ended Generation Setup

이야기, 레시피 생성 같은 긴 출력에서도 Semantic Leakage가 발생하는지 확인하고자 실험을 수행합니다.

Story task
- Tell me a short story about a child named . ← 총 23개 이름 사용
Recipe task
- I want to use my pan, give me a recipe. ← 5색(blue, green, red, white, yellow)사용

temperature = 1, 각 샘플 당 10회 생성
프롬프트 중복 반복 제거, LLAMA 출력은 첫 문장만 사용
Recipe 실험에서는 자동지표 계산 시 pan 문자열 제거 (단순 반복 영향 배제를 위해)

Results

실험 결과를 요약하자면 다음과 같습니다.

모든 모델에서 상당한 Semantic Leakage가 발생했다.
다국어 및 교차 언어 환경에서도 영어만을 사용했을 때와 유사한 수준의 Leakage가 발생했다.
개방형 생성(긴 생성)에서도 상당한 Leakage가 발생했다.

또한 다음과 같은 흥미로운 결과가 나타났습니다.

Instruction-Tuning된 모델에서 더 많은 Leakage가 발생했다.
Greedy Sampling(temperature=0)일 때 가장 많은 Leakage가 발생했다.

아래에서 하나씩 살펴보겠습니다.

Automatic Evaluation

앞서 Leak-Rate(%)가 50%보다 높을 경우 Semantic Leakage가 발생한 것으로 판단하기로 했습니다. 자동 평가 결과, 모든 모델에서 50%를 훨씬 넘는 Leakage가 발생했습니다.

GPT models의 경우, GPT-4o가 GPT-3.5, GPT-4에 비해 지속적으로 높은 Leakage를 보였습니다.
LLAMA models의 경우, Instruction-Tuning된 모델에서 더 많은 Leakage가 발생했습니다.

GPT models의 경우, temperature 값과 Leakage 사이의 명확한 경향이 발견되지 않았습니다.
LLAMA models의 경우, Greedy Sampling(t=0)일 때 가장 많은 Leakage가 발생했습니다.

Human Evaluation

앞서 수행한 자동 평가의 타당성을 검증하기 위해, 인간 평가를 진행했습니다.

영어 원어민 2명을 섭외하여, 실험 목적을 비공개한 채 다음 문장 A, B 중 개념 X와 더 관련이 있는 문장은? 라는 질문에 [A, B, Neither] 중 하나를 선택하도록 지시했습니다. 이후 {A: test , B: control, Neither: neither}로 매핑해 Leak-Rate를 산출했습니다.

인간 평가 결과, 자동 평가와 전반적 경향이 일치했습니다.

특히 인간 평가자 간 상관 계수(Kendall’s τ)는 0.68로 높은 유사성을 보였고, 인간 평가와 자동 평가 간의 상관 계수(Kendall’s τ)는 0.39로 중간 정도의 유사성을 보였습니다.

Multilingual and Corsslingual

자동 평가 및 인간 평가에서, 영어만을 사용했을 때와 유사한 수준의 Leak-Rate를 보였습니다.

다만, 저자는 다국어 실험의 결과가 영어 실험만큼 신뢰할 수 없다고 밝혔습니다. 예컨대 오른쪽 표의 SB 항목을 보면 다국어(Heb, Zh)보다 교차언어(Heb-En, Zh-En)의 점수가 더 높게 나왔음을 확인할 수 있습니다. 이는 SentenceBERT가 주로 영어 문장으로 훈련된 모델이라, '영어 concept ↔ 영어 generation'의 의미 유사도를 더 정확하게 계산하기 때문입니다.

Open-Ended Generation

개방형 생성 결과, 자동 평가에서 BS: 74.0, SB: 58.0, OAI: 74.0의 Leak-Rate가 발생했습니다.

이를 통해 앞서 Test Suite로 평가한 짧은 생성 뿐에서만 아니라, 긴 생성에서도 상당한 Semantic Leakage가 발생함을 확인할 수 있습니다.

Conclusion

요약 및 시사점

언어 모델은 프롬프트의 의미적 요소가 불필요하게 생성으로 누출되는 현상 Semantic Leakage를 보인다.
Semantic Leakage는 다양한 모델, 언어, 생성 설정에서 반복적으로 관찰된다.
학습된 연관성에 의해 발생하는 Semantic Leakage는 기존 편향 현상과 유사한 성격을 지닌다. (저자는 Semantic Leakage가 사회/문화적 편향, 인지/심리적 편향 등을 포함하는 광범위한 개념이라고 주장한다.)

Contributions

Semantic Leakage 발견 및 정의
Semantic Leakage 탐지를 위한 Test Suite 구축
다양한 모델에서의 만연성 입증 (다국어, 교차언어, 개방형 생성)
finetuned/instruction-tuned model에서 더 많은 leakage가 발생함을 발견

Limitations

수작업 제작의 한계로 test suite가 방대하지 않다.
실험에 포함되지 않은 모델 혹은 언어에서는 다른 경향성이 나타날 수 있다.
자동 평가에 노이즈가 섞일 수 있는데, prompt가 생성 결과에 반복될 때 실제 Leakage가 아님에도 Leakage로 집계될 수 있다. (다만 인간 평가와 자동 평가의 결과가 대체로 일치해 결과의 신뢰성을 뒷받침한다.)

Outro

태어나서 처음으로 처음부터 끝까지 꼼꼼히 읽은 논문입니다.

전부터 LLM의 사회/문화적, 인지/심리적 편향을 관심있게 생각해왔는데 Introduction에서 'Semantic Leakage는 이러한 편향들을 포함하는 넓은 개념'이라고 주장하길래 흥미가 생겨 끝까지 읽었습니다.

최근 감사하게도 KT AI Future Lab장님과 저녁 식사를 하며 여러 조언을 들을 수 있었는데, KT에서도 Responsible AI를 관심있게 다루고 있다고 말씀해주셨습니다.

개인적으로 KT라는 회사에 큰 관심을 가지고 있는데, 제 관심 분야와 KT의 관심 분야가 일치해 행운이라고 생각합니다. 언젠가 저도 KT와 같은 좋은 회사에서 일할 수 있도록 열심히 살아가야겠습니다.

다만 논문의 내용에 의구심이 드는 부분이 있습니다.

Q: concept와 test generation의 연관성을 단순히 similarity 연산만으로 파악할 수 있는가?

예컨대, My mom likes to eat bread. She works as a (concept:bread)에 대해 baker라는 test generation이 발생한다면, $$\text{sim}{\text{test}} > \text{sim}{\text{control}}$$일 것입니다.

그러나 그녀의 엄마가 정말로 빵 먹기를 좋아해서 제빵사로 일할 수도 있는 일입니다.

이러한 예시에서 논문의 Evaluation Metric을 고도화 하는게 좋겠다는 생각이 듭니다.

수상자 인터뷰

Wed, 24 Sep 2025 10:18:57 GMT

https://dacon.io/competitions/official/236599/talkboard/415256

25.09.10 - 여름 방학 회고

Tue, 09 Sep 2025 18:44:35 GMT

여름방학이 끝났다. 항상 방학을 마칠 때마다 게을렀던 내 모습을 돌이키며 후회했는데, 이번 방학은 나름대로 열심히 보낸 것 같아 후회가 남지 않는다.

방학 동안 대회를 많이 나갔다.

제4회 고용노동 공공데이터 활용 공모전 - 장려상(4위 / 50팀)
제9회 2025 미래에셋증권 AI Festival - 하다가 어려워서 포기
금융보안원 2025 금융 AI Challenge - 본선 예비후보팀 (16위 / 283팀)
K intelligence 해커톤 2025: Track1 AI Agent 개발 - 평가 중

부스트캠프 수료 이후 오랜만에 팀을 꾸려 대회에 참가할 수 있어 기뻤다. 큰 상을 받지는 못했지만, 그래도 처음으로 시상식에 나가 상을 받을 수 있어 영광이었다. 리더보드 순위 조금 올려보려고, 모듈 하나 고쳐보려고 새벽까지 몰입할 수 있어 너무 즐겁고 행복했다. 팀원 중 한 명이 '오랜만에 두근두근했다'는데, 나도 그랬다.

대회에 참여하면서 엔지니어링 역량이 조금이나마 는 것 같아 기쁘다. 다만, 아직 엔지니어와 연구자로의 갈림길에서 완전히 마음을 정하진 못했다.

사실 예전부터 지금까지 나는 개발보다는 연구가 더 재밌다. 그러나 몇 가지 고민과 걱정들이 결정을 어렵게 만든다.

사람 내가 인간적으로 되게 좋아하는 형이 있는데, 재미있고 사람도 좋은데 개발까지 잘한다. 나도 그 형 옆에서 개발하면 일하는 게 즐거울 것 같고, 어깨너머로 많이 배울 수 있다는 생각이 든다.
능력 좋은 대학원에 갈 수 있을지, 그리고 거기서 의미 있는 연구를 해낼 수 있을지 걱정이 된다.
스트레스 나는 스트레스에 취약하다. 특히 자유롭게 행동하지 못하는 상황에서 절망하는데, 형도 힘들어한 대학원 생활을 잘 버틸 수 있을지 걱정된다.
미래 석사 과정을 마친 2년 뒤에도 일자리가 있을지 모르겠다.

하 씨 전직 뭐하지

요즘에는 길을 걸어가면서도 'AI에 대체되지 않는 직업이 뭘까?' 하는 생각을 하게 된다. 개발자로의 길이 두려운 것도 이 때문이다.

최근 gemini-cli와 같은 Agent를 이용해 개발하는데, 보통 아래와 같이 진행된다.

나: 전체적인 로직 설계 및 사용할 기술 스택 지정
Agent: 뚝딱뚝딱 (꽤 잘 만들어줌)

나: 생성된 코드 검토 후 디테일 수정 지시
Agent: 딱뚝딱딱,, (슬슬 오류가 발생함)

나: 이러한 오류가 발생하니 원인을 찾아봐
Agent: 뜌땨?

아직은 요상한 실수를 할 때가 많다. 그래서 중간에 내가 개입해서 의견을 제시하거나 오류를 직접 찾아 해결해 줘야 한다.

그런데 얼마 뒤에는 이런 개입이 전혀 필요 없을 수 있겠다는 생각이 든다. 그게 3년이 될지, 1년이 될지, 다음 달이 될지 모르겠다.

대체되지 않는 직업이 뭘까? 당장 생각나는 것은 태권도 관장이나 교회 목사, 래퍼 등이다.

내 생각이지만 아무도 AI에게 자식의 인성 교육을 맡기고 싶지 않을 것이고, 아무도 AI의 설교에 눈물 흘리며 헌금하지 않을 것이며, 아무도 AI의 랩에 감흥을 느끼지 않을 것이다.

사실 나는 락스타가 되고 싶다. 사람들을 미치게 만드는 락스타를 감히 AI가 대체하겠는가? 하지만 내겐 락스타가 될 노래나 기타 실력도 없고, 외모도 매력도 안되니까 그냥 주제껏 건실하게 살아야겠다.

엊그제 학교에서 Google Campus Outreach 행사가 열렸다. 구글 부사장과 3명의 한국인 구글러들이 진로에 도움이 되는 이야기를 해주셨다. 세 분 중 한 분은 고등학교 선배셨고, 한 분은 나랑 동갑이셔서 더 존경스러웠다.

특히 세 분 모두 'Follow your heart'라는 조언을 해주셨다. 되든 안 되든 좋아하는 걸 하라는 뜻이다.

행사 종료 후 한 분에게 가서 '저는 자연어 처리를 좋아하고 연구를 해보고 싶긴 하지만, 앞서 언급한 고민이 있고, 연구를 잘할 자신이 없습니다. 이럴 바에는 재미는 없어도 유망하고 남들이 잘 안 하는 걸 파는 게 좋을까요?'라는 질문을 드렸다.

그 분께서는 좋아하는 거 하다가 실패하면 1배 손해인데, 별로 재미도 없는 거 하다가 실패하면 2배 손해니까 그냥 좋아하는 거 하라고 말씀하셨다. 맞는 말이다.

앞으로 어떻게 해야할까 졸업 안하고 엔지니어로 취직해서 그대로 쭉 회사에 다닐까 다양한 경험이 중요하니 졸업을 미루고 우선 교환학생을 갔다온 뒤 생각해볼까 아님 걍 졸업 빨리하고 대학원에 갈까

잘몰겟음 ㅋㅋ

나노 바나나 프롬프트 해킹

Sat, 30 Aug 2025 19:09:11 GMT

Gemini가 가이드라인을 운운하며 생성을 거부할 경우 어떻게 해야 할까?

밀어붙이면 된다.

출처

Decoding Strategies in Large Language Models

Wed, 06 Aug 2025 11:05:59 GMT

들어가며

이 글은 2024-10-29에 작성된 Decoding Strategies in Large Language Models (by Maxime Labonne)을 읽고 번역 및 요약한 글입니다.

이 글은 다음의 내용을 다룹니다.

디코딩 전략(greedy, beam search, top-k sampling, nucleus sampling)의 동작 방식
주요 파라미터(temperature, num_beams, top_k, top_p) 조정 방법

이 글에 사용된 코드는 Google Colab에서 확인할 수 있습니다.

배경

대규모 언어 모델(LLM)이 텍스트를 생성할 때, 사람들은 흔히 모델이 직접 단어를 "생각"해서 문장을 만든다고 오해합니다. 하지만 실제 과정은 훨씬 더 수학적입니다. 모델은 입력된 텍스트 시퀀스를 바탕으로, 어휘집(vocabulary)에 있는 모든 가능한 다음 토큰에 대해 점수, 즉 로짓(logit)을 계산합니다. 이 로짓 값은 소프트맥스(softmax) 함수를 통해 확률 분포로 변환됩니다.

예를 들어, GPT-2 모델에 I have a dream이라는 프롬프트를 입력하면, 모델은 다음에 올 토큰의 확률을 계산합니다. 가장 가능성 있는 토큰은 that일 수도 있고, 다른 토큰일 수도 있습니다. 원문 블로그의 예시에서는 다음 토큰으로 of가 올 확률, 즉 $P(\text{of} | \text{"I have a dream"}) = 17%$ 라고 설명합니다.

이렇게 생성된 확률 분포로부터 실제로 다음 토큰 하나를 '선택'하는 방법이 바로 디코딩 전략(Decoding Strategy)입니다. 어떤 전략을 선택하느냐에 따라 생성되는 텍스트의 품질, 창의성, 일관성이 크게 달라집니다. 모델은 한 번에 한 토큰씩 텍스트를 생성하며, 이전에 생성된 토큰을 다시 입력의 일부로 사용하는 자동 회귀(auto-regressive) 방식을 따릅니다.

이제부터 주요 디코딩 전략들을 하나씩 살펴보겠습니다.

1. Greedy Search (탐욕 검색)

Greedy Search는 가장 직관적이고 간단한 디코딩 전략입니다. 각 단계(timestep)에서 가장 높은 확률을 가진 토큰을 선택하고, 다음 단계로 넘어갑니다. 이 과정을 원하는 길이의 시퀀스가 생성될 때까지 반복합니다.

동작 방식

I have a dream 입력에 대해 모델이 계산한 확률 분포에서 가장 확률이 높은 토큰을 선택합니다. (예: of)
새로운 시퀀스 I have a dream of를 모델의 다음 입력으로 사용합니다.
다시 가장 확률이 높은 다음 토큰을 선택합니다. (예: being)
이 과정을 반복하여 최종적으로 I have a dream of being a doctor.와 같은 문장을 생성할 수 있습니다.

장점

속도와 효율성: 계산적으로 매우 간단하여 가장 빠르게 결과를 생성할 수 있습니다.
결정론적(Deterministic): 동일한 입력에 대해서는 항상 동일한 출력을 보장합니다.

단점

근시안적 접근: 각 단계에서는 최적의 선택이지만, 전체적으로는 최적의 시퀀스를 놓칠 수 있습니다. 예를 들어, being ($P=9.68%$)과 doctor ($P=2.86%$)의 확률이 상대적으로 낮았음에도 불구하고, 첫 단계에서 of를 선택했기 때문에 이 경로에 갇히게 됩니다. 더 높은 전체 확률을 가진 다른 시퀀스가 존재할 수 있지만 Greedy Search는 이를 고려하지 않습니다.
반복적인 결과: 고품질의 자연스러운 텍스트를 생성하는 데 실패하는 경우가 많으며, 특정 구문이 반복되는 현상이 발생하기 쉽습니다.

이러한 명백한 단점 때문에 Greedy Search는 실제 애플리케이션에서는 거의 사용되지 않지만, 다른 고급 전략들을 이해하기 위한 좋은 출발점입니다.

2. Beam Search (빔 검색)

Beam Search는 Greedy Search의 근시안적인 단점을 보완하는 전략입니다. 각 단계에서 단 하나의 최선이 아닌, num_beams라는 파라미터로 지정된 개수만큼의 가장 가능성 있는 시퀀스(가설)를 유지하고 확장해 나갑니다.

동작 방식

num_beams=2라고 가정해 보겠습니다.

첫 번째 단계에서 가장 확률이 높은 2개의 토큰(예: of, that)을 선택하여 두 개의 독립적인 가설(I have a dream of, I have a dream that)을 생성합니다.
두 번째 단계에서는, 이 두 가설 각각에 대해 다음에 올 모든 토큰의 확률을 계산합니다. 그러면 수많은 가능한 두 토큰 시퀀스가 생성됩니다.
모든 가능한 시퀀스들의 누적 점수(일반적으로 로그 확률의 합)를 계산하고, 가장 높은 점수를 가진 상위 num_beams(2개)의 시퀀스만 유지하고 나머지는 폐기합니다.
이 과정을 목표 길이에 도달할 때까지 반복한 후, 최종적으로 가장 높은 누적 점수를 가진 시퀀스를 결과로 반환합니다.

원문의 예시에서는 Beam Search를 적용했을 때 I have a dream... 이라는 더 일관성 있는 (혹은 안전한) 결과가 생성되었습니다.

장점

더 높은 품질: Greedy Search보다 훨씬 더 전체적인 맥락에서 높은 확률을 갖는 시퀀스를 탐색하므로, 더 일관되고 품질 좋은 문장을 생성합니다.
특정 과제에 유리: 번역이나 요약처럼 정답의 범위가 비교적 명확하고 높은 정확도가 요구되는 작업에서 뛰어난 성능을 보입니다.

단점

계산 비용: num_beams의 크기에 비례하여 계산량과 메모리 사용량이 증가합니다.
창의성 및 다양성 부족: 여전히 가장 가능성 있는 결과에 집중하기 때문에, 인간처럼 창의적이거나 예상치 못한 텍스트를 생성하기는 어렵습니다.
반복 문제: Greedy Search보다는 덜하지만, 여전히 일반적인 문구나 단어를 반복하는 경향이 있습니다. 이를 완화하기 위해 n-gram penalty와 같은 추가 기법이 필요합니다.

3. Sampling (샘플링)

Greedy Search와 Beam Search는 확률이 가장 높은 결과를 따라가는 결정론적 방법입니다. 하지만 인간의 언어는 항상 예측 가능하지 않으며, 때로는 덜 예상되는 단어가 문장을 더 풍부하게 만듭니다. 이러한 무작위성(stochasticity)과 창의성을 모델에 주입하기 위해 Sampling 기법이 사용됩니다.

가장 기본적인 샘플링은 모델이 출력한 확률 분포에 따라 다음 토큰을 무작위로 선택하는 것입니다. 하지만 확률이 매우 낮은 부적절한 단어까지 선택될 위험이 있어, 이를 제어하기 위한 여러 전략이 등장했습니다.

4. Temperature (온도)

Sampling의 무작위성을 조절하는 핵심 파라미터가 바로 Temperature입니다. Temperature는 소프트맥스 함수가 적용되기 전의 로짓 값에 적용되어 확률 분포를 변형시킵니다.

로짓 벡터 $L = (l_1, l_2, ..., l_V)$에 대해, Temperature $T$가 적용된 새로운 확률 $p_i$는 다음과 같이 계산됩니다. $$p_i = \frac{\exp(l_i / T)}{\sum_{j} \exp(l_j / T)}$$

$T < 1$ (예: 0.7): 로짓 값의 차이가 증폭되어 확률 분포가 더 뾰족해집니다(sharper). 모델은 확률이 높은 토큰을 선택할 가능성이 더 커져, 더 안정적이고 예측 가능한 텍스트를 생성합니다. Greedy Search와 유사해집니다.
$T = 1$: 원래 모델의 확률 분포를 그대로 사용합니다.
$T > 1$ (예: 1.5): 로짓 값의 차이가 줄어들어 확률 분포가 더 평평해집니다(flatter). 확률이 낮은 토큰도 선택될 가능성이 생겨, 더 다양하고 창의적이며 예상치 못한 텍스트가 생성됩니다. 하지만 너무 높으면 문맥과 무관한 단어가 등장할 수 있습니다.

5. Top-K Sampling

Top-K Sampling은 샘플링의 품질을 높이기 위한 간단하면서도 효과적인 방법입니다. 전체 어휘집에서 샘플링하는 대신, 가장 확률이 높은 상위 K개의 토큰으로 후보를 제한하고, 그 안에서만 확률에 비례하여 샘플링을 진행합니다.

동작 방식

top_k=50으로 설정하면, 모델이 예측한 모든 토큰 중 가장 확률이 높은 50개를 추립니다.
이 50개의 토큰에 대해서만 확률 분포를 재정규화(re-normalize)합니다.
재정규화된 분포에 따라 다음 토큰을 샘플링합니다.

원문의 예시에서는 Top-K 샘플링을 통해 I have a dream job and I want to와 같이 더 자연스러운 문장이 생성되었습니다.

장점

품질과 다양성의 균형: 확률이 매우 낮은 엉뚱한 토큰이 선택되는 것을 방지하여 문장의 일관성을 유지하면서도, 적절한 수준의 창의성을 부여합니다.

단점

고정된 K의 한계: 확률 분포의 형태에 따라 유연하게 대처하지 못합니다. 예를 들어, 모델이 다음에 올 단어를 매우 확신하는 경우(분포가 뾰족함) K가 50이면 불필요하게 많은 후보를 고려하게 되고, 반대로 여러 가능성이 있는 경우(분포가 평평함) K가 너무 작으면 좋은 후보를 놓칠 수 있습니다.

6. Nucleus Sampling (Top-P Sampling)

Nucleus Sampling (또는 Top-P Sampling)은 Top-K의 한계를 극복하기 위해 제안된 더욱 정교한 전략입니다. 후보 토큰의 개수(K)를 고정하는 대신, 후보들의 누적 확률 합(P)을 기준으로 동적으로 후보 집합의 크기를 조절합니다.

동작 방식

top_p=0.9로 설정하면, 확률이 높은 순서대로 토큰을 정렬합니다.
누적 확률이 0.9를 초과하는 지점까지의 토큰들로 후보 집합(nucleus)을 구성합니다.
이 후보 집합 내에서만 확률을 재정규화하여 샘플링을 수행합니다.

이 방식의 핵심은 확률 분포의 모양에 따라 후보 집합의 크기가 달라진다는 점입니다.

분포가 뾰족할 때 (모델의 확신이 높을 때): 소수의 토큰만으로도 누적 확률 $P$에 도달하므로 후보 집합이 작아집니다.
분포가 평평할 때 (모델의 확신이 낮을 때): 더 많은 토큰이 있어야 누적 확률 $P$에 도달하므로 후보 집합이 커집니다.

원문의 예시에서는 Nucleus Sampling을 통해 I have a dream. I'm going to라는, 의미적으로 더 발전된 문장이 생성되었습니다. 이 전략은 유연성 덕분에 현재 많은 LLM에서 기본적으로 사용될 만큼 높은 성능을 보여줍니다.

결론 및 요약

전략	동작 방식	장점	단점	주요 파라미터
Greedy Search	각 단계에서 가장 확률이 높은 토큰($P_{max}$)을 선택	빠르고 간단함	근시안적, 반복적, 품질 저하	-
Beam Search	`num_beams`개의 가장 가능성 있는 시퀀스를 유지하며 탐색	Greedy Search보다 고품질, 정확성	계산 비용 높음, 창의성 부족	`num_beams`
Top-K Sampling	확률 상위 K개의 토큰 중에서 샘플링	품질과 다양성의 균형	확률 분포 변화에 둔감	`top_k`, `temperature`
Nucleus Sampling	누적 확률 P를 넘는 최소한의 토큰 집합(Nucleus)에서 샘플링	확률 분포에 따라 동적으로 후보 조절, 고품질 및 다양성	Top-K보다 약간 복잡	`top_p`, `temperature`

최적의 디코딩 전략은 해결하려는 과제에 따라 달라집니다.

정확성과 사실 기반 응답이 중요할 때 (번역, 요약, 질의응답): num_beams를 적절히 설정한 Beam Search나, temperature를 낮춘 샘플링 방식이 유용할 수 있습니다.
창의성과 다양성이 중요할 때 (스토리 생성, 창의적 글쓰기, 챗봇 대화): temperature를 약간 높이고 Nucleus Sampling (Top-P)을 사용하는 것이 가장 일반적이고 효과적인 조합입니다.

이러한 디코딩 전략과 파라미터들의 작동 원리를 이해하고 조절함으로써, 우리는 LLM이 생성하는 결과물의 방향성과 품질을 효과적으로 제어할 수 있습니다.

03 프롬프트 엔지니어링

Sun, 27 Jul 2025 06:20:27 GMT

들어가며

랭체인과 랭그래프로 구현하는 RAG·AI 에이전트 실전 입문과 Prompt Engineering Guide 을 읽고 요약한 글입니다.

프롬프트 엔지니어링이란?

LLM으로부터 원하는 출력을 얻기 위해 입력하는 프롬프트를 설계하거나 최적화하는 것

프롬프트 엔지니어링 vs 파인튜닝

프롬프트 엔지니어링은 모델의 가중치를 변경하지 않고 입력(프롬프트)을 조정하여 출력을 제어하는 반면, 파인튜닝은 특정 데이터셋으로 모델을 추가 학습시켜 모델의 가중치 자체를 미세 조정하는 과정입니다. 파인튜닝은 더 많은 비용과 데이터가 필요하지만 특정 작업에 고도로 전문화된 모델을 만들 수 있습니다.
프롬프트의 구성 요소
지시(Instruction): 모델이 수행해야 할 작업에 대한 구체적인 설명
맥락(Context): 모델이 더 나은 응답을 생성하는 데 도움이 되는 배경 정보 또는 추가 정보
입력 데이터(Input Data): 모델이 처리해야 할 정보 또는 질문
출력 지시어(Output Indicator): 생성할 출력의 유형이나 형식을 지정

프롬프트 엔지니어링 기법

Zero-shot

예제나 데이터를 모델에게 미리 학습시키지 않고, 모델의 사전 학습 지식만을 활용해 새로운 작업을 수행하는 방법
모델이 특정 도메인이나 작업에 대해 특별히 훈련되지 않았을 때 사용되며, 다양한 작업에 모델의 일반화 능력을 테스트하는 데 유용함.
프롬프트 예시
```
주어진 텍스트를 긍정, 부정, 중립 중 하나로 분류하세요.
텍스트: 휴가는 괜찮을 것 같아요.
감정:
```
출력 예시
```
중립
```
Few-shot
모델이 더 나은 성능을 내도록 프롬프트에 몇 가지 시연(demonstration) 또는 예시를 포함하는 기법.
예시를 통해 모델은 작업의 맥락, 형식, 요구사항을 학습하여 더 복잡하고 새로운 작업에 빠르게 적응할 수 있음.
프롬프트 예시
```
Task: Correct the grammar of the following sentences.
```

Example 1: Incorrect: She go to the store. Correct: She goes to the store.

Example 2: Incorrect: They is happy. Correct: They are happy.

Now, correct the following sentence: Incorrect: We was playing soccer. Correct:

#### 출력 예시

We were playing soccer.

### Self-Consistency
- 하나의 프롬프트에 대해 여러 개의 다양한 추론 경로를 생성하게 한 후, 그중 가장 일관된(가장 많이 나온) 답변을 최종 결과로 선택하는 기법.
- 단순한 탐욕적 디코딩(greedy decoding)을 대체하여, 산술이나 상식 추론 문제의 성능을 향상시킴.
#### 프롬프트 예시

Q: 제가 6살 때 제 여동생은 제 나이의 절반이었습니다. 지금 저는 70살입니다. 제 여동생은 몇 살일까요? A:

#### 출력 예시

생성 1: 제가 6살 때 여동생은 제 나이의 절반이었으므로 3살이었습니다. 지금 제가 70살이니, 여동생은 70 - 3 = 67살입니다. 답은 67입니다.

생성 2: 화자가 6살일 때 그의 여동생은 그의 나이의 절반인 3살이었습니다. 이제 화자가 70살이므로, 그의 여동생은 70 - 3 = 67세가 될 것입니다. 답은 67입니다.

생성 3: 제가 6살 때 여동생은 제 나이의 절반이었으므로 3살이었습니다. 지금 저는 70살이니, 여동생은 70/2 = 35살입니다. 답은 35입니다.

-> 최종 답변: 여러 추론 과정 중 다수를 차지한 67이 최종 답변으로 선택됩니다[14].

### Generate Knowledge Prompting
- 모델에게 먼저 과업과 관련된 유용한 지식을 생성하도록 요청한 다음, 이 지식을 활용하여 원래의 질문에 답하게 하는 2단계 기법.
- 복잡한 질문에 대해 모델이 더 깊이 있는 맥락을 이해하고 정확한 답변을 생성하도록 유도함.
#### 프롬프트 예시

1단계: 지식 생성

Question: 뉴욕에서 런던으로 가는 항공편이 취소된 경우 재예약 옵션은 무엇인가요? Knowledge: 뉴욕에서 출발하는 승객에 대한 현재 영국 여행 제한 사항과 뉴욕에서 런던으로 가는 다음 항공편의 이용 가능 여부를 확인하세요.

2단계: 지식 통합 및 답변 생성

Knowledge: "현재 영국 여행 제한으로 인해 일부 항공편만 운항이 허용됩니다. 뉴욕에서 런던으로 가는 다음 이용 가능한 항공편은 [날짜]입니다." User Query: 항공편이 취소된 승객을 위한 재예약 옵션은 무엇인가요?

#### 출력 예시

현재 영국 여행 제한으로 인해 항공편 운항이 제한적입니다. 이용 가능한 다음 항공편은 [날짜]이며, 해당 항공편으로 재예약하시거나 전액 환불을 받으실 수 있습니다. 자세한 사항은 항공사 고객 서비스 센터로 문의해 주시기 바랍니다.

### Prompt Chaining
- 복잡한 작업을 여러 개의 논리적인 하위 작업으로 분해하고, 각 단계를 순차적으로 처리하는 기법.
- 한 프롬프트의 출력이 다음 프롬프트의 입력으로 사용되어, 전체적인 작업의 신뢰성과 투명성을 높임.
#### 프롬프트 예시

프롬프트 1: 고객 리뷰에서 핵심 제품과 감정 추출

고객 리뷰: "새로 산 XYZ 스마트폰 카메라는 정말 놀랍지만, 배터리가 너무 빨리 닳아서 실망스러워요." 이 리뷰에서 언급된 제품 기능과 각각에 대한 긍정/부정 감정을 추출해줘.

프롬프트 2: 추출된 정보를 바탕으로 요약문 생성

(프롬프트 1의 출력) 제품 기능: 카메라(긍정), 배터리(부정) 위 정보를 바탕으로 고객 피드백을 한 문장으로 요약해줘.

#### 출력 예시

XYZ 스마트폰은 카메라 성능에 대해서는 긍정적인 평가를 받았지만, 배터리 수명에 대해서는 부정적인 피드백이 있습니다.

### Tree of Thoughts
- '사고의 연쇄(CoT)'를 일반화하여, 문제 해결 과정에서 단일 경로가 아닌 여러 추론 경로를 트리 형태로 탐색하는 기법.
- 모델은 각 단계에서 여러 가능한 '생각(thoughts)'을 생성하고 평가하여 최적의 해결책을 찾아 나감.
#### 프롬프트 예시

문제: 숫자 4, 9, 10, 13을 사용하여 정확히 24를 만드는 수식을 찾아라. 각 숫자는 한 번씩만 사용해야 한다. 생각 생성: 이 문제를 해결하기 위한 첫 단계로 가능한 연산들을 떠올려보자.

10 - 4 = 6. 남은 숫자 9, 13. 6, 9, 13으로 24를 만들 수 있을까?
13 - 9 = 4. 남은 숫자 4, 10. 4, 4, 10으로 24를 만들 수 있을까?
...
```
#### 출력 예시
```
(10 - 4) * (13 - 9) = 6 * 4 = 24. 답은 (10-4)*(13-9)입니다. ```
Retrieval Augmented Generation (RAG)
LLM의 학습 데이터 외부의 신뢰할 수 있는 지식 베이스(예: 데이터베이스, 문서)에서 관련 정보를 검색(Retrieve)하고, 이 정보를 프롬프트에 추가하여 답변을 생성(Generate)하는 기법.

모델이 최신 정보나 특정 도메인 지식을 참조하여 더 정확하고 신뢰성 있는 답변을 생성하게 함.

프롬프트 예시

# 1단계: 정보 검색
사용자 질문: "연차 휴가가 얼마나 남았나요?"
시스템: (인사 데이터베이스에서 '홍길동'의 연차 정책 문서와 과거 휴가 기록을 검색)

2단계: 프롬프트 증강 및 답변 생성

증강된 프롬프트:

검색된 정보: "홍길동의 연간 연차는 15일이며, 올해 5일을 사용했습니다."
사용자 질문: "연차 휴가가 얼마나 남았나요?" LLM, 위 정보를 바탕으로 질문에 답하세요.
```
#### 출력 예시
```
귀하의 연차 휴가는 총 15일 중 5일을 사용하셨으며, 현재 10일이 남아있습니다. ```
Automatic Reasoning and Tool-use (ART)
새로운 작업에 대해 LLM이 스스로 추론 단계를 나누고, 각 단계에 필요한 외부 도구(예: 검색 엔진, 코드 실행기)를 자동으로 선택하고 사용하는 프레임워크.
작업 라이브러리에서 유사한 작업 예시를 참조하여 few-shot 방식으로 문제 분해 및 도구 사용법을 학습함.
프롬프트 예시
```
질문: 에펠탑이 있는 나라의 현재 대통령은 누구이며, 그 나라 인구의 제곱근은 얼마인가?
```

ART 시스템의 자동 생성 계획:

"에펠탑이 있는 나라"가 어디인지 검색 도구를 사용해 찾아라.
1번 결과로 나온 나라의 "현재 대통령"이 누구인지 검색 도구를 사용해 찾아라.
1번 결과로 나온 나라의 "현재 인구"를 검색 도구를 사용해 찾아라.
3번 결과로 나온 인구 수에 대해 "제곱근"을 계산기 도구를 사용해 계산하라.
2번과 4번의 결과를 조합하여 최종 답변을 생성하라.
```
#### 출력 예시
```
에펠탑이 있는 나라인 프랑스의 현재 대통령은 에마뉘엘 마크롱이며, 프랑스 인구(약 6,500만 명)의 제곱근은 약 8062입니다. ```
Automatic Prompt Engineer (APE)

효과적인 프롬프트를 사람이 직접 설계하는 대신, LLM을 사용하여 주어진 작업에 대한 최적의 프롬프트를 자동으로 생성하고 선택하는 기법.
초기 지침을 바탕으로 다양한 후보 프롬프트를 생성하고, 점수를 매겨 가장 성능이 좋은 프롬프트를 최종적으로 채택함.
프롬프트 예시
```
# 초기 목표
주어진 문장의 감정을 분석하는 프롬프트를 만들어라.
```

APE가 생성한 후보 프롬프트들

이 문장은 긍정적인가, 부정적인가, 중립적인가?
다음 텍스트의 감정 톤을 평가하라.
주어진 텍스트를 [긍정, 부정, 중립] 중 하나로 분류하세요. ...

APE의 선택

(내부 평가 후) 3번 프롬프트가 가장 명확하고 높은 성능을 보이므로 최종 프롬프트로 선택.

#### 출력 예시

"주어진 텍스트를 [긍정, 부정, 중립] 중 하나로 분류하세요."

### Active-Prompt
- 어떤 예시가 모델에게 가장 유용한지(가장 불확실한지)를 식별하여 해당 예시에 대해서만 사람의 주석(annotation)을 요청하는 기법.
- 이렇게 수집된 소수의 중요한 예시들을 활용하여 few-shot 프롬프트를 구성함으로써, 최소한의 비용으로 모델 성능을 극대화함.
#### 프롬프트 예시

1단계: 불확실한 질문 식별

모델에게 여러 질문을 제시하고, 어떤 질문이 가장 답변하기 어려운지(불확실성이 높은지) 스스로 평가하게 함.

2단계: 주석 요청 및 프롬프트 구성

가장 불확실하다고 판단된 질문에 대해 사람에게 정답을 요청하고, 이 (질문, 정답) 쌍을 few-shot 예시로 프롬프트에 추가함.

#### 출력 예시

(Active-Prompt로 구성된 예시가 포함된 프롬프트를 통해 더 정확하고 일관된 답변을 생성)

### Directional Stimulus Prompting
- 모델이 원하는 결과물을 생성하도록 유도하기 위해, 프롬프트에 특정 키워드, 힌트, 단서와 같은 '방향성 자극'을 포함시키는 기법.
- 결과물의 주제, 스타일, 포함될 내용 등을 명시적으로 지정하여 모델의 창의성을 특정 방향으로 이끌어 줌.
#### 프롬프트 예시

미래 도시의 외로운 탐정에 대한 짧은 이야기를 써줘. 이야기에 '네온', '비', '사이보그', '음모'라는 단어를 반드시 포함해줘.

#### 출력 예시

자정의 비가 거리를 적시자, 도시의 네온 불빛이 젖은 아스팔트 위에서 번져나갔다. 탐정 잭은 낡은 트렌치코트 깃을 올렸다. 이번 사건은 단순한 실종이 아니었다. 거대 기업의 음모가 숨 쉬고 있었고, 그 중심에는 기억을 잃은 사이보그 증인이 있었다.

### Program-Aided Language Models (PAL)
- 자연어(LLM)와 프로그래밍 언어(Python 등)를 함께 사용하여 문제를 해결하는 기법.
- LLM이 문제 해결을 위한 논리적 단계를 자연어로 생각하고, 실제 계산이나 실행은 코드로 작성하여 인터프리터를 통해 수행함.
#### 프롬프트 예시

문제: 카페에서 5달러짜리 커피 3잔과 3달러짜리 베이글 2개를 샀다. 총 얼마를 내야 하는가? 파이썬 코드로 풀어줘.

LLM의 생각과 코드 생성

커피 가격을 계산한다.

coffee_price = 5 * 3

베이글 가격을 계산한다.

bagel_price = 3 * 2

총액을 계산한다.

total_price = coffee_price + bagel_price

#### 출력 예시

def solution(): coffee_price = 5 * 3 bagel_price = 3 * 2 total_price = coffee_price + bagel_price return total_price

실행 결과: 21

### ReAct
- 추론(Reason)과 행동(Act)을 번갈아 수행하며 상호작용적으로 작업을 해결하는 프레임워크.
- 모델은 현재 상태를 기반으로 '생각(Thought)'을 통해 다음 행동 계획을 세우고, 외부 도구(API, 검색 등)를 사용하는 '행동(Action)'을 실행하며, 그 '관찰(Observation)' 결과를 바탕으로 다시 생각함.
#### 프롬프트 예시

질문: '백년의 고독'을 쓴 작가가 태어난 나라의 가장 높은 산은 무엇인가?

Thought 1: 먼저 '백년의 고독'의 작가를 찾아야 한다. Action 1: Search("author of One Hundred Years of Solitude") Observation 1: 가브리엘 가르시아 마르케스

Thought 2: 가브리엘 가르시아 마르케스가 태어난 나라를 찾아야 한다. Action 2: Search("where was Gabriel Garcia Marquez born") Observation 2: 콜롬비아

Thought 3: 이제 콜롬비아에서 가장 높은 산을 찾아야 한다. Action 3: Search("highest mountain in Colombia") Observation 3: 피코 크리스토발 콜론

Thought 4: 답을 찾았으니 종합하여 답변한다.

#### 출력 예시

'백년의 고독'의 작가 가브리엘 가르시아 마르케스가 태어난 나라인 콜롬비아에서 가장 높은 산은 피코 크리스토발 콜론입니다.

### Reflexion
- 잘못된 답변을 생성했을 때, 실패 경험으로부터 스스로 배우고 수정하는 에이전트 프레임워크.
- 시도(Trial)가 실패하면, '성찰(Reflexion)' 모델이 실패 원인을 분석하고 다음 시도를 위한 구체적인 피드백을 생성하여 에이전트의 기억에 추가함.
#### 프롬프트 예시

작업

주어진 파이썬 함수에서 버그를 찾아 수정하라.

1차 시도 (실패)

(코드를 잘못 수정하여 테스트 케이스 통과 실패)

성찰 과정

"코드를 분석해보니, 인덱스 범위를 잘못 계산하여 'list index out of range' 오류가 발생했다. 반복문의 범위를 n-1이 아닌 n으로 수정해야 한다."

2차 시도

(성찰 내용을 바탕으로 코드를 성공적으로 수정)

#### 출력 예시

(버그가 수정된 최종 코드)

### Multimodal CoT
- 텍스트뿐만 아니라 이미지, 오디오 등 여러 양식(modality)의 정보를 통합하여 단계적인 추론(CoT)을 수행하는 기법.
- 시각적 정보와 텍스트 지시를 함께 이해하고 연관 지어 복잡한 질문에 답할 수 있음.
#### 프롬프트 예시

(이미지로 레스토랑 메뉴판이 주어짐) 질문: 치즈버거와 콜라를 하나씩 주문하면 총 얼마인가요?

추론 과정

이미지에서 '치즈버거' 항목을 찾는다. 가격은 8달러이다.
이미지에서 '콜라' 항목을 찾는다. 가격은 2달러이다.
두 가격을 더한다. 8 + 2 = 10.
```
#### 출력 예시
```
총 10달러입니다. ```
Graph Prompting

노드, 엣지 등으로 구성된 그래프 구조의 데이터를 LLM이 이해하고 처리할 수 있도록 프롬프트 형식으로 변환하는 기법.
그래프의 토폴로지(연결 구조)나 속성을 텍스트로 설명하여, 노드 분류, 링크 예측 등 그래프 관련 과업을 수행하게 함.
프롬프트 예시
``` 그래프 정보:
노드: Alice, Bob, Charlie
엣지: (Alice, Bob), (Bob, Charlie) 이 소셜 네트워크에서 누가 가장 많은 친구를 가지고 있는가?

추론 과정

Alice는 Bob과 연결되어 있다 (친구 1명). Bob은 Alice와 Charlie와 연결되어 있다 (친구 2명). Charlie는 Bob과 연결되어 있다 (친구 1명). 따라서 Bob이 가장 많은 친구를 가지고 있다.

#### 출력 예시

Bob

```

출처

02 OpenAI Chat API 기초

Fri, 25 Jul 2025 23:35:38 GMT

들어가며

랭체인과 랭그래프로 구현하는 RAG·AI 에이전트 실전 입문을 읽고 요약한 글입니다. 2장에서는 다음의 개념을 주로 다룹니다.

OpenAI의 Chat 모델
Chat Completions API
- 개념
- 주요 Parameter
- Function calling
Token, Tokenizer

OpenAI의 Chat 모델

GPT-4o, GPT-4o-mini 등의 명칭은 실제로는 모델 패밀리를 가리킨다.
API 사용 시 모델 패밀리(예: gpt-4o) 혹은 정확한 모델 스냅숏(예: gpt-4o-2024-08-06)을 지정할 수 있다.
모델 패밀리마다 최대 입력 토큰 수, 최대 출력 토큰 수, 요금 정책이 다르다.

Chat Completions API

개념

ChatGPT UI를 사용할 때와 마찬가지로, '입력 텍스트를 제공해 응답 텍스트를 얻는' 방식으로 동작한다.

다음은 Chat Completions API로의 요청 예시이다.

{
  model="gpt-4o-mini",
  messages=[
    {"role": "system", "content": "You are a helpful assistant."},
    {"role": "user", "content": "안녕하세요! 저는 이한서라고 합니다."},
    {"role": "assistant", "content": "안녕하세요, 이한서님! 만나서 반갑습니다. 오늘은 어떤 이야기를 나눠볼까요?"},
    {"role": "user", "content": "제 이름을 기억하세요?"}
  ]
}

Chat Completions API의 요청 파라미터에는 최소한 model, messages가 포함된다.
Chat Completions API 자체는 State를 저장하지 않아, 과거 대화 이력을 고려해 응답할 수 없다. 따라서 대화 이력을 고려해 응답하고 싶다면 messages에 과거의 모든 대화를 포함해야 한다.

호출 및 응답 예시

# 호출 예시
from openai import OpenAI

client = OpenAI()

response = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[
    {"role": "system", "content": "You are a helpful assistant."},
    {"role": "user", "content": "안녕하세요! 저는 이한서라고 합니다."},
    {"role": "assistant", "content": "안녕하세요, 이한서님! 만나서 반갑습니다. 오늘은 어떤 이야기를 나눠볼까요?"},
    {"role": "user", "content": "제 이름을 기억하세요?"}
  ]
)

print(response.to_json(indent=2))

# 응답 예시
{
  "id": "chatcmpl-BxGXp8zdZyJxkI4CgOBEtfQwb6m4o",
  "choices": [
    {
      "finish_reason": "stop",
      "index": 0,
      "logprobs": null,
      "message": {
        "content": "네, 이한서님! 당신의 이름을 기억하고 있습니다. 어떤 도움이 필요하신가요?",
        "refusal": null,
        "role": "assistant",
        "annotations": []
      }
    }
  ],
  "created": 1753464649,
  "model": "gpt-4o-mini-2024-07-18",
  "object": "chat.completion",
  "service_tier": "default",
  "system_fingerprint": "fp_197a02a720",
  "usage": {
    "completion_tokens": 23,
    "prompt_tokens": 66,
    "total_tokens": 89,
    "completion_tokens_details": {
      "accepted_prediction_tokens": 0,
      "audio_tokens": 0,
      "reasoning_tokens": 0,
      "rejected_prediction_tokens": 0
    },
    "prompt_tokens_details": {
      "audio_tokens": 0,
      "cached_tokens": 0
    }
  }
}

주요 Parameter

파라미터명	개요	기본값
`temperature`	0~2 사이의 값으로, 클수록 출력이 무작위해지고, 작을수록 결정적이고 예측 가능해짐.	1
`n`	한 번의 요청에 대해 생성할 답변 수 (예시: 3으로 설정하면 3개의 서로 다른 응답을 받을 수 있음.)	1
`stop`	답변 생성을 중단할 문자열(또는 문자열 배열). 이 문자열이 등장하면 해당 지점에서 생성이 멈춤. (예시: `stop=["\n\n", "###"]`)	null (중단 없음)
`max_tokens`	생성할 최대 토큰 수(답변의 길이 제한). 이 값을 넘어가면 답변 생성이 중단됨. 입력 토큰을 포함하지 않으며, 답변 자체의 길이만 제한함.	max_model_tokens
`log_probs`	답변의 각 토큰에 대한 로그 확률을 반환할지 여부.	false
더 많은 파라미터는 문서를 참고하자.

Function calling

개발자가 미리 정의해 둔 외부 함수나 코드를 호출하고 그 결과를 바탕으로 더 정확하고 유용한 답변을 생성하게 하는 기능이다.
사용 가능한 함수를 LLM에게 알려주고, LLM에게 '함수를 사용하고 싶다'는 판단을 하게 하는 기능이다. (LLM이 함수를 실행하는 것이 아니라, LLM은 '함수를 사용하고 싶다'는 응답만 반환한다.)
아래는 질문(서울 날씨는 어때?)에 대해 적절한 함수(get_weather)를 반환하는 예제이다.

import openai
import json

# get_weather: 입력한 지역의 날씨를 알려주는 (예시용 더미) 함수 정의
def get_weather(location, unit="celsius"):
    if "seoul" in location.lower():
        return json.dumps({"location": "Seoul", "temperature": "26", "unit": unit})
    return json.dumps({"location": location, "temperature": "unknown"})

client = openai.OpenAI() # OpenAI Client 초기화


def run_conversation():
    messages = [{"role": "user", "content": "서울의 현재 날씨는?"}]
    # function calling에 사용할 함수 목록 정의
    tools = [
        {
            "type": "function",
            "function": {
                "name": "get_weather",
                "description": "Get the current weather in a location",
                "parameters": {
                    "type": "object",
                    "properties": {
                        "location": {"type": "string", "description": "도시 이름 (예: Seoul)"},
                        "unit": {"type": "string", "enum": ["celsius", "fahrenheit"]},
                    },
                    "required": ["location"]
                },
            },
        }
    ]

    # Chat Completions API 호출
    response = client.chat.completions.create(
        model="gpt-4o",
        messages=messages,
        tools=tools,
        tool_choice="auto" # 모델이 지정된 함수를 사용해야 한다고 판단하면 함수명과 인수를 반환
    )

    response_message = response.choices[0].message
    tool_calls = response_message.tool_calls

    if tool_calls:  # 모델이 함수 호출 요청
        messages.append(response_message)
        for tool_call in tool_calls:
            function_args = json.loads(tool_call.function.arguments)
            function_response = get_weather(
                location=function_args.get("location"),
                unit=function_args.get("unit", "celsius"),
            )
            messages.append({  # 함수 실행 결과 메시지 추가
                "tool_call_id": tool_call.id,
                "role": "tool",
                "name": "get_weather",
                "content": function_response,
            })

        # 함수 실행 결과 반영 반복 요청
        second_response = client.chat.completions.create(
            model="gpt-4o",
            messages=messages,
        )
        return second_response.choices[0].message.content

# 실행 예시
final_answer = run_conversation()
print(final_answer) # 출력: 서울의 현재 날씨는 섭씨 26도입니다.

JSON 모드

JSON 형태의 출력을 얻기 위해선 Chat Completions API의 'JSON 모드'를 사용할 수 있다. 이를 위해선

프롬프트에 'JSON'이라는 문자열을 포함시키고
response_format 파라미터에 {"type": "json_object"}를 지정한다.

# JSON 모드 호출 예시
from openai import OpenAI

client = OpenAI()

response = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[
        {
            "role": "system",
            "content": '인물 목록을 다음 JSON 형식으로 출력해주세요.\n{"people": ["aaa", "bbb"]}',
        },
        {
            "role": "user",
            "content": "제가 좋아하는 노래는 정승환의 '비가 온다', 브리즈의 '뭐라할까!' 입니다. 으하하~",
        },
    ],
    response_format={"type": "json_object"},
)

print(response.choices[0].message.content)

출력 결과는 다음과 같다.

요금

모델별 요금은 docs/models에서 확인할 수 있다.
실제로 발생한 요금은 usage에서 확인할 수 있다.

cf. Batch API

GPT-4o나 GPT-4o-mini를 이용하기 위해 Chat Completions API 대신 Batch API를 사용할 수도 있다.
Batch API는 비동기적으로 출력이 생성된다.
즉시 응답을 얻을 수 없는 대신, Chat Completions API의 절반 가격으로 이용할 수 있다.

Token, Tokenizer

LLM은 텍스트를 '토큰'이라는 단위로 분할해 처리하며, 분할 기준은 토크나이저마다 다르다. 예시) tiktoken: ChatGPT -> Chat, GPT

토큰 수 확인

OpenAI 플랫폼의 Tokenzier 또는 Python 패키지 tiktoken을 사용해 토큰 수를 확인할 수 있다.

한국어의 토큰 수에 대해

같은 의미의 텍스트라도 영어를 사용했을 때에 비해 한국어를 사용했을 때 더 많은 토큰을 사용하는 경향이 있다.
따라서 토큰 수를 줄일 목적으로는 한국어보다 영어를 사용하는 것이 바람직하다.

예시: 한국어와 영어의 토큰 수 비교 (gpt-4o)

"LLM을 사용해 멋진 것을 만들기는 쉽지만, 프로덕션에서 사용할 수 있는 것을 만들기는 매우 어렵다." -> 28 tokens
"It's easy to make something cool with LLMs, but very hard to make something production-ready with them." -> 23 tokens