AI 답변의 단어 선택을 팀마다 같은 방향으로 맞추려면 감각이 아니라 판정 기준표가 필요합니다. 독자, 위험도, 문맥에 따른 허용 표현과 금지 표현을 사례로 남기고, 평가와 업데이트가 이어지는 운영 구조를 만드는 방법을 설명합니다.
언어모델 단어 선택 기준이 필요한 이유
대규모 언어모델(LLM)은 같은 질문에도 표현의 강도와 확신 정도를 다르게 만들 수 있습니다. 한 답변에서는 “확인됩니다”라고 단정하고, 다른 답변에서는 “가능성이 있습니다”라고 말하면 독자는 정보의 확실성을 일관되게 판단하기 어렵습니다.
문제는 단어 하나가 문체만 바꾸는 데 그치지 않는다는 점입니다. “해야 합니다”는 의무처럼 들리고, “권장합니다”는 선택지를 남기며, “검토할 수 있습니다”는 가능성만 제시합니다. 이런 차이를 팀이 합의하지 않으면 검수자마다 서로 다른 수정을 지시하게 됩니다.
기준표의 목적은 가장 그럴듯한 문장을 고르는 것이 아닙니다. 특정 상황에서 어떤 의미를 전달해야 하는지 먼저 정하고, 그 의미에 맞는 표현을 반복해서 선택할 수 있게 만드는 것입니다. 따라서 좋은 기준표는 표현 목록보다 판단 조건을 중심으로 작성됩니다.
팀 기준표를 설계하는 질문
먼저 답변이 사용되는 장면을 좁혀야 합니다. 고객 문의, 내부 업무, 교육 콘텐츠, 법률이나 건강처럼 오류 비용이 큰 안내는 같은 단어 선택 기준을 적용하기 어렵습니다. 사용 목적과 독자의 지식 수준을 한 문장으로 적으면 이후 판정이 흔들리지 않습니다.
그다음 표현의 확신 수준을 정합니다. 사실로 확인된 내용, 자료에 근거한 해석, 조건부 가능성, 모델이 답할 수 없는 영역을 서로 다른 언어로 구분해야 합니다. “입니다”, “일 수 있습니다”, “확인해야 합니다”를 각각 언제 쓰는지 조건과 함께 기록하면 검수자가 문장을 감으로 고치지 않게 됩니다.
루브릭은 평가 기준표를 뜻합니다. 기준표의 각 행에는 평가 항목, 통과 조건, 실패 조건, 권장 표현, 대표 사례를 넣고, 한 항목이 여러 의미를 동시에 평가하지 않도록 나눕니다. 예를 들어 정확성과 친절함을 한 점수로 묶지 말고 각각 판단하게 해야 어느 부분이 부족한지 알 수 있습니다.
<!– 시각자료 블록 –>
기준표에는 경계 사례를 반드시 넣습니다. 질문이 모호하거나 정보가 일부만 주어진 경우, 사용자가 단정을 요구하는 경우, 서로 충돌하는 자료가 입력된 경우가 대표적입니다. 정상적인 질문만 모으면 모델의 안정성을 과대평가하게 되므로 실제로 자주 실패하는 입력을 별도 묶음으로 관리해야 합니다.
표현을 고를 때는 단어 자체보다 독자가 받는 행동 신호를 확인합니다. “문제가 없습니다”는 위험이 없다는 인상을 주지만, “현재 확인된 범위에서는 문제가 발견되지 않았습니다”는 확인 범위를 남깁니다. 팀이 원하는 것은 더 공손한 문장이 아니라 오해 가능성을 줄이는 문장인지 먼저 합의해야 합니다.
사례와 평가 세트를 운영하는 방식
평가 세트(eval set)는 실제 입력과 기대하는 답변 방향을 묶어 둔 시험 자료입니다. 팀 내부에서 수집한 질문을 유형별로 정리하고, 각 질문에 대해 반드시 포함할 의미와 피해야 할 의미를 적으면 단어 선택을 재현 가능한 방식으로 비교할 수 있습니다. 성공 기준은 구체적이고 측정 가능하게 정하며, 정성 평가는 일관된 질적 척도로 운영할 수 있습니다.
평가 사례에는 정답 문장 하나만 넣지 않는 편이 좋습니다. 같은 의미를 전달하는 허용 표현을 여러 개 두고, 의미를 과장하거나 축소하는 표현은 실패 사례로 분리하면 문장 복사 여부가 아니라 의도 보존 여부를 평가할 수 있습니다.
Anthropic의 공식 평가 도구는 테스트 사례를 직접 추가하거나 생성 기능으로 만들고, CSV로 가져오는 방식을 제공합니다. 또한 여러 결과를 나란히 비교하고 5점 척도로 품질을 기록하며, 프롬프트 버전을 바꾼 뒤 같은 평가 세트를 다시 실행할 수 있습니다. 팀은 이 구조를 그대로 쓰거나, 스프레드시트와 내부 검수 화면으로 옮겨도 됩니다.
점수표에는 평가자의 근거를 남겨야 합니다. “어색함”처럼 주관적인 메모 대신 “확인되지 않은 사실을 확정형으로 표현함”, “사용자의 질문 범위를 넘어 권고함”처럼 관찰 가능한 이유를 적습니다. 그래야 다음 회의에서 취향 논쟁이 아니라 동일한 문장과 동일한 조건을 놓고 수정할 수 있습니다.
자동 평가와 사람의 검토는 역할이 다릅니다. OpenAI Graders처럼 문자열 확인, 텍스트 유사도, 모델 점수, 라벨 분류, 여러 평가 결과의 결합을 활용하면 반복 검사를 자동화할 수 있습니다. 다만 표현의 뉘앙스나 독자에게 생기는 오해는 자동 점수만으로 결정하지 말고 사람이 별도 확인해야 합니다.
자동화할 항목은 명확한 규칙부터 시작합니다. 금지된 표현의 포함 여부, 필수 문구의 누락 여부, 답변 형식 준수 여부는 기계가 빠르게 판정할 수 있습니다. 반대로 단정의 강도나 맥락에 맞는 공감처럼 의미 해석이 필요한 항목은 예시와 판정 근거를 함께 보여 주는 사람 평가가 적합합니다.
기준표를 프롬프트와 검수 절차에 연결하기
기준표를 만든 뒤에는 프롬프트에 단순히 “좋은 문체로 답하라”고 넣지 않습니다. 독자, 답변 목적, 확신 수준, 피해야 할 해석, 예외 상황을 짧은 규칙으로 바꾸고, 좋은 사례와 실패 사례를 함께 제공합니다. 규칙이 길어질수록 중요한 조건이 묻힐 수 있으므로 한 규칙에는 하나의 판단만 담습니다.
프롬프트 변경은 한 번에 여러 요소를 바꾸지 않는 방식으로 비교해야 합니다. 표현 지침, 예시, 출력 형식 중 무엇을 바꿨는지 기록하고 같은 평가 세트에서 이전 결과와 새 결과를 대조합니다. 개선된 문장이 늘었더라도 특정 질문 유형의 단정 표현이 증가했다면 전체 변경을 승인하지 않습니다.
Google은 일반 벤치마크만 사용하지 말고 실제 애플리케이션에 가까운 자체 평가 데이터를 함께 만들도록 안내합니다. 특히 안전이나 위험 경계와 관련된 시스템이라면 사용자가 직접 요구하는 명시적 공격 질의뿐 아니라, 간접적으로 문제를 유도하는 암시적 공격 질의도 넣어야 합니다.
이 원칙은 단어 선택 기준에도 적용됩니다. 사용자가 “확실하게 말해 달라”고 압박하는 질문, 일부 사실만 제공하고 결론을 요구하는 질문, 권위 있는 표현을 흉내 내도록 유도하는 질문을 별도 사례로 만들 수 있습니다. 이런 상황에서 모델이 확신 수준을 지키는지 확인하면 평상시 문장만 볼 때 놓치는 문제를 발견할 수 있습니다.
판정 권한도 미리 정합니다. 기준표를 처음 만든 사람, 도메인 담당자, 최종 승인자가 서로 다를 수 있으므로 각자의 역할과 이견 처리 방식을 문서화해야 합니다. NIST AI RMF도 AI 위험관리에서 역할과 책임을 명확히 하고, 시험 자료와 지표, 평가 방법을 기록하며, 운영 중에도 주기적으로 점검하는 방식을 제시합니다.
마지막으로 기준표에는 변경 이유를 남깁니다. 특정 표현을 금지한 이유가 오해 사례인지, 법무 검토인지, 사용자 피드백인지 표시하면 시간이 지난 뒤에도 규칙의 배경을 이해할 수 있습니다. 모델이나 서비스가 바뀌었을 때는 기존 문장이 그대로 작동한다고 가정하지 말고 동일한 사례로 다시 평가한 뒤 배포 여부를 결정합니다.
자주 묻는 질문 FAQ
Q1) 기준표에 권장 표현을 많이 넣을수록 더 좋은가요?
권장 표현의 개수보다 각각의 사용 조건이 분명한지가 중요합니다. 비슷한 표현을 많이 나열하면 검수자는 다시 개인 취향으로 선택하게 됩니다. 표현마다 전달하는 확신 수준과 사용하면 안 되는 상황을 함께 적어야 기준표가 실제 판단 도구로 작동합니다.
Q2) 사람 평가와 자동 평가 중 하나만 사용해도 되나요?
단순한 형식이나 특정 단어의 포함 여부는 자동 평가가 효율적입니다. 그러나 문맥에 따른 단정의 강도, 독자가 오해할 가능성, 답변의 태도는 사람의 판단이 필요합니다. 두 평가 결과가 다르면 실패 원인을 기록하고 기준표의 판정 조건을 보완하는 방식으로 운영합니다.
Q3) 기준표는 언제 다시 고쳐야 하나요?
새로운 실패 사례가 발견됐거나 서비스와 사용 목적이 바뀌었을 때 기준표를 검토해야 합니다. 프롬프트나 모델을 변경한 뒤 기존 평가 세트에서 결과가 달라져도 재검토 대상입니다. 변경 전후의 사례, 판정 근거, 승인자를 함께 남기면 팀의 단어 선택 원칙이 일회성 문서에 머물지 않습니다.