왜 LLM 출력을 인간 친화적으로 만드는 것이 에이전트 워크플로우에는 역효과를 내는가

인간 중심의 출력 스타일은 에이전트의 작업을 압축하고 정보를 손실시킨다

Simplified Technical English (STE) 또는 짧은 문장 프롬프트와 같은 인간 지향적 출력 형식은 모델이 내부 추론을 대역폭이 낮은 표현으로 압축하도록 강제합니다.

  • 압축은 손실적입니다: 텍스트가 여전히 매끄럽게 읽히더라도 세부 사항이 누락됩니다.
  • 에이전트는 작업을 해결하고, 추상화를 보존하며, 오류를 방지하기 위해 가장 정보 밀도가 높은 표현이 필요합니다.
  • 핵심 지침 세트의 일부로 스타일 제약을 적용하는 것은, 저장소와 디스플레이가 별개의 레이어인 전통적인 시스템과 달리, 문제 해결과 표현을 혼합합니다.

"에이전트에게 짧은 문장을 사용하고, 전문 용어를 피하며, 사용자를 압도하지 말고 가장 중요한 세부 사항만 포함하라고 말하는 것은, 출력을 지속적으로 대역폭이 낮은 형식으로 압축하도록 요청하는 것입니다. 그 압축은 손실적입니다." – kuberwastaken, Humanising LLM Outputs is Dumb

원시 에이전트 출력은 정확성과 디버깅에 필수적이다

에이전트가 하위 에이전트와 통신할 때, 각 레이어는 정확하고 기계가 읽을 수 있는 데이터를 교환해야 합니다:

5/6 PASS
FAIL: test_cache_invalidation
CAUSE: stale key survives restart
REPRO: tests/cache_test.py:184

"몇 가지 살펴볼 문제가 있지만 대부분의 테스트를 통과했습니다"와 같은 인간 친화적인 요약은 자동화된 복구에 필요한 정확한 실패 정보를 숨깁니다.

  • 상세한 로그는 상충하는 증거, 해결되지 않은 분기, 스택 트레이스 및 불확실한 가정을 노출합니다.
  • 인간의 산문은 이러한 신호들을 매끄럽게 다듬는 경향이 있어, 환각(hallucination)이나 미세한 버그를 감지하기 어렵게 만듭니다.

기존 시스템 설계 패턴은 경계까지 충실도를 유지한다

  • Databases는 원시 행을 저장하고, 대시보드는 사용자를 위해 이를 형식화합니다.
  • Compilers는 인간이 소비하기 위한 것이 아닌 중간 표현(IR)을 유지합니다.
  • APIs는 서사적인 요약이 아닌 구조화된 데이터를 교환합니다.

LLM 툴링은 추론 단계 도중에 인간이 읽기 쉬운 형식을 강제함으로써 이 패턴을 점점 더 뒤집고 있습니다.

접근성과 개인화는 최종 렌더링 단계에 속한다

저자는 출력을 접근 가능하게 만드는 것에 반대하는 것이 아님을 명확히 합니다:

"세 줄짜리 답변이나 Simplified Technical English를 원하신다면 좋습니다! 저는 단지 그것을 마지막에 하는 것이 더 낫다고 생각할 뿐입니다."

권장 사항은 에이전트의 내부 상태, 스키마, diff, 신뢰도 점수 및 출처를 온전하게 유지한 다음, 결과물을 인간이 소비할 수 있도록 한 번만 변환하는 것입니다.

트레이드오프에 대한 커뮤니티의 관점

  • Xcelerate는 긴 LLM 출력 후에 개인적인 용도로 "LLM 말투를 압축 해제"하기 위한 두 번째 패스를 프롬프트하여, 미래의 에이전트를 위해 원시 출력을 보존한다고 언급합니다.
  • 7402는 간결하고 사실적인 답변을 목표로 친절함과 1인칭 언어를 억제하는 프롬프트를 공유합니다.
  • Animats는 스타일을 강제하는 것이 단순히 정보를 누락시키는 것뿐만 아니라 환각을 유발할 수 있다고 경고합니다.
  • firefoxd는 로봇 명령처럼 구성된 검색 쿼리가 더 나은 결과를 냈었지만, AI 생성 개요가 그 힘을 약화시켰다고 관찰합니다.
  • pholden은 Claude의 출력 스타일 설정이 기본 대화에만 영향을 미치며, 하위 에이전트는 자체 시스템 프롬프트를 유지하므로 스타일 유출은 제한적이라고 지적합니다.
  • boredumb는 프론트리어 모델이 기계 수준의 정밀도를 우선시하고, UI 개발자가 필요한 인간 친화적인 레이어를 구축하도록 남겨두어야 한다고 주장합니다.
  • TheCapeGreek은 많은 사용자가 코드 리뷰에서 장황한 설명을 피하기 위해 실제로 손실 압축을 원한다고 강조합니다.
  • wren6991는 LLM이 이미 내부적으로 코드 스위칭(예: chain-of-thought vs. 최종 출력)을 수행하므로, 인간을 위해 더 단순한 방언을 제공하는 것이 본질적으로 해롭지는 않다고 반박합니다.
  • virajk_31와 scotty79는 기계 최적화 출력과 사용자 친화적 렌더링 사이를 번역하는 전용 리에종(liaison) 에이전트를 제안합니다.

실질적인 권장 사항: "생각"과 "말하기" 단계를 분리하라

  1. 핵심 에이전트 출력은 원시 상태로 유지하라 – 전체 테스트 로그, 오류 트레이스, 신뢰도 메트릭 및 구조화된 diff를 보존하십시오.
  2. 후처리 단계를 정의하라 – 에이전트가 작업을 마치면, 원시 데이터를 원하는 인간 스타일(예: STE, 간결한 불렛 포인트)로 변환하는 포맷터나 보조 LLM을 호출하십시오.
  3. API를 통해 원시 데이터를 노출하라 – 다운스트림 도구나 인간 검토자가 필요할 때 필터링되지 않은 출력을 요청할 수 있도록 하십시오.
  4. 스타일을 명령이 아닌 렌더러로 취급하라 – 데이터베이스 쿼리가 행을 반환하고 UI 컴포넌트가 이를 형식화하는 것과 유사하게 처리하십시오.

이러한 분리를 준수함으로써, 개발자는 신뢰할 수 있는 자동화에 필요한 충실도를 유지하면서도 최종 사용자에게 접근 가능하고 개인화된 요약을 제공할 수 있습니다.

이 논의는 AI 툴링의 광범위한 변화를 반영합니다: 단일한 인간 중심 프롬프트에서, 기계는 정밀하고 기계 친화적인 언어로 통신하고 최종 레이어에서만 이를 인간이 읽을 수 있는 형태로 번역하는 계층형 아키텍처로 이동하고 있습니다.

Sources

관련