▲

LLM은 위임할 때 문서를 훼손한다

 (arxiv.org)
1P by GN⁺ 16시간전 | ★ favorite | 댓글 1개
  • DELEGATE-52는 사용자가 LLM에 긴 문서 편집 작업을 맡기는 위임형 워크플로에서 문서가 얼마나 충실히 유지되는지 평가하는 벤치마크임
  • 이 벤치마크는 코딩, 결정학, 악보 표기 등 52개 전문 영역에서 깊이 있는 문서 편집이 필요한 작업을 다루며, 예시 시뮬레이션은 20개의 연속 작업 위임으로 구성됨
  • 19개 LLM 실험에서 Gemini 3.1 Pro, Claude 4.6 Opus, GPT 5.4 같은 프런티어 모델도 긴 워크플로가 끝날 때 평균적으로 문서 내용의 25% 를 훼손함
  • 문서 훼손은 드물지만 심각한 오류로 나타나며, 문서 크기, 상호작용 길이, 방해 파일이 늘어날수록 열화가 커지고 에이전트형 도구 사용도 성능을 개선하지 못함
  • 현재 LLM은 위임형 문서 편집에서 신뢰할 수 있는 대리자로 보기 어렵고, microsoft/DELEGATE52와 datasets/microsoft/DELEGATE52가 DELEGATE-52 관련 자료로 공개됨

위임형 편집의 실패 양상

  • 위임형 업무는 사용자가 작업을 LLM에 맡기고, LLM이 문서에 오류를 넣지 않고 작업을 수행할 것이라는 신뢰를 전제로 함
  • 19개 LLM을 대상으로 한 대규모 실험에서 현재 모델들은 위임 과정에서 문서를 열화시킴
  • 다른 모델들은 프런티어 모델보다 더 심각하게 실패함
  • 문서 훼손은 긴 상호작용 동안 누적되어 문서를 조용히 망가뜨림

예시로 제시된 문서 변화

  • Graph Diagrams 영역의 Linux Kernel Architecture 문서는 Gemini 3.1 Pro에서 원본 대비 4회 후 79%, 10회 후 49%, 14회 후 48%, 20회 후 48% 수준으로 표시됨
  • Textile Patterns 영역의 12-Shaft Twill Diamond 문서는 Claude 4.6 Opus에서 원본 대비 4회 후 100%, 10회 후 40%, 14회 후 27%, 20회 후 34% 수준으로 표시됨
  • 3D Objects 영역의 ActionBoy Palm Tree 문서는 GPT-5.2에서 원본 대비 4회 후 100%, 10회 후 31%, 14회 후 15%, 20회 후 6% 수준으로 표시됨

공개 자료

  • microsoft/DELEGATE52
  • datasets/microsoft/DELEGATE52

함께 보면 좋은 글 β

▲
GN⁺ 16시간전  [-]
Hacker News 의견들

  • 도구 사용 결과에 대해서는 의심스러움

    긴 내용을 LLM에 왕복으로 통과시키면 손상되는 건 놀랍지 않음. LLM을 자주 쓰는 사람들은 이미 그렇게 하면 안 된다는 걸 알고 있음

    논문에서는 도구 사용이 도움이 안 됐다고 해서 놀랐는데, 동시에 “기본적인 에이전트 하네스”를 구현했고 최신식으로 최적화된 시스템은 아니라고 밝힘

    실제 하네스는 read_file()과 write_file()뿐이라, 그냥 왕복 처리에 한 단계가 추가된 것에 가까움. 요즘 코딩 에이전트 하네스는 파일 편집 도구 설계에 많은 공을 들이고, 예를 들어 Claude 편집 도구 묶음이 있음: https://platform.claude.com/docs/en/agents-and-tools/tool-us...

    str_replace와 insert 명령은 전체 파일을 다시 쓰는 위험한 편집을 피하는 데 핵심임

    최소한 run_python() 도구는 제공하므로, 더 나은 모델들은 이를 이용해 문자열 치환을 실행했을 가능성은 있음. 시스템 프롬프트가 Python 기반 조작을 권장했는지, 아니면 파일을 읽고 다시 쓰도록 유도했는지 보고 싶음

    하네스 코드는 여기서 찾음: https://github.com/microsoft/delegate52/blob/main/model_agen...

    관련 프롬프트 조각은 “프로그래밍 방식이든 직접 파일을 쓰는 방식이든 가장 효과적이라고 생각하는 방식으로 접근할 수 있다”는 내용임

    이런 논문들이 흔히 그렇듯, 결과는 모델 자체보다 논문 저자들이 사용한 하네스 설계를 더 많이 반영함. 경험 있는 AI 엔지니어든 프롬프트 엔지니어든, 하네스 자체를 반복 개선하면 이 테스트에서 더 나은 결과를 낼 수 있다고 봄

    • 대부분 동의하지만 “LLM을 자주 쓰는 사람들은 이미 그렇게 하면 안 된다는 걸 알고 있다”는 부분은 예외임

      지금 조직과 팀 전반에 LLM 도입이 밀려오는 상황에서, 매일 LLM을 쓰지만 하네스처럼 기술적인 것에는 접근해 본 적도 없는 사람이 많고, 어쩌면 다수일 수도 있음

      그런 사람들에게 여기서 말하는 동작은 큰 문제임

    • 약간 관련된 얘기지만, ed를 기본 파일 편집/읽기 도구로 쓰는 하네스를 보고 싶음. Claude가 실행하는 bash의 절반은 어차피 sed처럼 보이는데, ed에 상태가 유지되면 도움이 될 것 같음

      전체 편집기가 너무 많은 대역폭^H 토큰을 먹을 때는 어떻게 해야 하나? 표준 편집기인 ed를 쓰면 됨

    • 이건 LLM 작업을 약간 허수아비로 만든 사례에 가까움

      편집 작업에서는 프로그래밍 방식의 편집 명령만 허용해야 하고, 텍스트가 LLM을 통과하면 안 됨. LLM은 텍스트를 분석하고, 피드백에 따라 목표를 달성할 명령을 내보내야 함

    • HN에서는 결과를 가능한 한 부정적으로 해석하려는 경향이 있음. 자기 직업과 정체성에 대한 위협으로 느끼기 때문임

      사실 문서를 읽은 뒤 수정 사항을 반영해 문서 전체를 다시 말하게 하는 방식으로 편집하려면, 사람은 25% 열화보다 더 나쁜 결과를 낼 수 있음. 사람이 0% 열화를 달성하는 것도 가능하긴 하지만, 그 상태는 문서를 수백 번 입력받아 암기해야 가능함. LLM에서 이에 해당하는 건 학습이고, 문서를 LLM에 학습시키면 이 경우 암기한 사람의 편집과 동등해질 수 있음

      하지만 위 내용은 핵심이 아님. LLM은 사람과 비슷한 점이 있으므로, 사람이 문서를 편집하는 방식처럼 LLM도 검색과 외과적 수정으로 편집하도록 하네스를 설계해야 함. 모든 코딩 에이전트는 그렇게 편집하므로, 이 논문은 별로 관련성이 없음

    • 자원 제약 때문이든 단순화를 위해서든, 이해하기 어려운 방법론 때문에 이런 논문들은 안타깝게도 가치가 떨어짐

  • 예전부터 말해 왔듯이, 어떤 텍스트든 AI로 덧칠하면 품질이 떨어지고, 반복할수록 누적됨

    이걸 부르는 말로는 “의미 절제(semantic ablation)”가 제일 마음에 듦: https://www.theregister.com/software/2026/02/16/semantic-abl...

    • 나는 이걸 평균 지능으로의 회귀라고 불러 왔음
    • “반복할수록”이라는 게 같은 세션 안에서 반복한다는 뜻인지, 매번 새 세션이나 새 문맥 창에서 한다는 뜻인지 궁금함

  • “위임에는 신뢰가 필요하다. LLM이 문서에 오류를 넣지 않고 작업을 충실히 수행할 것이라는 기대가 있어야 한다”는 요지인데, 이게 바로 수십 개의 Markdown 파일을 쓰는 하네스와 프롬프트 의식이 광고처럼 작동하지 않는 이유임. 사실상 에이전트 엔지니어링이라는 이름의 사이비에 가까움

    에이전트 엔지니어링도 결국 소위 프롬프트 엔지니어링과 거의 같고, 다만 프롬프트가 이제 수십 개의 Markdown 파일과 디렉터리에 흩어져 있을 뿐임

  • 최근 LLM 관련해서 읽은 것 중 가장 덜 놀라운 내용임

    LLM은 JPEG 밈과 비슷함. JPEG로 저장할 때마다 품질이 조금씩 떨어져 마지막에는 알아볼 수 없게 되는 것처럼 작동함

    다만 LLM에서 시작점은 의도임. LLM을 한 번 통과할 때마다 의도가 열화되고, 정밀한 과학 논문 같은 경우에는 다시 표현하는 과정에서 미묘한 뉘앙스와 정밀도가 조금씩 사라짐

    LLM은 평균으로 회귀하는 기계임. 현재 다루는 문맥이나 작업 부하가 학습 범위에서 벗어날수록, 그것을 점점 더 균질한 추상적 평형 상태로 끌어당기려는 경향이 커짐

    • LLM으로 코딩하면서 확실히 겪어 봄. 기능 작업을 빠르게 몰아서 하고 나서는 꽤 조심했다고 생각했는데, 나중에 작은 코드 조각을 자세히 보면 “맙소사” 싶은 순간이 자주 있음

      그 뒤 몇 시간을 들여 전체를 다시 훑고, 원하는 대로 되지 않은 부분, 내가 불명확했던 부분, LLM의 이상한 습성이 발동한 부분을 신중히 고쳐야 함

      코드 품질 자체도 중요하지만, 정확히 이런 반복 압축 문제가 걱정됨. 코드베이스가 깨끗하고 머릿속 모델이 최신이면 LLM이 기능 작업을 빠르게 도와주고도 코드베이스를 괜찮은 상태로 남길 수 있음. 하지만 LLM이 코드베이스를 더럽히기 시작하면 과거의 실수나 오해가 누적되고, 점점 더 많은 것을 틀릴 가능성이 커짐. 그래서 LLM을 다시 쓰기 전에 올바른 상태로 “복원”해야 안심됨

    • 이 결과가 실제로 흥미롭고 관련 있는 경우는 코딩 에이전트가 큰 소스 파일을 여러 작은 파일로 쪼갤 때임. Opus와 Claude Code는 사람이 하듯 복사/붙여넣기 같은 조작을 쓰는 대신, 긴 소스 코드 구간을 기억에서 암송해 새 파일들에 넣으려 함

      파일 이동은 조금 쉬움. LLM이 가끔 파일을 기억에서 다시 말하려 하기도 하지만, git mv를 쓰고 컴파일러 오류를 고치라고 하면 대체로 잘함

      반면 일반적인 편집은 합리적인 모델과 도구 구성이 있으면 보통 잘 작동함. Qwen3.6 27B도 이 정도는 괜찮음. 제자리 수정은 git diff로 예상 밖 변경을 검토할 수도 있음

    • 이걸 보여주는 어린이 놀이도 있음: https://en.wikipedia.org/wiki/Telephone_game

    • 동료는 LLM을 “헛소리 층”이라고 표현함. 완전히 깎아내리는 뜻은 아니고, 무언가를 LLM에 통과시킬 때마다 반대편에서 나오는 결과가 기대하거나 원하는 것과 다를 수 있다는 점을 강조하는 말임

      술집에서 몇 잔 마신 사람이 어디서 봤다는 온라인 정보를 전해 주는 것과 비슷함. 맞을 수도 있지만, 아닐 위험도 꽤 큼

      예를 들어 API를 호출해 데이터를 모으고 보고서를 만들 때 LLM을 쓰지 말아야 함. 결정적인 데이터를 헛소리 층에 통과시키는 셈이라 결과를 신뢰할 수 없기 때문임. 대신 LLM은 결정적인 데이터에서 결정적인 출력을 만드는 코드를 작성하는 데 쓰는 편이 나음

      동료들이 API에서 온 결정적인 데이터를 LLM으로 요약하게 했다가, 보고서가 맞을 때만큼이나 크게 빗나가는 것도 봤음. 무엇을 보고 있느냐에 따라 재앙적인 위험이 될 수 있음

    • 이력서 편집에서 이걸 겪음. LLM은 내 이력서를 평균적인 경험을 가진 주니어 엔지니어 더미와 구분해 주는 모든 요소를 제거함. 특별하거나 독특하거나 다른 것들은 결국 전부 일반적인 문구로 대체됨

      물론 그 결과물을 쓰지는 않았지만, LLM이 계속 이게 기존 것보다 낫다고 우기는 게 정말 답답했음

      LLM은 이력서 전체의 방향을 잡는 것보다, 아주 작은 덩어리, 예를 들어 한 문장이나 세 문장 정도의 수정 제안을 받을 때 훨씬 유용했음

  • 문제는 우리가 LLM에게 너무 많은 일을 시킨다는 데 있음. 에이전트는 LLM을 자연어 의도를 결정적 과정으로 번역하는 가능한 한 얇은 층으로 쓰도록 설계해야 하고, LLM 왕복을 최대한 줄여야 함

    • 조금만 복잡한 일을 해 보려는 사람이라면 이게 분명해짐. 전처리 흐름, 의미 기반 대상 지정, 최소한의 문맥 호출을 LLM API와 결합하는 파이프라인을 만들면 강력한 자동화 단계를 얻을 수 있음

      별도의 검증 단계와 결합하면 LLM은 장난감에서 유용한 도구로 바뀜

    • 사람도 요정도 반복 과정에 들어 있지 않아야 비로소 자동화된 과정임

  • 보통 에이전트에게 문서 작성은 마지막 렌더링 단계로만 다루라고 지시함. LLM은 흩어진 지식을 모아 엮는 데 매우 능숙하므로, 지식은 조합 가능한 아이디어와 사실 형태로 저장하는 편을 선호함

    실제로 잘 먹힌 방식은 에이전트에게 디렉터리를 주고, 찾아낸 사실이나 발견마다 독립적인 Markdown 파일을 만들라고 하는 것임. 각 파일에는 검색하기 쉽게 앞부분 메타데이터를 넣게 함

    이렇게 하면 대부분의 작업이 “최종 문서 형식으로 조사와 저장을 반복”하는 뒤엉킨 형태에서, “문서에 도움이 될 사실과 발견을 조사”하고 “문서를 조립”하는 더 응집된 작업으로 분리됨

    완전한 해결책은 아니지만, 사람이 작업할 때처럼 발견물의 재사용성이 더 좋아짐

  • 이건 사람에게도 적용되지 않나? 아이들이 “전화 놀이”를 하면서 메시지가 어떻게 손상되는지 보는 이유도 그 때문임. 해결책은 단일 진실 공급원을 제공하는 것임

  • 이런 종류의 열화와 싸우기 위한 도구를 만들고 있음: https://github.com/JigSpec/JigSpec

  • 여기 평가 방법은 정말 마음에 들었음. 가역적인 단계들의 사슬을 왕복시키면서 충실도를 테스트하는 방식임

    겉보기에는 컴퓨터가 다루기 쉬워 보이는 작업에서도 최전선 모델들이 오류를 누적한다는 점이 인상적이었음

    Python에서 더 강한 결과가 나온 것이 Python 특화 평가의 산물일 뿐인지, 다른 흔한 범용 언어에도 이어지는지, 그리고 학습 과정의 특정 요소 때문인지 궁금함

  • 모델이 수많은 작은 오류, 즉 “천 번의 베임” 때문에 실패하는 게 아니라는 점은 이미 대체로 알고 있었음. 어떤 라운드에서는 거의 완벽하게 재구성하다가, 몇몇 라운드에서 한 번에 10~30점 이상 잃는 치명적 실패를 겪음

    약한 모델의 열화는 주로 내용 삭제에서 오고, 최전선 모델의 열화는 내용 손상에서 온다는 점도 마찬가지임. 그래서 우리가 하네스, 온도 같은 것들을 이리저리 만지는 것임

답변달기