▲

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

(arxiv.org)
3P by GN⁺ 7일전 | ★ favorite | 댓글 1개
  • 대형 언어 모델(LLM) 은 다중 턴 대화에서 성능 저하와 신뢰성 감소 현상을 보임
  • 싱글 턴 대비 다중 턴 상황에서 평균 39% 성능 하락이 실험적으로 확인됨
  • 주된 요인은 작은 적성 감소와 매우 큰 신뢰성 저하, 즉 결과의 일관성 부족임
  • LLM은 이른 시점에서 잘못된 가정을 세우거나, 최종 해답을 너무 빨리 시도하는 경향이 있음
  • 결과적으로 LLM이 대화 초반에 실수하면 회복하지 못하고 대화 방향을 잃는 현상이 발견됨

ABSTRACT

  • 대형 언어 모델(LLM) 은 대화형 인터페이스로, 사용자의 요구를 완전히 명시하지 못할 때에도 다중 턴 대화를 통해 점진적으로 요구 사항을 정의·탐색·수정하도록 도와줄 수 있는 잠재력을 가진 존재임
  • 그러나 대부분의 LLM 평가가 싱글 턴 완전 명세 지시 환경에만 집중되어 있음에도, 실제 대화 로그 분석에서는 지시 불명확(underspecification) 현상이 빈번하게 보임
  • 본 연구에서는 싱글 턴과 다중 턴(underspecified) 환경에서 LLM의 성능을 대규모로 시뮬레이션하여 비교함
  • 그 결과, 15개의 주요 LLM 모두에서 다중 턴 대화에서 평균 39%의 성능 저하가 있으며, 이는 적성 약간 감소와 신뢰성 급격한 저하로 분석됨
  • LLM이 대화 초기에 잘못된 경로를 택할 경우 그 후에 회복하지 못하고 방향을 잃고 헤맨다는 현상이 포착됨

Introduction

  • 최신 LLM(예: ChatGPT, Gemini, Claude 등)은 다중 턴 대화가 가능한 인터페이스임
  • 사용자가 처음부터 모든 요구를 명확하게 기술하지 않아도, 반복적인 질의응답(underspecified → refined)으로 점진적으로 요구를 구체화할 수 있음
  • 실제 많은 사용자는 대화 초반에 불명확한 요구를 제시함에도, 대부분의 평가는 싱글 턴 완전 명세 환경에서만 진행됨
  • 일부 선행 연구는 다중 턴 평가를 시도하지만, 대화의 각 턴을 개별적인 에피소드로 취급하는 경우가 많으므로 실제 인간 대화에서 흔한 불명확성의 영향을 과소평가함
  • 본 연구는 이 간극을 좁히고자, sharded simulation(정보를 여러 조각으로 나눠 각 턴마다 한 조각씩만 공개)이라는 환경을 제안해 다중 턴, 불명확 지시 상황을 정밀하게 시뮬레이션함

주요 연구 결과 요약

  • 싱글 턴에서 LLM이 전체 지시를 한 번에 받을 때 90%의 성능을 보였으나, 다중 턴 불명확 지시에선 65%로 하락(평균 25포인트 감소)
  • 이 현상은 단 두 번의 대화(turn) 만 거쳐도 나타나며, 개방형·폐쇄형·대형·소형 모든 LLM에서 공통적으로 관찰됨
  • 성능 저하의 원인 분석 결과, (1) 적성 감소(aptitude loss)와 (2) 신뢰성(unreliability) 급증임
    • 싱글 턴에선 적성 높은 모델이 신뢰성도 높게 나타났으나, 다중 턴에선 적성과 무관하게 신뢰성 낮음
    • 즉, LLM이 다중 턴 대화 중 잘못된 방향으로 접어들면 회복 불가 — 이를 “lost in conversation” 현상으로 명명함
  • 주된 원인
    • 장황한 응답 및 최종 해답 성급 시도
    • 불명확 정보에 대한 잘못된 가정
    • 이전의 잘못된 시도에 대한 과도한 의존
  • 실제 LLM 활용 현장과 모델 평가 방식 사이에 큰 간극 존재함
    • 초보 사용자일수록 초반에 불완전한 지시를 내릴 때가 많아, 이 현상이 실전 적용을 어렵게 하는 주요 원인 중 하나
  • 논문 구성 소개: 선행 연구 요약, 시뮬레이션 환경 설명, 6개 생성 작업 및 평가 지표, 15개 LLM 대규모 실험 및 결과, 그리고 실무·제품 적용 시사점 및 구체적 추천 사항 제시

Background and Related Work

  • 과거 세대 언어 모델(예: BART, GPT-2, T5)은 실제로 다중 턴 대화에 대응하지 못했기 때문에 싱글 턴 위주로 평가됨
  • ChatGPT의 등장 이후 다중 턴 평가에 관심이 높아졌고, MT-bench 등 크라우드 소싱 평가가 이루어짐
  • 하지만 대부분의 평가 체계가 에피소드성 대화(각 턴 개별 평가)에 머물러, 실제 불명확 대화의 연속성이 고려되지 않음
  • 현실에서는 “최소 노력의 원칙”에 따라 인간이 불분명하게 지시(a.k.a. underspecification)하는 일이 흔하며, LLM도 정보 부족 시 조기 결론 도출 및 적응 미비 등으로 성능 저하
  • 본 연구는 불명확성이 핵심인 실제 환경에 더 가까운 평가를 목표로 구성함

Simulating Underspecified, Multi-Turn Conversation

3.1 Sharding Process

  • 원래의 완전 명세 지시문을 여러 shard(정보 조각)로 나눔
    • 예: 한 문장에 모든 조건을 담는 대신, 각 턴에서 하나의 정보(상황 설정, 수치, 조건 등)씩만 공개
  • 첫 shard는 항상 지시의 상위 목적을 설명, 이후 shard가 추가 정보(문맥, 조건 등)를 턴마다 점진적으로 제공
  • 이 sharding 과정은 LLM(GPT-4o) 제안+검증 및 수작업 보완으로 높은 품질의 다중 턴 지시 데이터 집합 구축
  • 각 작업별로 90–120개의 sharded instruction 제작(수 시간 수작업 검수)

3.2 Simulating Sharded Conversations

  • 대화 시뮬레이션은 3자 역할: 평가 대상 LLM(assistant), 전체 shard를 아는 user simulator, 응답 분류 및 채점 시스템
  • 첫 턴: user simulator가 첫 shard만 assistant에게 전달 → assistant가 응답 → 그 전략(명확화, 질문, 정답 시도 등) 분류 및 정답 추출 → 정답 평가
  • 다음 턴: 남은 shard 중 한 개만 추가 공개하며 반복 / 각 턴마다 assistant가 자유롭게 응답
  • 대화 종료: (1) 평가자가 정답 판정하거나, (2) 더 제공할 shard가 없을 때
  • user simulator는 LLM(GPT-4o-mini)로 구현되어, 자연스러운 shard 제공 및 자동 rephrase 능력을 가짐
  • 전체 실험에서 보조 LLM의 오분류, 추출 오류는 5% 미만, assistant에 불리한 경우는 2% 미만
  • assistant에게는 해당 환경에 대한 특별한 정보 없이 디폴트 상태로 평가(실전과 유사하게 시나리오 정보를 별도로 부여하지 않음)

3.3 Simulation Types

  • FULLY-SPECIFIED (FULL): 싱글 턴에 전체 지시 제공, 베이스라인 성능 평가용
  • SHARDED: 턴마다 한 개의 정보 조각만 공개, 다중 턴 불명확 대화 본 연구의 핵심 실험
  • CONCAT: sharded instruction 전체를 한 번에 bullet-point로 제공, 지시 정보 손실만 평가
  • RECAP: sharded 대화 후 마지막에 모든 shard 요약/재제공, simple agent-like 개입 시도의 한 형태
  • SNOWBALL: 각 턴마다 새로운 shard 추가와 함께 이전에 공개한 shard 전체를 반복하여, assistant가 정보를 놓치지 않게 반복 상기(메모리 보강 실험용)

Task and Metric Selection

4.1 Task Selection

  • 총 6개 작업: 프로그래밍(Code), 데이터베이스(SQL 생성), API 함수 호출(Actions), 수학(Math), 표→텍스트(Data-to-Text), 질의응답형 요약(Summary)
    • 예시: Python 함수 작성, 자연어→SQL 질의 변환 등
  • 각 작업별로 고품질 벤치마크에서 90~120개 지시문 선별, sharding 후 수작업 검증
  • 6개 모두 프로그래밍/비프로그래밍을 망라하는 대표 성격이며, long context를 요구하는 Summary 등 다양한 시나리오 포함

4.2 Metric Selection

  • 평가지표
    • 평균 성능(P): 여러 시뮬레이션에서 얻은 평균 점수(0~100)
    • 적성(A90): 상위 10% simulation 결과 값(90th percentile, best-case)
    • 신뢰성(U90_10): 상위 90%-하위 10% 점수 차이(결과 일관성/변동성 측정)
  • 예: box-plot의 맨 위가 적성, 위-아래 범위가 신뢰성임
  • 6개 작업 모두 일관성 있는 척도로 점수 집계(정답 여부/유사성/BLEU 등)
  • 모든 실험 파라미터, 예시, 샘플링 등에 대한 자세한 방법 및 코드도 부록/Appendix에 수록

Simulation Scale and Parameters

  • 총 600개 instruction을 6개 작업에 대해 구축, FULL/CONCAT/SHARDED 시나리오 실험
  • 15개의 LLM(GPT-4, Claude, Gemini 등)에 대해 각 조합별 10번씩 시뮬레이션, 20만 회 이상 실험 데이터 생성
  • 모든 실험은 temperature 1(샘플링)로 진행, 추가 실험(7.2)에서는 temperature의 효과도 분석
  • 이 거대한 시뮬레이션 데이터로 LLM의 다중 턴 underspecified 대화 내 행동 양상 및 성능 저하의 주요 원인과 유형 파악 가능

Lost in Conversation Experiment

  • 이후 본문에서는 실험 세팅, 개별 모델 결과, 성능 저하 원인 분석, 보완 기법(RECAP/SNOWBALL) 시도, 실무적 시사점·구체적 권고 순으로 상세 설명함
▲
GN⁺ 7일전  [-]
Hacker News 의견

  • 실제로 LLM 도구를 사용해 본 사람이라면 누구나 경험적으로 알고 있는 내용을 확인해 주는 논문을 보게 되어 기쁨. 대화라는 개념이 제품 인터페이스에서 만들어진 것. 컨텍스트를 깨끗하게 유지하는 것이 중요. 컨텍스트가 오염되면 복구되지 않으므로 새로운 대화로 다시 시작해야 함

    • 내 경험도 이런 관찰과는 비슷하지만, 다소 다른 점도 있었음. 2주 동안 Gemini로 IPSEC 문제를 디버깅했음. 처음에는 OPNsense와 pfSense의 IPSEC 문서를 읽어 들이고 전반적 컨텍스트를 제공함. 이후 설정 정보를 공유하고, 질문·답변을 지속함. 마지막에는 LLM이 산만해지는 일이 줄어들었고, 때로 포럼 글이나 SO 포스팅을 넣었지만 LLM이 “이건 지금 보는 현상과 다르다”고 언급하기도 했음. 모든 막다른 길을 논리적으로 배제했고, LLM이 반성은 도와주지만 결정은 인간이 해야 했음. 최종적으로 문제의 원인을 찾았고, 다른 사용자들이 말한 것처럼 LLM은 복잡한 정보를 단순화하는 데 강점이 있지만 단순한 개념을 복잡하게 확장하는 데는 약함. 입력이 출력보다 더 복잡하거나 길 때 결과에 만족스러움. LLM 없이도 할 수 있었지만 맥락을 기억하거나 빠르게 재현하지 못했던 사실을 저장해주는 점이 유용했음. 대량의 로그에서 시간 패턴을 찾는 데에도 도움됨. 여러 설정도 개선함. 문제 해결뿐만 아니라 많은 것을 배움. 상태 파악이 가끔 틀렸지만 직접 바로잡기 쉬웠음. 즉, 목표를 알고 도구로 활용하면 유용하지만, 결정을 넘기거나 잘못된 방향으로 끌려가면 효과 없음. 35만 토큰(약 30만 단어) 사용함. 관련 블로그 포스트 있음. wireguard 추천은 필요 없음
    • 경험이 완전히 일치함. “오염됨”이라는 표현이 딱 맞음. 무언가 잘못되면 이후 모든 답변이 나빠지기 시작함. 그래서 ChatGPT의 memory 기능이 마음에 안 듦. 커다란 문제는 없지만 맥락 오염이 어떻게 일어나는지 완전히 이해하지 못해 불안함
    • 내가 알려주는 최고의 팁은 ChatGPT와 Claude의 아주 작고 숨어 있는 “편집” 버튼을 적극 활용하라는 것. 나쁜 답변이 나오면 그대로 넘어가지 말고, 멈춰서 수정한 뒤 더 나은 답변을 얻으라는 것. 그렇지 않으면 엉망이 계속 증식함
    • 항상 대화를 포크해서 다양한 방향으로 실험해 보고 싶은 마음이 있음. 유망한 흐름에 돌이킬 수 없는 오염이 발생하는 것을 막고 싶음. ChatGPT에서 이 기능을 못 쓰고 있는데, 혹시 이걸 제공하는 서비스가 있는지 궁금함
    • 이 문제의 흥미로운 예시가 바로 초기 프롬프트. 사실상 영구적이고 숨겨진 컨텍스트. 트위터의 Grok 봇이 최근 “White Genocide”를 자주 언급하는데, 이는 누군가 해당 주제에 부합하도록 프롬프트를 변경했기 때문. 완벽한 챗봇이라면 다른 주제에서 영향을 받지 않아야 하는데 실제론 영향을 받음. 결국 맥락이 바뀌었고, 그 주제에 끊임없이 집착함
    • 그래서 FileKitty를 만들었음. 여러 소스코드 파일을 빠르게 마크다운 형식으로 합치는 도구. LLM에 소프트웨어 개발을 지원받을 때 코드베이스 검색을 LLM에 의존하면 오류 가능성이 커짐. 맥락 압축이라는 손실로 인해 결과물이 희석되기도 함. 특정 컨텍스트를 처음부터 명확히 하고 대화 중간중간 갱신해야 가장 좋은 결과를 얻을 수 있음. 그럼에도 대화 길이에 신경 써야 함. 콘텍스트를 잘 캡처하고 새 세션에 전달하는 프롬프트도 있음. 포함해야 할 파일을 골라 새 프롬프트에 넣기도 함. 관련 논의는 HN의 다른 스레드에서도 참고 가능함
    • 이젠 내 작업 흐름 자체에 이런 패턴이 자리 잡음. 가끔 “좋은 진행, 다음 단계로 넘어가고 싶은데, 이 대화에서 계속할 만한지 아니면 새로 시작해야 하는지?”로 LLM에게 요청함. 모델이 새로 시작하는 게 낫다고 하면 좋은 요약 프롬프트를 준비해주고, 계속해도 괜찮다고 답하기도 함. "앞으로 탐색할 초깃값 모음"이라는 노트를 여럿 만들어 둠. RL 기반 post-training 과정 등 챗봇이 계속 대화를 이어가려는 경향이 있음. RL에서 post-training은 실제 RL과 달리 1회 선호 기반 메커니즘만 사용함. 장기 프리퍼런스나 대화는 계산 복잡성이 기하급수로 증가해 연구가 많지 않음
    • 혹시 대화 기록을 “정리”하는 인터페이스가 구현된 사례가 있나 궁금함. 대화 내에서 죽은 경로나 관련 없는 내용을 정리하는 기능. 전체 내역은 유지하지만, 주제 경로에 따라 불필요한 부분만 가지치기/정돈. 요약이라기보단 유기적으로 정돈됨
    • LLM을 자동완성 용도로만 쓰지만, LLM 채팅 UI에 “메시지 삭제” 버튼이나 옵션을 추가하면 이 문제를 해결할 수 있을 거라 생각함. 마지막 LLM 메시지를 삭제하면 새 답변을 얻을 수 있음. 임의성 높은(temperature) LLM에서 특히 유용. 다른 메시지를 삭제했을 때는 이후 답변에 반영될 수 있도록 맥락을 갱신. 이를 통해 사용자가 LLM이 지능적이라고 착각하는 것도 바로잡을 수 있음. 이미 표준인지 익숙하지 않음. 만약 아니면 이 아이디어를 공개 도메인에 둠. 또 한편으론 “서브컨텍스트 LLM”을 두어서 주 맥락을 관리하는 것도 실용적. 즉, 응답이 너무 길거나 방대한 경우 하위 LLM이 요약/정돈해 전체 대화의 맥락을 다듬는 구조. 또는 단순하게 “메시지 편집” 버튼을 두어 사람이 직접 정리해도 됨
    • 맥락이 오염되면 복구가 어려움. LLM에 특정 부분만 주기적으로 리셋하거나 정화할 수 있다면 개선될 수 있음. 다만 어떤 부분을 정리할지, 핵심 정보를 잃지 않을지가 과제. 더 스마트한 맥락 관리가 길어진 대화의 일관성 유지에 도움이 될 수 있으나 균형 잡기가 어려움. 어쩌면 다른 에이전트가 이를 자동화할 수 있음
    • AI 챗봇에서 chain-of-thought 방식 프롬프트도 동일한 이유로 한계가 드러남
    • “대화”가 오직 프로덕트 인터페이스의 산물이라는 점에 대한 의견. RL의 멀티턴 평가 데이터셋 학습으로 이 부분 흐름이 달라졌음. 컨텍스트 창은 매번 새로워지지만 각 프롬프트를 더 긴 대화의 일부로 해석하는 경향이 늘어남. 공개적으로는 멀티턴 포스트트레이닝이 아직 확장되지 않았으나, 장기적으로 더 많은 목표 달성을 위해 도입될 것 같음
    • 코딩을 할 때도 대화 없이 자주 새 대화를 시작하고 현재 코드를 갖고 다시 설명하는 식으로 접근함. 이는 한 대화에서 계속 두드리는 것보다 더 좋은 결과로 이어질 때가 많음. 수동 명령을 통해 요약과 망각을 모델에 명시하면 문제를 풀 수 있을 듯. 이는 인간의 작동 메커니즘(작업 기억 vs 내러티브/일화 기억)과도 일부 일치함
    • ChatGPT의 가장 답답한 기능 중 하나가 “메모리”. 대화 오염이 채팅 간에도 따라다닐 수 있음
    • “오염됨”은 정말 적확한 용어. 대화/API에서 “버전 관리”를 도입해 예전 상태로 롤백하거나 새 대화로 복제하는 기능이 있었으면 함. 심지어 오타나 메시지 수정도 이후 응답 결과에 미묘한 편향을 준다는 점 때문에 더욱 그러함
    • zed의 채팅 UX를 정말 좋아함. 전체 대화 기록을 텍스트 파일처럼 편집할 수 있어 원하지 않는 부분을 정리, 삭제, 수정보완 후 훨씬 깔끔하고 관련 있는 맥락으로 대화를 이어갈 수 있음. 그래서 zed를 프로그래밍 외 일에도 LLM 대화용 주요 인터페이스 중 하나로 씀
    • 오염은 엉뚱한 질문이나 답변, 거듭된 “희석”을 통해서도 발생함. 콘텐츠를 생성할 때도 처음엔 명확했던 지시가 점점 흐트러지는 것을 자주 경험함
    • “대화란 오직 제품 인터페이스의 산물”이라는 점을 늘 염두에 두려 하지만 실전에서는 다양한 “대화체” 단서 때문에 쉽지 않음
    • 메모리를 켜 둔 걸 후회했음. 쓸데없는 정보로 대화가 오염됨
    • 놀라운 점은 모델이 얼마나 초기에 잘못된 가정을 하면서 고착화되는지
    • 사람도 생각해보면 이런 일 많이 벌어짐
    • 이제 ChatGPT가 “메모리”를 통해 예전 대화에도 접근할 수 있기 때문에 오염이 영구적일 수 있음. 한 번 잘못된 아이디어를 잡으면, 사용자 입장에서 절대 다시 언급하지 말라고 몇 번을 강조해도 그걸 계속 답변에 집어넣는 일이 반복됨. 내부 프롬프트(“사용자가 매우 불만임, xyz를 빼야 함”)까지 실수로 출력되어서 결국 xyz만 집중적으로 언급하는 웃긴 상황이 발생함

  • 이건 LLM이 잘 알려진 과신 경향, 자기반성의 부재, 더 많은 정보를 요청해야 할 때 그걸 인식하지 못하는 것에서 비롯된 현상. 추론 모델 결과를 보면, 혼란스러운 경우 LLM이 추가 설명을 요청하지 않고 사용자가 무슨 뜻을 원했는지 추측만 반복함. 이것은 인간 프로그래머를 대체하자는 발상의 현실적 한계를 보여줌. 진짜 어려운 부분은 모호한 요구를 명확하게 바꿔가는 “이해관계자와의 상호작용”이기 때문

    • 자기반성 불가 능력 관련, LLM엔 실제 주체가 없으며 사용자는 일종의 “믿음유지 스토리”에 빠지는 것. 대부분 영화 대본의 사용자 역할로 텍스트 입력을 남기면, LLM은 챗봇 역할로 불완전한 줄거리를 자동완성할 뿐. 예를 들어 드라큘라봇과의 인터뷰는 자기반성을 “피를 갈구”하거나 “박쥐 구름이 되는 것”처럼 표면적으로만 흉내냄
    • LLM이 정보가 애매한 오픈엔드 문제 상황(특히 패러독스)에서 명확하게 추가 설명을 요청하지 못하는 점에 동일하게 실망함. DeepSeek-R1과 Claude-3.7-Sonnet에서 테스트했고, 관련 실험 블로그도 있음
    • Gemini 2.5 Pro와 ChatGPT-o3는 종종 작업을 실행하기 전에 추가 정보를 요청함. Gemini는 여러 옵션도 제시하면서 내 입력을 요구하기도 함
    • 진짜 프로그래머들은 실제로 대부분의 시간을 요구 사항을 명확히 파악하는 데 씀. LLM은 아직도 추측 그 자체를 하나의 기능으로 취급함
    • 아이러니하게도 초보 개발자와 일할 때도 비슷함. 작업을 맡기면, 오로지 직진하며 가정만 하고 아무 질문 없이, 결국 구조대가 가서 꺼내야 할 만큼 깊은 숲에 스스로 빠지는 일이 다반사
    • 이것은 꽤 쉽게 바꿀 수 있다고 생각함. chain of thought 프롬프트 방식이 마지막 토큰을 “흠”으로 바꾸듯이, LLM이 “아마도 ~일 것 같다”는 식으로 말 나오면 “먼저 추가적으로 설명을 요청하겠다”로 토큰을 바꾸면 됨
    • 추가 정보 요청이나 자기반성도 요청만 하면 충분히 잘할 수 있음

  • LLM에게 지금까지 논의 내용을 간결한 프롬프트 형식으로 요약하게 한 뒤 직접 수정·편집해서 새로운 대화를 시작하는 기법을 즐겨 사용함. 이 방법이 꽤 효과적이었는데, 머지 않아 자동화될 거라 생각함

    • Cursor는 이걸 자동으로 시도했는데, (대형 맥락 모델을 쓰지 않는 한) 요약된 내용이 디테일을 너무 많이 놓쳐 실전엔 별로였음
    • Claude Code엔 /compact 명령이 있어 대화를 요약해 토큰 사용량을 줄여줌

  • TSCE(Two-Step Contextual Enrichment)를 직접 고안함. GPT-35-turbo에서 300개의 과제에 활용 시 성능이 +30pp 향상됨. 오픈 프레임워크로 자유 이용 가능함. gpt-4.1로 300회 추가 실험했음. baseline은 em-dash 제거를 149/300번 실패, TSCE는 18/300번 실패. 전체 데이터와 스크립트도 공개함

    • 단순한 find and replace 작업에 킬로와트시가 낭비됨. text.replace("—", "-") 같은 걸 써봤는지 궁금함
    • baseline 프롬프트를 조금만 바꿔도 GPT-4.1에서 100% 성공률을 얻었음. 추가 호출이나 토큰 지출, 복잡한 테크닉 없이도 가능함

  • 두 시스템(LMM + 자동 curator)으로 고민을 푼 경험이 있음. 하나는 LLM 자체, 다른 하나는 ‘사고의 큐레이터’로 맥락 일부분을 유동적으로 교체 관리함. 명확한 규칙이 아닌 LLM의 채우기 능력에 기반. 문제를 작게 분할해 처리하도록 돕고, 이 결과가 모여 최종 목표를 달성함

    • 멋진 아이디어. 현재 하는 일은 대화 RAG와 유사해 보임. 미래엔 메모리 계층 구분(트레이닝 데이터 / 현재 컨텍스트 / RAG)이 더 명확해질 것
    • 흥미로운 아이디어라 생각. 간단하게라도 세계에 공유하면 많은 사람들이 개선하면서 커뮤니티가 스스로 키워나갈 수 있음
    • 이는 Emotion Machine에서 말하는 내적 비평 시스템과 유사함
    • 만드는 프로젝트에 대해 더 많은 정보를 알 수 있으면 좋겠음. 흥미로워 보임
    • 그래서 결과적으로 Map-Reduce-of-Thought라고 할 만함

  • 메인 챗도구에서 브랜칭/포킹이 기본이 아니라는 게 신기함. 답변을 편집할 순 있긴 한데, 이 경우 다른 맥락이 많이 사라짐. 내 작업 흐름은 1. 계획 2. 빌드 3. 브랜치 4. 반복. 프롬프트 가지치기/브랜칭이 LLM 활용의 핵심 도구가 되어야 한다고 생각함

    • Google AI Studio에는 적어도 이 기능이 있음. 하지만 구현이 혼란스러웠고, 이게 더 많이 보급되지 않은 이유일 수도 있다고 생각함
    • 예전부터 직접 이런 걸 만들고 싶었음. BetterChatGPT는 최소한 이력 삭제 인터페이스가 좋지만 나도 브랜칭이 다음 단계라고 봄

  • LLM 인터페이스가 단일 턴 대화 중심으로 설계되면 문제가 생김. 대부분의 사용자는 선형 대화를 기대함. 그래서 Telegram 봇 experai_bot을 만들어 LLM의 유니버설 UI로 삼았고 “답장이 아니면 새 대화”라는 접근을 사용함. 맥락을 유지하려면 꼭 답장 트리 구조로 이어나가야 함. 비전문가들은 이 방식을 이해하는 데 어려움을 느낌. 또 OpenAI 모델(3.5, 4o 기준)이 같은 질문을 반복할수록 공백이나 옵션이 짧아지면서 점점 결과가 부정확해짐. 시스템 메시지를 최소화해야 비교적 결과가 유지됨. 필요하면 옵션으로 시스템 메시지 추가 가능

  • promptdown을 만든 주 이유가 전체 채팅 이력을 턴마다 완전히 편집할 수 있게 하려는 것. 표준 인터페이스의 ‘append-only’ 구조는 이런 것을 어렵게 함

  • 현 시점 LLM 분야는 모두가 똑같은 문제를 반복해서 풀고 있는 느낌

    • 멀티턴 대화에서의 LLM처럼 모두가 같은 문제를 반복하고 있음
    • “학습”이 아닌 “고양이 몰이” 현상이지만 일부 작업 흐름엔 이게 적합함
    • 모두가 자신만의 프롬프트 엔지니어링 실력을 뽐내고 싶어함

  • LLM은 정말 병 속의 지니 같음. 세 번 질문엔 답해 주지만 그 이후부턴 엉뚱한 소리만 하는 현상

답변달기