전체 글 썸네일형 리스트형 로컬 환경이 CI 워크플로를 만든다 CI 설정 파일 하나 만드는 데 드는 시간이 만만치 않다는 말, 공감하시나요? 2026년 10월 21일 arXiv에 공개된 논문 DynaCI는 이 지루한 작업을 다른 각도에서 봅니다. 요구사항을 글로 설명하라고 요구하지 않고, 개발자 컴퓨터에서 실제로 도는 환경을 직접 읽는 방식입니다.왜 CI 설정은 여전히 손이 많이 갈까CI는 빌드와 테스트로 코드 변경을 자동 검증합니다. 그런데 복잡한 아키텍처와 수많은 의존성, 다양한 실행 환경 때문에 워크플로 설정은 여전히 어렵습니다. 워크플로는 CI 플랫폼별 DSL로 써야 해서 에러가 잦고 유지보수도 힘듭니다.기존 자동 생성 연구는 자연어 명세나 부분 워크플로를 요구했습니다. 문제는 개발자가 요구사항을 말로 풀기 어려워하고, CI 기능을 잘 모른다는 점입니다. 글.. 더보기 벤치마크 점수, 그 분포부터 의심하세요 리더보드 점수가 몇 점 올랐다는 소식은 넘치는데, 그 점수가 도대체 무엇을 재는지 묻는 연구는 드뭅니다. 2026년 10월 21일 arXiv에 공개된 논문 Your Benchmark는 이 질문 자체를 정식화합니다. 벤치마크는 문제 모음이 아니라, 난이도 위에 올라간 경험적 측도라는 관점입니다.점수가 아니라 분포를 봐야 하는 이유논문의 출발점은 단순합니다. 벤치마크 점수는 난이도 축 위의 분포에서 유도됩니다. 그래서 의도한 난이도 분포와 실제 문항이 만드는 분포가 다르면, 점수 해석 자체가 틀어집니다. 점수를 올렸다는 말보다 먼저 물어야 할 것은, 이 벤치마크가 어떤 난이도를 얼마나 재고 있는가입니다.벤치마크는 난이도 위에 경험적 측도를 유도한다.이 관점이 중요한 이유는 리더보드 숫자를 읽는 방식을 바꾸기.. 더보기 LLM 분류기, 하나로 묻지 말고 회로로 언어 모델에 “이 문장은 스팸인가요?”라고 묻는 일은 쉬워졌습니다. 프롬프트 하나로 분류기가 되니까요. 그런데 같은 질문을 다시 던졌을 때 답이 바뀐다면, 그 답을 어디까지 믿어야 할까요? 2026년 10월 21일 arXiv에 공개된 논문 ‘Circuits of LLM Classifiers’는 이 흔들림 자체를 설계 문제로 다룹니다.왜 하나의 답을 믿기 어려울까논문의 출발점은 단순합니다. 샘플을 분류하라고 프롬프트한 언어 모델로 분류기를 만들기는 쉽습니다. 문제는 그 다음에 생깁니다.예측은 결정적이지 않습니다. 같은 입력에도 답이 달라질 수 있습니다.예측은 샘플 전반에 균일하게 신뢰할 수 없습니다. 어떤 샘플에서는 맞고, 어떤 샘플에서는 틀립니다.그래서 핵심 질문은 이것입니다. 다른 모델의 예측을 결합해.. 더보기 추론을 말로 풀지 말고 잠재로 압축하라 추론을 길게 말로 풀어내는 방식, 과연 언제까지 버틸 수 있을까요. Seokhyun Lee 연구진의 PLRM은 이 질문에 잠재 공간이라는 답을 내놓습니다. 말을 줄이는 것이 아니라, 추론 자체를 다른 공간으로 옮기는 시도입니다.말로 푸는 추론은 왜 비쌀까요언어에 의존하는 모델은 토큰 단위 생성에 묶여 있습니다. 텍스트 일관성을 맞추기 위한 토큰이 핵심 추론과 얽힌다는 것이 논문의 출발점입니다. 말이 길어질수록 추론도 함께 무거워지는 구조, 바로 그 지점을 PLRM은 겨냥합니다.대안은 compact한 연속 잠재 공간에서 추론하는 것입니다. 이곳에서는 다양한 추론 궤적을 효율적으로 표현하고 탐색할 수 있다고 합니다. 한 줄의 정답 경로가 아니라, 여러 갈래의 가능성을 함께 다루는 공간입니다.기존 잠재 모델은.. 더보기 에이전트 PR, 검증 증거부터 재야 합니다 코딩 에이전트가 쓴 PR을 리뷰할 때, 테스트가 붙어 있으면 충분하다고 보십니까. VeeReview 연구는 그 질문부터 다시 던집니다. 테스트가 있느냐가 아니라, 그 변경을 검증하는 증거가 되느냐를 재야 한다는 것입니다.테스트 유무만으로는 PR을 가릴 수 없습니다PR 리뷰는 변경에 대응하는 검증 증거를 요구합니다. 그런데 코딩 에이전트 벤치마크와 PR 결과 연구는 이 관계를 직접 측정하지 않았다고 합니다. 벤치마크 점수가 높다고 해서, 그 PR이 제대로 검증됐다는 뜻은 아니라는 이야기입니다. VeeReview는 소프트웨어 공학의 V-Model에서 아이디어를 빌려, 빌드 산출물과 검증 산출물의 쌍을 측정하는 기기로 나섰습니다.측정 방식은 두 갈래입니다. 리포지토리 신호와 언어모델 판정으로 네 가지 빌드-검.. 더보기 모니터 12개가 동시에 속았다 AI 에이전트에게 결제 권한을 줄 때, 승인 모니터를 여러 개 두는 것만으로는 부족하다는 실측이 나왔다. 소형 오픈웨이트 모니터 12개가 같은 근거원에 속아 한 번에 무너졌기 때문이다.모니터가 많은데 왜 한 번에 무너졌나결제나 메시징, 코드 변경처럼 되돌리기 어려운 행동 앞에는 보통 여러 모니터가 선다. 각자 점수를 매기거나 표를 세어 최종 승인을 결정하는 구조이다. 문제는 이 모니터들이 서로 독립이 아니라는 점이다.같은 베이스 모델을 쓰거나, 오염된 입력을 공유하면 모니터들은 같은 지점에서 함께 실패한다. 연구진은 분산 컴퓨팅의 fail-prone systems 개념을 가져왔다. 함께 실패할 수 있는 모니터 집합을 목록으로 정의한 것이다.실측 대상은 소형 오픈웨이트 모니터 12개였다. 결제 승인 상황에.. 더보기 정책이 좋아질수록 검증이 무너진다 검증자 스택은 이제 포스트 트레이닝과 테스트 타임 컴퓨트 루프 안에 깊숙이 들어와 있습니다. 그런데 정책을 평가하는 검증자 자체는, 그 정책이 만든 출력으로 평가받습니다. 정책이 좋아지면 검증자의 시험지도 함께 바뀌는 셈입니다. 2026년 10월 arXiv에 공개된 논문 Better Policies, Worse Verifier Audits는 이 역설을 수식으로 정리했습니다.검증자는 정책이 만든 시험지로 평가받습니다논문이 다룬 제어 루프는 단순합니다. 컴포넌트 검증자는 새 정책 출력에 대해 전체 성공 라벨로 평가받고, 총합 점수가 떨어지면 갱신됩니다. 얼핏 합리적으로 보이지 않나요? 문제는 평가 데이터가 정책에 종속된다는 점입니다. 정책이 바뀌면 검증자가 보는 세상도 바뀝니다.저자: Daniel Cieśl.. 더보기 데이터 없이 긴 문맥 추론 키우는 LongZero 긴 문서를 읽고 답하는 모델을 키우려면 어떤 학습 데이터가 필요할까요. 길고, 다양하고, 어렵고, 검증까지 가능한 데이터가 필요합니다. 그런데 바로 그 데이터를 만드는 일이 병목입니다. 사람이 직접 주석을 달기에는 비싸고, 자연적으로 존재하는 데이터는 금방 바닥납니다.순서를 뒤집으면 데이터 문제가 달라집니다기존 합성 방식은 문서 위에 질문을 쓰는 순서였습니다. 문서가 먼저 있고, 그 위에서 질문과 답을 만드는 방식이지요. 문제는 이 방식이 외부 코퍼스나 더 강한 교사 모델에 의존한다는 점입니다. 그런데 모델이 강해질수록 교사 모델은 구하기 어려워집니다. 강한 모델을 가르칠 더 강한 교사를 어디서 구할까요.LongZero는 순서를 뒤집습니다. 모델이 먼저 질문과 답을 supporting evidence와 .. 더보기 이전 1 2 3 4 ··· 49 다음
