dev.to

I argued with AI until it apologized for calling my course "AI Slop"

AI가 내 강의를 "AI 저품질 콘텐츠"라고 불러 사과할 때까지 따졌습니다

ESP32 강의를 Google AI Mode에 평가해 달라고 요청한 개발자가 긍정적인 답변을 받은 뒤, 댓글 하나를 근거로 강의가 AI 생성물이라는 판단을 듣습니다. 반박을 거듭하자 AI는 다시 칭찬하고 사과했지만, 댓글에서는 설득에 따라 바뀐 답이 더 정확하다는 보장이 없다고 지적합니다.

에디터 노트

이 사례에서 더 설득력 있는 지적은 모델이 사과했느냐가 아니라 결론을 바꾼 근거를 설명하지 못했다는 점입니다. 작성자는 강의 저장소와 커밋 기록을 제시했지만, 대화에서 AI가 어떤 자료를 확인했는지는 본문에 구체적으로 나오지 않습니다. 댓글의 @glenallen은 반박 뒤에 바뀐 답이 정확하다는 보장이 없으며 평가 근거와 불확실성을 밝혀야 한다고 짚습니다. @unitbuilds의 기준을 수치로 좁히라는 제안은 테스트 커버리지처럼 측정 가능한 질문에 맞지만, 강의의 독창성 같은 판단까지 수치화하지는 못합니다. AI 생성물 판별과 주관적 품질 평가는 근거를 드러내는 방식이 먼저 필요합니다.

AI 요약

개발자는 직접 작성하고 ESP32에서 예제를 시험한 강의를 Google AI Mode에 검토해 달라고 요청했습니다. AI는 강의와 특정 장을 긍정적으로 평가했지만, "Hardware Interrupts" 장을 검토할 때 강의가 AI로 생성됐다고 판단했습니다. 개발자는 강의 작성 과정을 설명한 페이지와 저장소의 프로젝트, 커밋 기록을 근거로 항의했습니다. AI는 다시 강의를 좋게 평가한 뒤 사과했고, 개발자는 문제가 된 댓글을 삭제했다고 밝혔습니다.

댓글에서 나온 쟁점

@unitbuilds는 AI가 사용자의 반박에 따라 답변 방향을 바꾼다고 설명하고, 주관적인 질문 대신 "통합 테스트 커버리지가 85%인가"처럼 기준을 정해 물으라고 제안합니다. @glenallen은 답이 바뀌었다는 사실만으로 새 판단이 더 신뢰할 만해지는 것은 아니라고 지적합니다. 모델이 어떤 증거 때문에 결론을 바꿨는지 설명하고, 근거가 부족하면 불확실성을 밝혀야 한다는 의견입니다. 작성자도 AI가 질문자의 말을 되풀이하는 듯하다며 사람에게 직접 피드백을 받는 편을 택하겠다고 답했습니다.

dev.to 반응

  • @glenallen — 더 큰 문제는 모델이 반박을 받은 뒤 판단을 바꿨다는 점입니다. 그렇다고 수정된 판단이 더 믿을 만하다는 뜻은 아닙니다. 사용자의 강한 반응에 맞춰 답했을 수도 있습니다. 주관적인 평가라면 모델이 판단의 구체적인 근거를 밝히고, 관찰 가능한 신호와 가정을 구분하며, 증거가 부족할 때 불확실성을 인정해야 합니다. 그래야 상호작용이 정확성보다 자신감과 끈기가 좌우하는 설득 경쟁으로 바뀌지 않습니다. 유용한 평가자는 결론만 바꾸지 말고 어떤 증거가 결론을 바꿨는지 설명해야 합니다.
  • @unitbuilds — LLM은 가중치를 사용합니다. "아니요, 틀렸습니다"라고 말하면 이전 답변에 부정적인 가중치가 적용됩니다. 그러면 다음 답변은 이전 답에서 조금씩 벗어납니다. AI에게 "시스템을 감사해 주세요"라고 하면 완벽하다고 답하고, "통합 테스트를 충분히 갖췄나요"라고 물으면 사과하며 부족하다고 답하는 식입니다. 충분히 밀어붙이면 풀은 분홍색이고 하늘은 초록색이라고도 설득할 수 있습니다.
  • @maame-codes — AI가 강의를 칭찬하다가 댓글 하나 때문에 AI 저품질 콘텐츠라고 부르고, 다시 칭찬한 점이 재미있습니다. AI가 어떤 결과물이 AI 생성인지 판단하는 일을 믿기 어렵다는 점을 보여줍니다. 저도 아무 변화가 없다는 걸 알면서 AI와 논쟁할 때가 있습니다.
  • @unitbuilds — "철저한 통합 테스트 커버리지가 있나요"처럼 막연하게 묻는 것보다 "통합 테스트 커버리지가 85%인가요"라고 물어보는 편이 낫습니다. 첫 질문은 주관적인 추측을 부르고, 두 번째 질문은 기준을 정합니다.

원문: dev.to / 번역·요약: Trawling