멀티 턴 대화에서 LLM은 길을 잃음

 (arxiv.org)
4P by GN⁺ | ★ favorite | 댓글 1개
  • 사용자가 요구사항을 한 번에 완전히 쓰지 못하는 상황에서, 15개 LLM의 멀티 턴·불완전 명령 성능은 단일 턴·완전 명령보다 크게 낮아져 6개 생성 과제 평균이 90%에서 65%로 떨어짐
  • 실험은 기존 단일 턴 벤치마크 명령을 여러 조각으로 나누는 샤딩(sharding) 방식으로 구성해, 대화가 진행될수록 조건과 맥락이 조금씩 드러나게 함
  • 성능 저하는 단순한 능력 부족보다 불안정성 증가의 영향이 컸고, 200,000개 이상 대화에서 모델은 초반 가정과 이른 최종 답변 시도에 과도하게 의존함
  • 테스트 대상은 Llama3.1-8B-Instruct부터 Gemini 2.5 Pro까지 포함됐으며, Code, Database, Actions, Math, Data-to-Text, Summary 등 프로그래밍과 자연어 생성 과제를 함께 사용함
  • 실제 인간-AI 대화를 단순화한 시뮬레이션이지만 모든 대화가 과제 해결에 충분한 정보로 끝나도록 설계됐기 때문에, 관측된 하락폭은 실제 불완전 멀티 턴 대화보다 작을 수 있음

단일 턴 평가와 실제 대화 사용의 간극

  • LLM은 ChatGPT, Gemini, Claude처럼 대화형 인터페이스로 사용되며, 사용자는 처음부터 요구사항을 완전히 특정하지 못해도 여러 턴을 거치며 요구를 정의·탐색·수정할 수 있음
  • 기존 LLM 평가는 주로 단일 턴·완전 명령 환경에 집중했지만, LLM 대화 로그에서는 사용자 지시의 불완전성이 흔하게 나타남
  • 기존 멀티 턴 평가 다수는 대화를 독립적으로 평가 가능한 하위 과제들의 배열처럼 다루는 episodic 방식에 가까움
    • 턴 사이 맥락 이해를 일부 요구하지만, 불완전한 사용자 지시에서 정보를 능동적으로 결합하는 상황과는 다름
    • 이런 과제는 멀티 턴 대화에서 LLM 성능을 실제보다 높게 보이게 할 수 있음

샤딩으로 만든 불완전 멀티 턴 대화

  • 실험은 고품질 단일 턴 벤치마크의 완전한 명령을 sharded instruction으로 변환함
    • 첫 번째 shard는 과제의 높은 수준 의도를 제시함
    • 이후 shard는 원래 명령의 추가 조건이나 맥락을 하나씩 제공함
    • 모든 shard를 합치면 원래 완전 명령과 같은 정보를 담음
  • 예시로 GSM8K의 눈덩이 문제는 단일 지문에서 “시간당 20개 생성”, “15분마다 2개 녹음”, “총 60개 필요” 같은 조건을 모두 제공하지만, sharded 버전은 이를 여러 턴에 걸쳐 나눠 공개함
  • 샤딩 과정은 반자동으로 수행됐으며, GPT-4o가 후보를 만들고 검증한 뒤 연구자가 검토·수정함

대화 시뮬레이션 구조

  • 멀티 턴 시뮬레이션에는 세 주체가 있음
    • 평가 대상 assistant: 성능을 측정할 LLM
    • user simulator: 전체 sharded instruction을 알고 있으며 각 턴에서 다음 shard를 공개하는 LLM
    • system: assistant 응답을 분류하고 답변 시도를 평가하는 구성요소
  • 첫 턴에서 user simulator는 첫 shard만 공개하고, assistant는 자유 텍스트로 응답함
  • assistant 응답은 7가지 전략 중 하나로 분류됨
    • clarification
    • refusal
    • hedging
    • interrogation
    • discussion
    • missing
    • answer attempt
  • answer attempt로 분류되면 answer extractor가 코드 조각, 숫자, SQL 등 평가에 필요한 답변 범위를 추출하고, 과제별 evaluator가 점수를 매김
  • 대화는 두 조건 중 하나에서 종료됨
    • assistant의 답변 시도가 정답으로 평가됨
    • 새 턴 시작 시 더 공개할 shard가 없음
  • user simulator, strategy classifier, answer extractor는 prompt 기반 GPT-4o-mini로 구현됨
  • 수백 개 대화를 수동 주석한 결과, user simulator·classifier·extractor 오류는 검사한 대화의 5% 미만에서 발생했고 assistant 모델에 불리하게 작용한 오류는 2% 미만이었음

비교한 다섯 가지 시뮬레이션 유형

  • FULL은 원래 완전 명령을 첫 턴에 제공하는 단일 턴 시뮬레이션이며, 기본 성능 기준선으로 사용됨
  • SHARDED는 shard를 여러 턴에 걸쳐 공개하는 멀티 턴·불완전 대화이며, 핵심 평가 환경임
  • CONCAT은 shard들을 한 턴의 bullet-point 명령으로 합쳐 제공함
    • FULL처럼 불완전성이 제거됨
    • SHARDED처럼 샤딩 과정에서 생긴 재표현은 유지됨
    • FULL과 CONCAT에서는 성공하지만 SHARDED에서 실패하면, 정보 손실보다 멀티 턴·불완전성 자체가 원인일 수 있음
  • RECAP은 SHARDED 대화 뒤 마지막에 모든 shard를 한 번에 다시 제시해 LLM에 최종 답변 기회를 줌
  • SNOWBALL은 각 턴에서 새 shard와 지금까지 공개된 모든 shard를 함께 다시 말해, 턴마다 누적 요약을 제공함

사용한 과제와 벤치마크

  • 실험은 프로그래밍과 자연어 생성 사용 사례를 모두 포함하는 6개 생성 과제로 구성됨
  • 각 과제마다 90~120개 sharded instruction을 준비했고, 전체는 600개 instruction임
  • 과제 구성:
    • Code: HumanEval, LiveCodeBench 기반 Python 함수 작성
    • Database: Spider 기반 text-to-SQL 생성
    • Actions: Berkeley Function Calling Leaderboard 기반 API 함수 호출 생성
    • Math: GSM8K 기반 초등 수학 문장제 풀이
    • Data-to-Text: ToTTo 기반 표 데이터 설명 문장 생성
    • Summary: Summary of a Haystack 기반 문서 묶음 요약과 인용 생성
  • 평가 지표는 원래 벤치마크의 지표를 재사용함
    • Code와 Database는 실행 기반 정확도
    • Actions와 Math는 참조 답변과의 의미적 동등성 또는 수치 정답
    • Data-to-Text는 BLEU
    • Summary는 정보 포괄성과 출처 귀속 정확도를 측정하는 LLM-as-a-judge “Joint Score”
  • 이진 정확도도 0~100 범위로 매핑해 모든 과제 점수를 같은 스케일에서 집계함

성능, 능력, 불안정성 측정

  • LLM 출력은 확률적이므로 같은 instruction과 시뮬레이션 유형에 대해 N=10회 반복 실행함
  • 각 실행은 0~100 범위의 점수로 평가됨
  • 세 지표를 사용함
    • 평균 성능 P: 반복 실행 점수의 평균
    • aptitude A90: 점수의 90번째 백분위로, 상위 10% 실행에서의 best-case 성능 추정
    • unreliability U90-10: 90번째 백분위와 10번째 백분위의 차이로, best-case와 worst-case 사이 격차를 측정
  • 단일 턴에서는 aptitude가 높은 모델이 더 신뢰성도 높은 경향을 보였지만, 멀티 턴에서는 aptitude와 관계없이 모든 LLM에서 높은 unreliability가 나타남

대규모 실험 결과

  • 메인 실험은 600개 instruction, 3개 시뮬레이션 유형(FULL, CONCAT, SHARDED), 15개 LLM을 대상으로 진행됨
  • 각 조합을 10회 반복해 200,000개 이상의 대화를 시뮬레이션함
  • 모든 시뮬레이션은 기본 temperature T=1로 수행됐으며, temperature가 aptitude와 reliability에 미치는 영향은 별도 보조 실험에서 다룸
  • 전체적으로 멀티 턴·불완전 대화의 평균 성능은 65% 였고, 전체 명령을 처음부터 받은 단일 턴 성능 90% 보다 25포인트 낮음
  • 작은 open-weight 모델부터 최신 모델까지 멀티 턴 성능 하락이 공통적으로 나타남
    • 테스트 대상에는 Llama3.1-8B-Instruct 같은 작은 open-weight 모델과 Gemini 2.5 Pro 같은 최신 모델이 포함됨
    • Figure 1에는 Claude 3.7 Sonnet, Deepseek-R1, o3, GPT-4.1, Gemini 2.5 Pro가 예시로 표시됨
  • 6개 생성 과제 평균 성능 하락은 39% 이며, Figure 1은 멀티 턴 설정에서 약 -35% 성능 저하를 표시함

왜 길을 잃는가

  • 성능 저하는 두 요소로 나뉨
    • aptitude 감소: best-case 성능 자체가 일부 낮아짐
    • unreliability 증가: 실행 간 품질 격차가 크게 커짐
  • Figure 1 기준 멀티 턴에서는 aptitude가 -15% 낮아지고 unreliability가 +112% 높아짐
  • 모델은 불완전한 초반 정보만 보고 잘못된 가정을 만들고, 대화 초기에 최종 답변을 시도하는 경향을 보임
  • 이후 새 정보가 제공돼도 이전의 잘못된 답변 시도에 과도하게 의존해 방향 수정에 실패함
  • 멀티 턴 불완전 대화에서 한 번 잘못된 방향으로 들어가면 회복하지 못하는 현상이 lost in conversation으로 정의됨

한계와 실무적 함의

  • 완전 자동 시뮬레이션은 실제 인간-AI 대화를 그대로 대표하지 않음
  • 실험 환경은 단순화·이상화되어 있음
    • 대화는 과제를 풀기에 충분한 정보로 끝나도록 보장됨
    • 실제 환경에서 발생할 수 있는 대화 이탈 같은 예기치 않은 행동은 제한됨
  • 이런 설계 때문에 관측된 성능 저하는 실제 불완전 멀티 턴 인간-AI 대화에서 발생하는 저하보다 과소평가일 수 있음
  • LLM 기반 대화 제품을 만드는 조직과 최종 사용자는 멀티 턴 신뢰성을 단일 턴 능력과 함께 평가해야 함
  • 불완전한 요구사항을 처음부터 완전하게 쓰기 어려운 초보 사용자에게는 멀티 턴 성능 저하가 AI 시스템 사용 확산을 낮추는 원인일 가능성이 있음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • LLM 도구를 써 본 사람이라면 휴리스틱하게 이미 아는 내용을 논문이 확인해 주는 건 반가움. 깨끗한 문맥 유지가 중요하고, “대화”는 제품 인터페이스가 만든 구성물일 뿐이며 LLM 자체의 응답 품질에는 해가 됨. 문맥이 한 번 오염되면 회복되지 않으니 새 채팅으로 다시 시작해야 함

    • 내 경험도 어느 정도는 이 관찰과 맞지만, 다른 경우도 있었음. Gemini로 IPSEC 문제를 2주 동안 디버깅했는데, 처음에 OPNsense와 pfSense의 IPSEC 문서를 모두 넣고 작업 맥락을 알려준 뒤 양쪽 설정을 민감정보 제거 후 추가했음. 이후 로그를 올리고 질문하고 답하는 긴 피드백 루프를 돌림
      2주가 끝날 때쯤 LLM은 훨씬 덜 산만해졌고, 포럼 스레드나 Stack Overflow 글 전체를 넣어도 “이건 여기서 보는 현상이 아니다. 이유는 [이전 문맥이나 발견] 때문이다”라고 구분해 줬음. 막다른 길은 내가 논리적으로 제거하고 알려줘야 했지만, 결국 원인을 찾았음
      LLM은 복잡한 정보를 단순하게 압축하는 데 강하고, 단순한 아이디어를 복잡한 것으로 확장하는 데는 약하다는 말과도 맞아 보임. 입력이 출력보다 크거나 복잡할 때는 결과가 만족스러웠음
      LLM 없이도 할 수는 있었지만, 초반부터 넣어 둔 사실을 잊었거나 새 맥락에서 빨리 떠올리지 못할 때 저장소처럼 도움을 줬고, 큰 로그 파일의 시간 패턴을 찾는 데도 유용했음. 문제 하나만 고친 게 아니라 여러 설정도 최적화했고 꽤 많이 배웠음. 현재 파라미터 상태를 가끔 틀리긴 했지만 쉽게 고칠 수 있었음. 어디로 가는지 알고 도구로 다루면 도움이 되지만, 의사결정을 넘기거나 잘못된 방향으로 끌려가게 두면 안 됨
      전체 사용량은 350k 토큰 정도였음. 관련 블로그 글은 https://du.nkel.dev/blog/2021-11-19_pfsense_opnsense_ipsec_cgnat/에 있으며, 이 특정 문제와 직접 일치하지는 않음. WireGuard 추천은 사양함
    • 내 경험과 정확히 맞음. “오염”이라는 표현이 좋음. 한 번 뭔가 잘못되면 이후 응답이 전부 나빠지는 느낌이라 ChatGPT의 메모리 기능도 애매하게 봄. 큰 문제를 일으키는 건 잘 못 느끼지만, 내가 완전히 이해하지 못하는 방식으로 문맥을 더럽히는 점이 마음에 들지 않음
    • 오래전부터 대화 포크가 가능했으면 좋겠다고 말해 왔음. 유망한 흐름을 되돌릴 수 없게 오염시키지 않고, 교환이 어느 방향으로 가는지 실험하고 싶음. ChatGPT에서는 안 되는데, 이 기능을 제공하는 곳이 있는지 궁금함
    • 내가 가르치는 1순위 팁은 ChatGPT와 Claude의 아주 작고 거의 숨겨진 “편집” 버튼을 적극적으로 쓰는 것임. 나쁜 응답이 나오면 그 위에 계속 쌓지 말고, 멈춰서 편집해 더 나은 응답을 얻어야 쓰레기가 쓰레기를 증식시키지 않음
    • 이 문제의 흥미로운 작은 예가 초기 프롬프트임. 사실상 지울 수 없는 영구적이고 숨겨진 문맥이기 때문임. 지금 Twitter의 “Grok” 봇이 최근 “White Genocide”를 자주 언급하기 시작했는데 꽤 이상함
      누군가 최근 프롬프트를 조정해 백인 학살에 대한 관점을 지정했을 가능성이 크고, 완벽한 챗봇이라면 다른 주제를 물을 때 중요하지 않겠지만 실제로는 중요함. 그게 문맥의 일부라서 이제 그 얘기를 하게 됨

  • 잘 알려진 과신과 자기성찰 불능의 한 측면처럼 보임. 사전 확률이 너무 낮으면 더 자세한 정보를 요청해야 한다는 걸 알아차리지 못함. 추론 모델의 출력을 보면 해명 질문을 해야겠다는 생각이 거의 나오지 않고, 혼란스러울 때는 사용자가 무슨 뜻이었을지 끝없이 추측만 함
    이건 “인간 프로그래머 대체”라는 생각의 현명함에도 함의가 있음. 이 직업의 어려운 부분 중 하나는 이해관계자와 상호작용하면서 모호하고 종종 혼란스러운 아이디어를 정확한 명세로 바꾸는 일이기 때문임

    • “자기성찰 불능”에 대해, LLM을 다룰 때의 핵심 요령은 실제 주체가 없고 사용자가 불신 유예의 서사에 속고 있다는 점을 인식하는 것이라고 봄
      대부분의 경우 사용자는 영화 대본 문서의 User 캐릭터 대사를 쓰고 있고, LLM 알고리즘은 주기적으로 Chatbot 캐릭터의 미완성 대사를 자동완성할 뿐임
      DraculaBot이라는 흡혈귀와 인터뷰할 수는 있지만, 그 캐릭터가 “피를 갈망”하거나 “박쥐 떼로 변신”하는 것과 같은 얕고 허구적인 방식으로만 “자기성찰”할 수 있음
    • LLM이 명확화 질문을 못 하는 점은, 모호하게 서술된 열린 문제를 테스트할 때 정확히 마주친 결함이었음. 역설적 상황을 DeepSeek-R1과 Claude-3.7-Sonnet으로 시험한 맥락이었고, 실험 글은 https://pankajpansari.github.io/posts/paradoxes/에 있음
    • 실제 프로그래머는 사람들이 진짜로 원하는 게 뭔지 알아내는 데 엄청난 시간을 씀. LLM은 여전히 추측을 기능처럼 다룸
    • 이걸 읽으면 똑똑한 사람들이 더 나은 Emacs doctor에 속는 장면을 보는 느낌임. LLM은 성찰하지도 않고 자신감이 있는 것도 아님. “그저” 텍스트 자동완성을 제안하는 것임
      그래서 자동완성이 나빠지기 시작하면 새로 시작해야 함. 어떤 개념도 없고, 훈련 텍스트가 보여 준 단어와 가능한 후속 텍스트의 거대한 덩어리만 있음
    • “인간 프로그래머 대체”라는 생각과 관련해 아이러니하게도, 주니어 개발자와 일하는 것도 이와 꽤 비슷함. 일을 맡긴 뒤 나중에 개와 손전등을 들고 깊은 숲으로 찾으러 가야 함. 그냥 밀고 나가고, 가정하고, 질문하지 않다가 길을 잃기 때문임

  • 종종 LLM에게 지금까지의 논의를 프롬프트 형식의 간결한 요약으로 만들어 달라고 함. 그걸 적절히 편집해 짐이 없는 새 대화를 시작하는 데 쓰면 아주 효과적이었음. 아마 곧 자동화될 것 같음

    • Cursor가 이걸 자동으로 시도했음. Gemini 2.5 Pro 같은 큰 문맥 모델을 쓰지 않으면 아직도 그럴 수 있음. 하지만 요약에서 빠지는 세부사항이 너무 많아 그대로 쓰기 어려웠음
    • Claude Code에는 지금까지의 대화를 요약해 문맥 토큰을 아끼는 /compact 명령이 있음

  • 그래서 TSCE(Two-Step Contextual Enrichment)를 만들게 됨. GPT-35-turbo로 300개 작업을 섞어 테스트했을 때 +30퍼센트포인트 향상이 있었음
    무료 공개 프레임워크이고 저장소에서 직접 시험해 볼 수 있음: https://github.com/AutomationOptimization/tsce_demo
    사람들이 싫어하는 튀는 “em-dash”를 제거하는 작업으로 gpt-4.1에서 다시 300번 테스트했음. 단일 패스 기준선과 TSCE를 같은 지시와 프롬프트 “Remove the em-dashes from my linkedin post. . .”로 비교함
    300회 중 기준선은 149/300번 em-dash 제거에 실패했고, TSCE는 18/300번 실패했음. 동작하며, 모든 데이터와 테스트 스크립트 전체가 저장소에 있음

    • 찾기-바꾸기 작업에 너무 많은 킬로와트시를 낭비한 것 같음. text.replace("—", "-")는 들어봤는지 궁금함
    • em dash 기준선 예제를 약간만 바꿨더니, 추가 호출이나 토큰 비용이나 기술 허세 없이 GPT-4.1에서 100% 성공률이 나왔음
      시스템 프롬프트: "Remove every em-dash (—) from the following text while leaving other characters unchanged.\n\nReturn only the cleaned text."
      사용자 프롬프트:
      Temperature: 0.0

  • 이 문제를 푸는 작업을 꽤 성공적으로 해 오고 있고, 곧 더 공유할 예정임. 시스템이 2개 있는데, 첫 번째는 LLM 자체이고 다른 하나는 일종의 생각 큐레이터처럼 동작함
    문맥 일부를 동적으로 넣고 빼며, 명시적 정의에 기반하지 않고 LLM이 “빈틈을 채우는” 능력에 의존함. 이 시스템은 LLM이 문제를 작은 작업으로 분해하게 돕고, 그 작은 작업들이 결국 전체 작업으로 집계됨

    • 좋은 아이디어임. 사실상 채팅 위에서 하는 검색 증강 생성(RAG) 임
      앞으로는 이런 메모리 계층 구분이 더 명확해질 것 같음. 훈련 데이터의 1차 메모리, 문맥의 2차 메모리, RAG의 3차 메모리처럼 나뉠 수 있음
    • 흥미로운 아이디어로 들림. 프롬프트 몇 개 수준에 불과하더라도 지금 가진 걸 세상에 공개하는 걸 권하고 싶음. 사람들이 보고 개선할 수 있고 좋은 아이디어라면 채택되어 다른 사람들이 작업하게 되며, 자체 생명력을 가질 수도 있음
    • 이건 Emotion Machine의 정신적 비평가 부류임
    • 그러면 Map-Reduce-of-Thought인가?

  • 주요 채팅 도구에서 분기/포크가 핵심 기능이 아니라는 게 놀라움. 응답 편집은 가능하지만 그러면 다른 문맥이 많이 사라짐
    내 흐름은 대략 1) 계획 2) 구현 3) 분기(기능이나 특이한 의존성 문제로) 4) 2번으로 이동임. 프롬프트 가지치기와 분기는 어떤 LLM 사용에서도 1급 도구여야 함

    • Google AI Studio에는 적어도 이 기능이 있음. 다만 그 구현은 꽤 헷갈렸고, 그래서 더 “소비자 지향” 도구들에 잘 안 들어가는 이유일 수도 있음
    • 한동안 이런 걸 만들어 볼까 고민했음. BetterChatGPT는 적어도 기록 삭제의 사용성은 괜찮음. 하지만 다음 단계는 분기라는 데 동의함

  • 단일 턴 대화 중심으로 LLM 인터페이스를 만들면 눈에 띄는 문제가 있음. 대부분의 사람은 선형 대화를 기대함
    LLM을 위한 범용 UI로 Telegram 봇 http://t.me/experai_bot을 만들었는데, 기능은 다소 줄였고 “답장 아닌 메시지는 새 대화”라는 아이디어를 중심으로 설계했음. 문맥을 유지하고 싶으면 봇의 답장에 계속 답장하면 됨. 고급 사용자가 아닌 사람들은 이 발상을 어려워함
    OpenAI 모델이 같은 질문에 답할 때, 아주 작은 시스템 메시지만 있어도 성능이 더 나빠지는 것도 봤음. 예를 들어 답장 속 선택지 목록이 짧아졌음. 3.5와 4o에서 그랬고 최신 모델은 모르겠음. 그래서 기본적으로 시스템 메시지를 넣지 않기로 했음. 그래도 필요하면 추가할 수 있고, 켜고 끄며 조합할 수도 있음

  • 지금 LLM 영역은 같은 문제를 계속 풀고 또 푸는 사람들로 가득한 느낌임

    • 일부 워크플로에서는 괜찮지만, 이건 “학습”이라기보다 고양이 몰이에 가까움
    • 모두가 자기만의 뛰어난 프롬프트 엔지니어링을 보태고 싶어 함

  • 이게 내가 promptdown을 만든 주된 이유였음. 매 턴마다 전체 채팅 기록을 편집할 수 있길 원했고, 추가만 되는 표준 채팅 인터페이스에서는 그게 쉽지 않음
    https://github.com/t-kalinowski/promptdown

  • “프롬프트 엔지니어링”이라는 용어에 대한 조롱은, 사람들이 초기 프롬프트의 중요성은 과대평가하고 진행 중인 문맥 관리의 중요성은 과소평가해서 생긴 면도 있다고 늘 느꼈음
    경험을 통해 모델을 어떻게 조종할지, 언제 새 대화를 시작할지 감을 익히게 됨. 시스템 프롬프트나 초기 프롬프트도 중요하지만, 순진하게 대화를 너무 오래 끌고 가면 아무것도 구해 주지 못함

    • 맞음. 프롬프트 엔지니어링은 완벽한 첫 문장을 만드는 것만이 아니라 대화 관리에 더 가까움. 흐름이 탈선하는 시점과 초기화해야 할 때를 감으로 익히게 됨
답변달기