작성 에이전트와 비평 에이전트를 반복 실행하면 답이 계속 좋아질까요? 평가·수정 루프의 조건과 한계는 무엇인가요?

평가 기준이 명확하고 수정에 도움이 되는 피드백이 있을 때 평가·수정 루프가 유용합니다. 같은 모델이 답을 다시 읽는 것만으로 새로운 사실을 알거나 오류를 확실히 발견하는 것은 아닙니다. 생성 결과를 기준에 대조하고 구체적인 결함만 수정한 뒤 다시 확인하되, 반복 상한과 최선 결과 보존 규칙을 두겠습니다.

피드백이 실행 가능한가

보고서의 '더 자세히 쓰라'는 피드백은 분량만 늘릴 수 있습니다. 반면 '주장 A는 출처의 선택 기능을 필수로 바꾸었고, 표의 단위가 원문과 다르다'는 피드백은 검증 가능한 수정 지점을 줍니다. 코드에서는 컴파일·테스트·정적 분석 결과를 우선 활용하고, 설명의 명확성처럼 기계적 판정이 어려운 부분에 모델 평가를 보완적으로 씁니다. 생성 모델이 평가 기준이나 테스트를 바꾸어 통과하지 못하게 분리합니다.

비평자가 필요한 원문·실행 결과 없이 생성 답만 보면 그럴듯한 잘못을 따라갈 수 있습니다. 근거 접근과 평가 rubric을 제공하고, 확실하지 않은 항목은 미확인으로 반환하게 합니다. 모든 문장을 수정하도록 압박하지 않고 문제가 없다는 결과도 허용해야 불필요한 변경으로 정확성이 떨어지는 일을 줄일 수 있습니다.

종료와 회귀 방지

수정 후 점수가 올라도 원래 맞던 부분을 망가뜨릴 수 있습니다. 버전별 결과를 보존하고 핵심 불변식과 기존 테스트를 함께 돌려야 합니다. 평가자 점수를 최대화하는 문구나 형식만 늘어나는 reward hacking도 확인합니다. 예를 들어 인용 개수를 점수로 삼으면 실제 근거보다 링크를 늘릴 수 있으므로 주장 뒷받침을 평가해야 합니다.

최대 반복 수, 시간·비용과 개선 중단 조건을 정하고 한두 번 이후 개선이 없으면 더 반복하기보다 새 근거·사람 검토·범위 축소를 선택합니다. 동일 과제에서 단일 생성, 자기 검토, 독립 평가, 실제 도구 검증을 같은 비용으로 비교하겠습니다. 평가기는 생성기보다 무조건 정확한 상위 지능이 아니며, 최종 결과를 검증하는 여러 수단 중 하나입니다. 최근 에이전트 평가 논의도 trace와 실제 outcome을 구분하므로, 좋은 피드백 대화가 있었다는 사실보다 결과가 실제로 개선됐는지 확인하는 것이 중요합니다.

실행 사례로 확인합니다

수정 요청에는 고칠 항목과 보존할 항목을 함께 적을 수 있습니다. 예를 들어 잘못된 버전 설명만 바꾸고 이미 검증된 코드 예제와 승인 조건은 유지하게 합니다. 모든 답을 통째로 다시 쓰게 하면 정확한 부분이 사라지는 회귀가 늘 수 있습니다. 수정 결과는 이전 버전과 diff로 비교하고 평가 기준이 실제 요구와 일치하는지 확인합니다. 피드백이 반복해서 같은 일반론만 반환하면 더 많은 루프보다 평가기를 바꾸거나 원문을 추가하는 것이 필요합니다. 개선이 없다는 결과도 정상 종료로 인정하고, 마지막 생성물보다 실제 검증을 통과한 최선 버전을 보존해야 평가 루프가 무조건적인 재작성 장치가 되지 않습니다.