커뮤니티 해설난이도 보통파이토치 한국 사용자 모임 · 10월 19일(월) 공개

하네스 세 가지를 묶은 한국어 공시 에이전트: 작은 실험에서 드러난 이득과 비용

비공식 구현의 합성 공시 35문항 실험에서 근거 관리와 과제별 하네스 수정을 비교하고, 정확도 개선·약 25배 비용·작은 모델의 실패를 함께 공개했습니다.

쉽게 말하면비유하자면 신입 직원에게 메모 양식과 점검표를 주고, 일마다 선배가 그 양식을 고쳐 주는 방식이다. 직원 자체(모델)는 그대로 두고 과제마다 일하는 절차를 고쳤더니 가상 공시 35문항에서 정답이 29개에서 34개로 늘었지만, 문항당 비용은 약 25배가 됐다.

왜 봐야 하나: 모델을 다시 학습시키지 않고 프롬프트와 검증 규칙만 고쳐 문서 질의 에이전트를 다듬으려는 사람에게 참고가 된다. 숫자에 출처·단위·정정 상태를 함께 적는 설계는 살펴볼 만하다. 다만 합성 자료 35문항을 한 번 돌린 결과다.

이 글은 LongHarness·Harmony Harness·Harness²의 아이디어를 하나로 묶은 개인의 비공식 구현과 새 실험이다. 모델 가중치는 그대로 두고, 근거를 보관하는 방식과 프롬프트·도구 안내·검증 규칙을 고친다. 가상 한국 공시의 테스트 35문항에서 Claude Haiku 5.5와 Opus 5.5 편집자를 쓴 과제별 수정은 정답을29개에서34개로 늘렸지만, 비교 대상 H† 단독 실행보다 비용이 약25배였다. 탐색용 문항에서 좋아진 Harmony의 수정은 테스트 개선으로 이어지지 않았고, 작은 qwen3:4b의 한계도 남았다. 이 수치는 합성 데이터의 작은 실험 결과이며 실제 DART 정확도나 세 원논문의 재현 성능을 뜻하지 않는다.

알아낸 것

세 하네스 연구를 참고한 비공식 구현으로, 근거의 유효 상태를 관리하고 과제에 맞춰 작업 절차를 수정했습니다.
Haiku 실행기와 Opus 편집자를 쓴 합성 공시 테스트에서 29/35 정답이 34/35로 늘었지만, 문항당 비용도 약 25배 증가했습니다.
작은 로컬 실행기에서는 강한 편집자를 붙여도 성공률이 낮아, 절차 개선만으로 실행 모델의 한계가 사라지지는 않았습니다.

한계와 주의할 점

원논문 저자들과 무관한 개인의 구현·합성 데이터 실험입니다. 세 원논문의 재현이나 직접적인 성능 비교로 읽으면 안 됩니다.
실제 기업 공시가 아닌 가상 기업의 자료를 사용했고, 테스트는 35문항입니다. 개발 중 테스트 5문항을 활용했으므로 완전히 보지 못한 데이터에 대한 평가도 아닙니다.
주요 실행은 한 번의 표본이며 독립 재현은 하지 않았습니다. 34/35라는 결과를 실제 공시의 일반적인 정확도나 통계적으로 확정된 개선으로 볼 수 없습니다.
약 25배는 해당 설정의 문항당 API 비용 차이입니다. 토큰 사용량의 배수나 모든 모델에서의 운영 비용을 뜻하지 않습니다.

용어 풀이

하네스(Harness): 모델 가중치를 고정한 채 모델 바깥에서 작동하는 시스템 프롬프트, 도구 안내, 스킬, 검증 게이트, 예산 등을 통틀어 이르는 말. 이 연구에서는 하네스를 파일 묶음으로 관리하고 자동으로 진화시킨다.
근거 은행(EvidenceBank): LongHarness의 핵심 구성 요소로, 에이전트가 읽은 문서 구간에서 얻은 근거를 쌓고 각 근거에 '유효·대체됨·철회됨' 상태를 붙인다. '아직 모르는 것' 목록이 다음 검색을 이끌어 불필요한 재탐색을 줄인다.
MOEA/D: 다목적 진화 알고리즘의 하나로, 여러 목표(여기서는 정확도와 토큰 비용)를 동시에 최적화한다. Harmony가 탐색용 문항에서 하네스를 진화시킬 때 사용하며, 체비쇼프 스칼라화로 목표 간 균형을 맞춘다.
Harness²: 정답지 없이 과제마다 하네스를 개선하는 방법. 범용 편집자와 도메인 편집자가 각각 수정안을 내고, 같은 과제에 시험 실행한 뒤 행동 차이로 뒷받침되는 수정만 합친다. 배운 점은 경험 라이브러리에 저장된다.
검증 게이트(Gate): 최종 답을 받아들이기 전에 통과해야 하는 검사 규칙. 예를 들어 value_in_source는 인용한 숫자가 인용 구간에 실제로 있는지 확인하고, correction_check는 정정 전 공시를 인용했는지 검사한다. 하네스 부품으로 켜고 끌 수 있다.

더 깊이 읽기 읽는 데 약 7분

배경과 문제

긴 공시에서 숫자를 찾는 에이전트는 맞는 표를 읽고도 정정 전 수치를 쓰거나, 잠정 실적을 확정치로 착각하거나, 별도·연결 재무제표를 섞을 수 있다. 저자는 이런 문제를 모델 재학습 대신 하네스 개선으로 다룬다. 하네스는 시스템 프롬프트, 도구 안내, 조건에 따라 쓰는 스킬, 답을 확인하는 검증 게이트, 턴·토큰 예산을 포함한 모델 바깥의 실행 구성이다. 여기서는 이를 작은 파일 묶음으로 관리한다.

정답과 함정을 통제하기 위해 실제 기업 자료 대신 가상 기업16곳의 공시93건, 약60만 자를 만들었다. 질문51개는 기업 단위로 탐색용16개와 테스트용35개로 나눴고, 테스트에는11개 회사가 나온다. 정정·잠정 수치, 별도와 연결, 누적과 분기, 천원과 백만원, 비슷한 회사명 등을 함정으로 넣었다. 따라서 실패 원인을 구분하기는 쉽지만 실제 공시의 다양한 문서 품질까지 반영한 시험은 아니다.

기존 접근의 한계

상위 검색 청크를 한 번에 주는 Direct RAG에서 Haiku는35개 중11개를 맞혔다. 틀린 답24개에는 잠정 수치를 고른5개와 단위 오류8개가 포함됐다. 같은 모델에 도구와 자유 메모를 주면26개로 늘었지만 단위 오류6개 등이 남았다. 이 관측은 검색된 숫자를 답에 옮기는 단계에도 기준과 단위 확인이 필요함을 보여준다. 자유 메모가 언제나 상태를 추적할 수 없다고 입증한 실험은 아니다.

서로 보완하려는 문제도 다르다. 근거의 상태를 잊으면 이미 정정된 수치를 다시 인용하고, 탐색을 끝낼 기준이 흐리면 같은 검색을 반복한다. 정답이 있는 작은 탐색 세트에서 하네스를 고쳐도 새 문항에 통할지는 별도 문제다. 반대로 과제마다 수정안을 시험하면 새 실패에 대응할 수 있지만 실행과 편집자 호출이 늘어난다. 이 구현은 세 방법을 연결해 이득과 비용을 함께 살펴본다.

연구방법을 단계별로

먼저 LongHarness에서 가져온 근거 은행(EvidenceBank)에 읽은 구간과 유효·대체됨·철회됨 상태를 남기고, 아직 모르는 내용으로 다음 검색을 정한다. Harmony는 정답이 있는16문항에서 정확도와 토큰 비용을 MOEA/D로 함께 최적화해 하네스 H†를 고른다. 이어 Harness²가 각 테스트 과제에 범용·도메인 수정안을 내고 두 안을 시험한 뒤, 실행 기록이 뒷받침하는 수정을 합친다. 교훈은 경험 라이브러리에 쌓인다. 모델 가중치는 이 과정에서 바뀌지 않는다.

근거 상태와 검증 게이트가 세 단계를 연결한다. 정답지를 보지 않고도 인용 숫자가 읽은 구간에 있는지, 정정 전 공시인지, 어떤 검사를 통과했는지 비교할 수 있다. 다만 검사 통과가 정답 보장은 아니다. 실행 모델은 RTX2060 노트북에서 돌린 qwen3:4b와 추론 노력 low의 Haiku5.5, 주요 편집자는 medium의 Opus5.5다. 로컬 설정은 시드7을 썼지만 Claude는 시드를 고정할 수 없어 각 결과 행은 한 번의 실험 표본이다.

결과와 숫자의 의미

Haiku의 초기 H0는29/35개, 재실행은31개였다. Harmony는 탐색에서15/16개를16개로 늘리고 토큰을8% 줄였지만, 테스트는 H†도29개였다. 단위 오류4개가1개로 줄어든 대신 별도·연결 혼동2개가 생겼다. H†에 Harness²를 더하면34/35개(97.1%)로, 새 정답5개와 기존 정답 훼손0개였다. 수정은16과제에서 채택하고19개는 유지했으므로, 채택 횟수와 새 정답 수를 구분해야 한다.

H† 단독은 문항당0.0042달러, Harness²를 더하면0.1064달러로 약25배다. 토큰은32,232에서117,603으로 약3.65배였으며, Opus 편집자만35과제에3.26달러가 들었다. 편집자 비용과 전체 비용은 다르다. qwen3:4b에서는 Direct RAG2개, 자유 메모1개, H0는0개, Opus가 편집한 H†는1개, Harness²까지 붙이면5개(14.3%)였다. 그래도20문항은 답을 확정하지 못했다. 이 조건에서는 강한 편집자만으로 작은 실행 모델의 한계를 메우지 못했다.

구체적인 예시

고친 사례에는 천원 수치를 억원으로 바꾸며10배 틀린 답, 별도 표를 연결로 읽은 답, 비슷한 회사의 공시로 넘어간 답이 있다. 한 회사 혼동 사례에서는 도메인 수정안이 오히려 다른 회사의 정정 수치를 골랐다. 합성 단계는 인용 구간의 회사명이 질문과 다르다는 기록을 보고 그 안을 버리고 범용 수정안만 채택했다. 명시적 근거가 판단 자료를 제공한 예이며, 정답 없이 항상 수정의 옳고 그름을 알아낸다는 보장은 아니다.

경험 파일에는 최신 정정 공시를 이미 읽었다면 같은 확인을 반복하지 말라는 교훈이 남았다. 저자는 한 사례에서 같은 답을39k 대신21k 토큰으로 냈다고 보고한다. 불필요한 검색을 줄이는 방향을 보여주지만 경험 라이브러리만 제거한 대조 실험은 없었다. 따라서 이 한 사례를 라이브러리의 독립적 평균 절감률로 해석할 수는 없다.

한계와 오해하기 쉬운 점

테스트35개·한 표본·합성 문서라는 한계가 크다. H†를 그대로 다시 실행해도29개였고, 두 실행에서 문항별 좋은 답을 고르는 오라클 비교는30개였지만 이는 실제 배포 절차가 아니다. 이 대조가34개의 개선을 뒷받침하는 관측이어도 두 번만으로 표본 잡음을 완전히 배제하거나 유의성을 확정하지는 못한다. 개발 중 테스트 첫5문항으로 도구 버그를 찾았으므로 완전히 미노출된 평가도 아니다. 초기 프롬프트를 그 문항에 맞추지는 않았다는 것은 저자의 설명이다.

원논문의 그대로인 재현도 아니다. LongHarness의 전체 이력 대신8k 로컬 문맥에 맞춘 최근 턴 요약을 쓰며, Harmony의 기능·보안 목표를 정확도·토큰 비용으로 바꿨다. 편집은 실행 코드보다 선언형 파일과 설정에 제한된다. Haiku의 Harmony 탐색은2세대8안, qwen+Opus는1세대4안으로 예산이 다르고, Harness²는 모두k=1이다. qwen 자체 편집 실험에는 나중에 수정한 스키마 버그로 거절된 안도 하나 남아 있다. 이 결과로 세 원논문의 우열을 정할 수는 없다.

실제로 어떻게 활용할까

실제로 참고할 부분은 숫자를 저장할 때 출처 구간·회사·기간·단위와 정정 상태를 함께 다루는 설계다. 프롬프트 수정도 작은 파일 단위로 남기고, 인용값 일치나 정정 여부 같은 검증 규칙과 분리해 시험할 수 있다. 게이트가 받아들인 답과 별도 정답 채점은 구분해야 한다. qwen의 최종 답 채택률43%가 정확도14.3%보다 높았다는 점이 이를 보여준다. 로컬 실행에 API 요금이 없어도 장비·전력 비용이 사라지는 것은 아니다.

후속 검증은 아직 남아 있다. 저자는 설정마다3~5회 반복, 더 큰 탐색 세트, 중간 크기 실행 모델, k>1, 경험 라이브러리 제거 대조, 실제 DART 공시 평가를 계획했다. 비용을 줄이려면 편집자 호출을 줄이거나 쉬운 과제에 싼 편집자를 쓰는 방법도 살펴봐야 한다. 현재 글은 저장된 저자 실험과 실패 기록을 공개한 자료이며, 이 해설에서 모델을 돌려 독립 재현한 결과는 아니다.

원문에서 확인한 근거 4곳

Claude Haiku 5.5 실행 모델에서 LongHarness 초기 하네스 H0는 테스트 35문항 중 29개(82.9%)를 맞혔고, H†+Harness² 단계는 34개(97.1%)를 맞혔다.Claude Haiku 5.5 실행, Claude Opus
Harness²는 정답지 없이 5문항을 새로 맞혔고 맞던 문항을 틀리게 만들지는 않았으며, 비용이 단일 실행의 약 25배(문항당 0.1064달러)였다.Harness²는 정답지 없이 5문항을 새로 맞혔고,
qwen3:4b 실행 모델에서는 H†+Harness² 단계가 35문항 중 5개(14.3%)를 맞혔고, 35개 중 20개는 최종 답을 확정하지 못했다.qwen3:4b 실행 (로컬, 무료)
저자는 개발 중 테스트 첫5문항으로 도구 버그를 찾았으며, 초기 프롬프트를 테스트 문항에 맞춰 조정하지는 않았다고 밝혔다.테스트 첫 5문항으로 도구 버그를 찾았습니다.

출처소개 글 — 파이토치 한국 다룬 원문 다룬 원문 다룬 원문

10월 20일(화) 정리 · AI가 쓰고 원문과 대조