| Aug 11, 2026 | reward를 어떻게 설계할 것인가 — RM 설계 실무 |
| Aug 11, 2026 | 프론티어 모델은 harmlessness reward를 어떻게 설계했나 |
| Aug 11, 2026 | 프론티어 모델은 helpfulness reward를 어떻게 설계했나 |
| Aug 11, 2026 | 도구 호출을 어떻게 채점하나 — ToolRL·ToolRM |
| Aug 11, 2026 | One Token to Fool: GenRM도 결국 뚫린다 |
| Aug 11, 2026 | CriticEval: judge를 채점하는 벤치마크 |
| Aug 11, 2026 | Rubrics as Rewards: 정답이 없는 도메인에 reward를 만드는 법 |
| Aug 11, 2026 | J1: RL로 judge를 생각하게 만들다 |
| Aug 11, 2026 | ReasonGRM: judge에게 추론 능력을 이식하다 |
| Aug 11, 2026 | DeepSeek-GRM: reward model이 평가 기준을 스스로 만든다 |
| Aug 11, 2026 | Self-Taught Evaluators: 사람 라벨 없이 judge를 키우다 |
| Aug 11, 2026 | Generative Reward Models: GenRM과 선호 학습을 잇다 |
| Aug 11, 2026 | Generative Verifiers: reward를 분류가 아니라 생성으로 풀다 |
| Aug 11, 2026 | Prometheus 2: 평가 기준을 입력으로 받는 judge |
| Aug 11, 2026 | DeepSeek-R1: reward model을 규칙으로 대체하다 |
| Aug 11, 2026 | Math-Shepherd: 사람 라벨 없이 PRM을 만들다 |
| Aug 11, 2026 | Let's Verify Step by Step: 결과가 아니라 과정에 보상을 주다 |
| Aug 11, 2026 | DPO: reward model을 없애면 무엇을 잃는가 |
| Aug 11, 2026 | Rule-Based Rewards: 안전 규칙을 reward로 직접 번역한다 |
| Aug 11, 2026 | Safe RLHF: 안전성을 reward가 아니라 '제약'으로 다룬다 |
| Aug 11, 2026 | WARM: reward model을 weight 공간에서 평균내다 |
| Aug 11, 2026 | 아첨(sycophancy): RM은 사실보다 동의를 좋아한다 |
| Aug 11, 2026 | ODIN: reward에서 길이 성분을 떼어내다 |
| Aug 11, 2026 | RLHF는 정말 좋아진 걸까, 길어진 걸까 |
| Aug 11, 2026 | Reward Model Overoptimization: Goodhart의 법칙을 수식으로 쓰다 |
| Aug 11, 2026 | RewardBench 2: reward model을 어떻게 믿을 것인가 |
| Aug 11, 2026 | Llama 2의 RLHF: reward model을 두 개로 쪼갠 이유 |
| Aug 11, 2026 | ArmoRM: 하나의 스칼라를 해석 가능한 여러 축으로 쪼개다 |
| Aug 11, 2026 | Skywork-Reward: 데이터 큐레이션이 아키텍처를 이긴다 |
| Aug 11, 2026 | Secrets of RLHF II: 선호 데이터의 노이즈와 reward model의 일반화 |
| Aug 11, 2026 | Rethinking Bradley-Terry: 왜 이 식으로 reward를 만드는가 |
| Aug 11, 2026 | HH-RLHF: helpfulness와 harmlessness는 왜 충돌하는가 |
| Aug 11, 2026 | InstructGPT: RLHF 3단계 레시피의 표준을 세우다 |
| Aug 11, 2026 | Deep RL from Human Preferences: 보상 함수를 사람의 선호로 배우다 |