근거가 있는 AI 요약도 틀릴 수 있습니다

커뮤니티 LLM QA에서 ID 검증과 의미 검증을 나눈 이유

근거가 존재하는 것과, 그 근거가 요약을 뒷받침하는 것은 다릅니다.

커뮤니티 게시글을 분석하고 종합 요약하는 서비스를 검증하면서 가장 선명하게 배운 점입니다. 문장은 자연스러웠고 대표 게시글도 연결돼 있었습니다. 그런데 근거를 열어 보면 요약과 반대되는 의견이 담겨 있었습니다.

예를 들어, 요약에는 ‘장비 교체가 빠르다’고 적혀 있는데 대표 글은 ‘교체가 너무 느리다’는 내용이었습니다. 근거가 연결돼 있다는 사실만으로 요약을 신뢰하기는 어려웠습니다.

이 문제를 확인하기 위해 평가 기준을 세우고, 개별 분석과 종합 요약을 나눠 검증했습니다. 발견한 오류를 프롬프트에 반영하고 반복시험했으며, 해결이 확인되지 않은 부분은 다음 개선 과제로 남겼습니다.

아래 사례는 이해를 돕기 위해 실제 검토 내용의 표현을 간략하게 재구성했습니다.

1. 먼저, ‘잘된 요약’을 판단할 기준을 공유했습니다

검증을 시작하기 전, 스코어링 기반 QA 진행안을 문서로 작성해 공유했습니다. 검토 항목은 다섯 가지로 나눴습니다.

이 프로젝트에서는 100점 만점에 90점 이상을 통과 목표로 설정했습니다. 배점과 목표는 업무 특성에 맞춰 정한 기준이며, 모든 LLM 서비스에 적용할 보편적 기준은 아닙니다.

총점과 함께 운영 판단을 바꿀 수 있는 중대 의미 오류가 남았는지도 별도로 확인했습니다. 이용자 비판을 운영사 비판으로 바꾸거나, 의심·신고 내용을 실제 제재로 확정하는 오류를 중요하게 봤습니다.

판정 방식도 구분했습니다.

• 확정 오류: 원문과 출력의 불일치를 구체적으로 설명할 수 있는 경우입니다.
• 확인 필요: 게임 은어처럼 추가 맥락에 따라 해석이 달라질 수 있는 경우입니다.
• 미검증: 실제 입력이나 집계 조건 등 판단에 필요한 자료가 없는 경우입니다.

문체 취향은 감점하지 않았습니다. 미검증 항목에는 임의로 0점이나 만점을 부여하지 않았고, 확인한 범위만 환산한 점수는 잠정치로 표시했습니다. 이를 통해 점수와 함께 판단의 근거와 확인 범위를 남길 수 있었습니다.

2. 개별 게시글 분석과 종합 요약을 나눠 검증했습니다

검증 대상은 내부 게임 트렌드 분석 플랫폼의 커뮤니티 요약 기능이었습니다. 크게 두 단계로 동작했습니다.

1. 개별 분석: 게시글마다 요약과 카테고리 등을 생성합니다.
2. 종합 요약: 개별 분석 결과를 모아 시간대별·일별 제목, 요약, 대표 게시글을 생성합니다.

최종 카드만 보면 어느 단계에서 의미가 바뀌었는지 알기 어려웠습니다. 그래서 원문과 개별 요약을 먼저 비교하고, 종합 요약과 선택된 대표 근거를 따로 대조했습니다.

개별 분석에서는 대상과 결과가 바뀌는 오류를 확인했습니다

이런 사례에서는 ‘정확하게 요약하라’는 포괄적 지시를 더 구체적으로 바꿨습니다. 무엇을 보존해야 하는지와 어떤 변환이 오류인지를 규칙과 예시로 명시했습니다.

반대로 빈 요약이 정상인 경우도 있었습니다. ‘누가 제일 잘해요?’라는 질문에 비교 대상이 전혀 없다면, 임의로 직업이나 캐릭터 비교를 만들어서는 안 됩니다. 해당 정책에 맞는 빈 요약은 오류에서 제외했습니다.

여기서 얻은 기준은 간단했습니다. 요약이 생성됐는지만 볼 것이 아니라, 입력으로 말할 수 있는 범위를 지켰는지 봐야 했습니다.

종합 요약에서는 전체 입력과 선택 근거를 따로 확인했습니다

종합 요약에서는 서로 다른 두 질문을 확인했습니다.

• 전체 입력으로 이 요약을 설명할 수 있는가?
• 선택된 대표 글로도 이 요약을 설명할 수 있는가?

마지막 사례는 전체 입력 어디에도 관련 논의가 없다는 뜻은 아닙니다. 전체 게시글에는 관련 내용이 있어도, 사용자에게 연결해 준 대표 글에는 없을 수 있습니다.

또한 실제로 존재하고 해당 카테고리에 속하는 글이라도, 요약과 반대되는 의견을 담고 있을 수 있습니다. 이때부터 ID 존재 여부, 카테고리 소속, 의미 일치를 각각 다른 검증 대상으로 보게 됐습니다.

3. 오류를 규칙으로 바꾸고, 같은 입력으로 다시 확인했습니다

실제 개선 작업은 다음 순서로 진행했습니다.

프롬프트 보완은 제가 담당했고, 개발 측과 실제 적용 및 재시험을 협의했습니다. AI는 파일 비교, 오류 유형 정리, 개선안 작성을 지원했습니다. 원문의 의미와 기대 결과는 사람이 검토했습니다.

개별 분석은 개발 전 시험에서 기존 핵심 오류의 개선을 확인했고, 전체 점검에서는 일부 추가 보완 사항이 남았습니다. 다만 실제 배포에는 비용을 고려해 시험 때와 다른 프롬프트 버전·경량 모델 조합을 선택했습니다. 따라서 개발 전 시험 결과를 배포 버전의 품질로 그대로 볼 수는 없었습니다.

종합 요약에서는 여러 차례 프롬프트를 보완한 뒤에도 같은 입력의 반복시험에서 의미 불일치가 남았습니다.

해당 시험 조건에서는 프롬프트 보완만으로 해결이 확인되지 않았습니다. 이를 ‘프롬프트로는 절대 해결할 수 없다’는 주장으로 확대할 수는 없었습니다.

기존 오류 사례를 통과하는 것과 새로운 데이터에서도 안정적으로 동작하는 것 역시 별개였습니다. 수정 사례의 재검증과 신규 라이브 모니터링을 구분해 진행한 이유입니다.

4. 남은 오류는 다음 시험의 질문으로 바꿨습니다

QA를 진행하면서 다음 단계로 전달되는 입력 범위와 실제 검증 항목을 추가로 파악해야 했습니다. 이 구조를 알아야 프롬프트로 보완할 부분과 별도 개발 검토가 필요한 부분을 구분할 수 있었습니다.

개발 측과 확인한 검증 범위는 ID와 카테고리였습니다. 선택된 글이 생성된 요약을 실제로 뒷받침하는지 확인하는 의미 검증 단계는 없었습니다.

제가 제안한 다음 비교시험은 아래와 같았습니다.

대표 근거를 먼저 선정 → ID·카테고리 검증 → 선택된 글의 요약만으로 종합 요약 생성

기존 게시글 요약 입력은 유지하고, 근거 선정과 종합 요약 생성을 분리하는 방식입니다. 요약이 참조할 근거를 먼저 확정하면 두 결과의 불일치를 줄일 수 있는지 확인하려 했습니다.

다만 이 방식에도 확인할 것이 있었습니다.

• 처음부터 잘못된 근거를 고르면 이후 요약도 그 영향을 받을 수 있습니다.
• 선택된 글로 범위를 좁히면서 주요 의견이 빠질 수 있습니다.
• 호출 단계와 데이터 전달 구조가 늘어 비용·시간·개발 범위가 달라질 수 있습니다.

해당 시험은 수정 범위와 일정의 제약으로 진행하지 못했습니다. 구조 분리의 개선 효과는 아직 확인되지 않았으며, 다음에 검증할 가설로 남아 있습니다.

이번 경험에서는 이 구분이 중요했습니다. 오류를 발견한 사실, 원인에 대한 해석, 개선안의 기대 효과를 각각 기록해야 이후 논의를 정확히 이어갈 수 있었습니다.

5. 배포 이후에도 같은 기준으로 확인했습니다

서비스는 비용·일정과 잔존 리스크를 고려해 Beta로 제공하고, 라이브 데이터를 모니터링하는 방향으로 진행했습니다.

배포 후에는 실제 화면과 다운로드한 게시글을 대조했습니다. 개별 요약·번역 오류와 함께, 종합 요약의 일부 내용을 대표 글이 뒷받침하지 못하는 사례도 확인됐습니다.

같은 주제 안의 상반된 의견이 한 방향으로 묶인 경우도 있었습니다. 설명을 위해 재구성하면 다음과 같습니다.

둘 다 ‘참여 제한’에 관한 내용이지만, 주장하는 방향은 반대입니다. 같은 주제로 묶을 수 있다는 것과 같은 의견의 근거로 사용할 수 있다는 것은 달랐습니다.

라이브 검토에서는 두 가지를 주의했습니다.

• 시험 조건 구분: 다른 모델·프롬프트·입력의 결과를 같은 조건의 개선 전후 성과처럼 비교하지 않았습니다.
• 출력 오류와 원인 구분: 최종 요약이 틀렸다는 사실만으로 앞 단계 오류인지, 종합 과정의 오류인지 단정하지 않았습니다.

출시 결정에는 품질 외에도 비용과 일정이 영향을 줍니다. 그래서 Beta 제공 결정과 QA 기준 충족 여부를 구분하고, 남은 오류와 후속 대응을 기록했습니다.

6. 다음 QA에 가져갈 세 가지 기준

이번 작업에서 다음에도 적용할 기준은 세 가지입니다.

첫째, 기준과 파이프라인을 함께 공유합니다.
무엇을 평가할지뿐 아니라 어떤 입력이 다음 단계로 넘어가고, 검증은 무엇을 확인하며, 실패 결과를 어떻게 처리하는지 QA 전에 확인합니다.

둘째, 오류를 수정 가능한 단위로 기록합니다.
‘요약이 이상하다’에서 끝내지 않고, 대상 변경·입장 반전·결과 누락·근거 불일치처럼 구체화합니다. 그래야 프롬프트 보완과 개발 검토의 범위를 좁힐 수 있습니다.

셋째, 개선한 것과 확인한 것을 구분합니다.
프롬프트를 수정했다는 사실이 해결을 뜻하지는 않습니다. 반복시험에서 확인된 결과, 새로운 데이터에서의 결과, 아직 시험하지 않은 대안을 각각 남깁니다.

근거가 존재하는 것과, 그 근거가 요약을 뒷받침하는 것은 다릅니다.
대표 글의 ID가 유효한지 확인한 다음에는 한 단계 더 들어가야 했습니다. 그 글의 대상과 주장, 의견 방향이 요약과 연결되는지 확인하는 것. 이번 LLM QA에서 얻은 가장 실용적인 기준입니다.