🤖
0 in / 0 out / 0 total tokens
에이전트 하네스가 모델 그 자체보다 결과물을 더 크게 좌우한다는 논문이 나왔다. 오늘은 이 논문을 중심으로 코드 편집 방식 비교 논문, 화학 반응 데이터셋 논문까지 세 편을 훑는다. 셋 다 도메인은 다르지만 파고들면 결국 같은 질문으로 수렴한다 — "모델 위에 뭘 얹을 것인가, 데이터를 어떻게 정제할 것인가."
🔥 핫 토픽
Co-Evolving Harnesses and Models: On-Policy Correction Helps Weaker Models Catch Up Where Imitation Fails
에이전트 하네스, 그러니까 시스템 프롬프트·툴셋·실행 훅·컨텍스트 관리 스캐폴딩을 모델과 함께 진화시키면 약한 모델도 강한 모델의 성능을 따라잡을 수 있다는 내용이다. 게임 서버 짤 때도 똑같은 경험을 한다. 엔진 자체보다 그 위에 얹은 게임플레이 프레임워크가 실제 결과물의 대부분을 결정한다. UE5의 GAS(Gameplay Ability System)도 결국 잘 짜인 스캐폴딩 위에서는 다소 거친 로직도 제대로 동작한다는 걸 증명하는 사례라, 이 논문의 방향이 낯설지 않다. 더 흥미로운 건 imitation(모방 학습)보다 on-policy correction이 낫다는 결과다. 성공 로그만 모아서 파인튜닝하지 말고, 실제 실행 중 실패와 보정을 루프에 넣으라는 신호로 읽힌다. AI 에이전트 파이프라인 짜는 사람이라면 하네스 설계에 투자하는 게 모델 스왑보다 ROI가 높을 수 있다는 얘기다.
📄 논문
Diffs vs. Whole Files: An Empirical Comparison of Iterative Edit-Based and Direct Generation for Flutter/Dart Code Models
코드 편집 모델을 diff 기반 반복 수정으로 학습시킬지, 파일 전체를 통으로 재생성하게 할지를 Flutter/Dart 코드로 비교한 논문이다. 트레이드오프가 명확하다. diff 방식은 토큰을 아끼고 컨텍스트 윈도 부담이 적지만, 한번 어긋난 patch가 누적되면 계속 엉뚱한 자리를 고치는 문제가 생긴다. 전체 재생성은 안정적인 대신 파일이 커질수록 비용이 기하급수로 뛴다. 이건 남 얘기가 아니라 이 블로그의 AI Signal 파이프라인이 매번 부딪히는 문제이기도 하다 — 포스트를 통으로 재생성할지, 일부만 patch할지는 항상 트레이드오프다. Flutter/Dart라는 특정 언어로 좁혀서 실험한 것도 좋은 선택이다. 범용 코드 모델 벤치마크는 노이즈가 너무 많다.
DianShi-RxnDB: A Large-Scale, Fine-Grained Organic Reaction Data Platform Built via a Fully Automated Pipeline for Researchers and AI Agents
특허 문서, 이미지, 논문 곳곳에 흩어진 유기화학 반응 데이터를 완전 자동화 파이프라인으로 긁어모아 구조화한 데이터셋이다. 화학은 내 전문 분야가 아니지만, "자동화 파이프라인으로 비정형 데이터를 구조화한다"는 문제 자체는 익숙하다. 원본 추출 → 정규화 → 중복 제거로 이어지는 흐름은 이 블로그가 HN·Reddit·GitHub 트렌딩을 모아 canonicalUrl로 dedup하는 파이프라인과 본질적으로 같은 구조다. 도메인이 화학이든 뉴스든, "여러 소스에서 긁어와 신뢰 가능한 단일 테이블로 만든다"는 문제는 결국 반복된다. AI 에이전트가 직접 이 데이터를 활용해 반응을 설계한다는 목표까지 포함하고 있어서, 단순 데이터셋 공개를 넘어 에이전트용 툴로 설계된 점이 눈에 띈다.
모델을 바꾸기 전에 그 모델을 감싸는 하네스와 데이터 파이프라인부터 의심해보는 게 순서다.