2P by GN⁺ 2일전 | ★ favorite | 댓글 1개
  • 코드 흐름(code-flow) 다단계 학습을 통해 정적 코드가 아닌 저장소의 변화와 개발 과정을 학습하는 코딩에 특화된 오픈 코드 LLM
  • 사전학습–미드트레이닝–포스트트레이닝으로 이어지는 진화형 학습 파이프라인을 통해 장기 추론과 에이전트 작업 성능 강화
  • 32K·128K 컨텍스트에서 추론 데이터와 에이전트 궤적을 주입해 복잡한 다중 파일·저장소 단위 문제 해결 능력 확보
  • 반복 구조를 도입한 LoopCoder 아키텍처로 모델 용량 대비 배포 효율을 개선하는 실용적 설계 제안
  • SWE-Bench, LiveCodeBench, Terminal-Bench 등에서 상용 모델과 경쟁 가능한 성능을 오픈 가중치 모델로 달성

개요

  • IQuest-Coder-V1은 7B·14B·40B·40B-Loop로 구성된 코드 전용 대형 언어 모델 계열
  • 코드 스냅샷이 아닌 커밋과 저장소 진화 과정을 학습 대상으로 삼는 code-flow 패러다임 채택
  • 에이전트형 소프트웨어 엔지니어링, 경쟁 프로그래밍, 도구 사용 전반에서 성능 평가 수행

Code-Flow 학습 파이프라인

  • 사전학습 단계에서 일반 데이터와 대규모 코드 데이터를 혼합 학습 후 고품질 코드 어닐링 적용
  • 미드트레이닝 단계에서 32K → 128K 컨텍스트 확장, 추론 QA·에이전트 궤적·저장소 단위 코드 데이터 학습
  • 포스트트레이닝 단계에서 Thinking 경로(추론 중심 RL)Instruct 경로(일반 보조 최적화) 로 분기

핵심 연구 결과

  • 저장소 커밋 흐름 데이터가 정적 코드 스냅샷보다 작업 계획 신호가 우수함을 실험으로 확인
  • 고품질 코드 어닐링 이후 미드트레이닝에서 추론·에이전트 데이터를 주입하는 구조가 분포 변화에 대한 안정성 제공
  • 추론 중심 RL을 적용한 Thinking 경로에서 장기 작업 중 자가 오류 복구 능력이 뚜렷하게 나타남

LoopCoder 아키텍처

  • 동일 파라미터 블록을 두 번 반복 실행하는 루프 트랜스포머 구조 도입
  • 전역 어텐션과 지역 어텐션을 게이팅으로 결합해 장거리 문맥 정제와 인과성 유지를 동시에 달성
  • 모델 용량 대비 연산 효율을 개선해 배포 환경 제약 대응 목적

데이터 구성과 사전학습 전략

  • 다언어 코드 혼합 학습에서 언어 간 시너지 효과를 수식 기반 스케일링 법칙으로 정식화
  • 저장소 생애주기 40~80% 구간의 커밋을 활용한 (R_old, Patch, R_new) 트리플릿 데이터 구성
  • 파일·저장소 단위 Fill-In-the-Middle 기법으로 코드 완성 능력 강화

평가 결과

  • SWE-Bench Verified에서 76.2, LiveCodeBench v6·Terminal-Bench·Mind2Web 등 다수 벤치마크에서 상위권 성능 기록
  • 코드 생성·추론·편집·효율성·Text-to-SQL·에이전트 작업까지 전 범위 평가 수행
  • 일부 지표에서 Claude Sonnet 4.5, GPT-5.1 등 폐쇄형 모델과 근접하거나 경쟁적인 결과 확인

안전성 평가

  • BeaverTails, HarmBench, TrustLLM 등 안전성 벤치마크에서 Thinking 모델이 높은 거부 정확도와 균형 성능 기록
  • 추론 중심 RL이 안전성 측면에서도 긍정적 효과를 보이는 결과 제시

결론

  • 코드 진화 흐름과 에이전트 궤적을 중심으로 한 학습이 자율적 코드 지능 형성에 효과적임을 실증
  • LoopCoder 구조를 통해 성능–효율 트레이드오프를 고려한 실용적 코드 LLM 설계 방향 제시
  • 전체 학습 단계와 체크포인트를 공개해 오픈 코드 지능 연구와 실제 에이전트 시스템 개발 촉진 목표
Hacker News 의견들
  • 더 나은 링크는 iquestlab.github.io
    하지만 아쉽게도 평가 중 에이전트가 부정행위를 한 것으로 보임

    • GitHub 이슈에 따르면, 부정행위를 수정한 후에도 결과는 여전히 좋았음
      점수가 81.4%에서 76.2%로 떨어졌지만 여전히 Opus 4.5(74.4%)보다 높음
    • 며칠 전에는 이 링크가 충분한 투표를 받지 못했음
  • 요약하자면, .git/ 폴더를 정리하지 않아 모델이 미래 커밋의 수정사항을 보상 해킹(reward hacking) 방식으로 참고한 것임
    이 문제를 함께 해결한 사람들에게 공을 돌리고 싶음
    관련 논의는 이 트윗Reddit 스레드에서도 볼 수 있음
    IQuestLab이 SWE-Bench Verified 데이터를 공개한 점을 보면, 의도적인 조작보다는 단순한 벤치마크 초보자의 실수로 보임

    • John이 언급했듯이, SWE-bench에서 이 문제는 이미 수정되었음
      최신 코드를 사용하고 업데이트된 Docker 이미지로 평가를 돌리면 됨
      관련 트윗
    • 나도 단순한 실수라고 생각하지만, 연구자들이 출력 결과를 한 번이라도 봤다면 바로 눈치챘을 것이라는 점은 아쉬움
    • SWEbench는 여전히 과대광고 논란에서 벗어나지 못하고 있음
  • 내 경험상 GLM-4.7 (opencode 버전) 이 오픈소스 중에서는 가장 근접함
    가끔 Claude의 데이터가 섞인 듯한 표현이 보여서, 일부 Claude 데이터 활용이 있었을 것 같음

    • 하지만 성능은 Sonnet 4.5에는 한참 못 미치고, Opus와는 비교 불가임
    • “What’s your use-case?” 같은 문구도 자주 보임
      Claude가 한계를 느낄 때 회피용으로 자주 쓰는 표현임
  • 40B 파라미터 모델이 Sonnet 4.5와 GPT 5.1을 이긴다고? 이게 가능한 일인지 궁금함

    • 내 추측(확실하진 않음)은 테스트 데이터 누출이나 벤치마크 세트 일부가 학습 데이터에 포함된 것 같음
      그래도 Sonnet 4.5는 이미 오래된 모델이고, 최근 혁신이 많았음
      오픈모델들이 대형 모델을 빠르게 추격하는 모습이 흥미로움
    • “IQuest”라는 이름이 의심스럽다(It's questionable) 는 말장난이 나올 정도임
    • 아마 모델 프루닝(pruning) 기법을 적용했을 가능성도 있음. 요즘 새로운 방법들이 많음
    • 실제로는 에이전트가 평가 하네스를 해킹한 것으로 드러남
  • 혹시 누가 이 모델을 직접 돌려봤는지, 또는 호스팅된 API로 테스트해본 적 있는지 궁금함

  • 이건 허위 주장인데, 왜 아직도 메인 페이지에 남아 있는지 의문임