예시를 추가하면 오히려 나빠지는 문제도 있다. 소형 LLM으로 확인한 생성형 AI 테스트 방법

생성형 AI는 “예시를 추가하면 정확도가 올라간다”, “다시 검토하게 하면 실수가 줄어든다”는 말을 자주 듣습니다. 이러한 시도를, 효과를 검증하지 않은 채 사내 업무 방식에 무작정 도입하고 있지는 않으신가요?

2026년 10월 29일, 대표인 데라다 코스케이 강사를 맡은 모 기업의 사내 스터디에서 작은 언어 모델을 대상으로 이 두 가지 방법을 시험해 보았습니다. 예시를 추가하여 정답을 맞힌 문제가 있었던 반면, 같은 방식으로 인해 오히려 오답을 낸 문제도 있었습니다. 재검토를 요청하자 틀린 답을 “수정 사항 없음”이라며 단언한 문제도 있었습니다. 이 글에서는 당시의 결과와 생성형 AI를 업무에서 테스트할 때의 비교 방식을 정리합니다.

어떤 일이 일어나고 있는가

스터디는 총 3회 중 마지막 회차로, 온라인을 통해 90분 일정으로 진행되었습니다. 참가자들은 각자 자신의 PC에서 동일한 모델과 설정을 사용하여 테스트했습니다. 여기에 작성된 결과는 강사의 PC에서 확인한 내용입니다.

• 모델: Qwen2.5-3B-Instruct (Q4_K_M, 약 2.1GB)
• 앱: LM Studio
• 설정: Context 4096, Temperature 0 (매번 동일한 답변이 나오기 쉬운 설정), max tokens 1024

요즘의 챗 AI는 특별한 요령을 부리지 않아도 그럴듯하게 답변합니다. 예전 모델들은 다루기 어려워, 사람이 입력 방식을 연구하여 이를 보완했습니다. 그러한 노하우가 모델과 시스템에 반영되어 지금의 챗 AI가 되었습니다. 스터디에서는 이 흐름을 작은 모델을 통해 되짚어 보았습니다. 옛 도구를 직접 만들어 사용해 보는 ‘실험고고학’을 본뜬 방식입니다.

예시를 추가하자 오히려 결과가 나빠진 문제가 있었다

첫 번째 방법은 답변 방식의 예시를 먼저 2개 보여주는 것(Few-shot)입니다. 예시의 유무만을 다르게 설정하여 동일한 문제를 비교했습니다.

거스름돈 계산은 사과 1개 120엔짜리 3개와 귤 1개 80엔짜리 4개를 사고 1000엔 지폐로 지불하는 문제입니다. 예시가 없을 때는 올바르게 320엔이라고 답했으나, 예시를 추가하자 680엔이라고 답했습니다. 680엔은 대금의 합계로, 거스름돈과 혼동한 것입니다. 예약 문장에서 성명·날짜·시간·인원수를 추출하는 문제에서는 예시를 추가한 쪽에서 날짜 항목에 원문의 “(목)“이 그대로 남았습니다.

반면, 세 사람 중 누가 가장 늦은지를 묻는 문제에서는 예시가 없을 때 잘못된 C를 답했으나, 예시를 추가하자 정답인 B로 바뀌었습니다. 동일한 방법이라도 문제에 따라 결과가 좋아질 수도, 나빠질 수도 있습니다.

재검토를 요청하자, 오류를 “수정 없음”이라고 단언했다

두 번째 방법은 답변이 나온 후 동일한 대화 내에서 재검토를 요청하는 것(자체 점검)입니다. 5개 단어를 오십음도 순으로 배열하는 문제에서는 잘못된 배열 상태 그대로 “수정 사항 없음”이라고 단언했습니다. 세 사람의 속도를 묻는 문제에서는 재검토 도중에 세 사람의 순서를 올바르게 적었음에도 최종 답변은 여전히 C로 유지되었습니다.

동일한 설정에서도 답변이 흔들렸다

Temperature를 0으로 통일했음에도 재검토 후의 답변은 일정하지 않았습니다. 강사의 PC에서 세 사람의 속도를 묻는 문제의 재검토를 8회 시도해 본 결과, 정답인 B가 나온 것은 단 1회뿐이었습니다.

여기까지의 결과는 3B 크기의 작은 모델을 강사의 PC 1대에서 테스트한, 5개 문제에 불과한 기록입니다. 현재의 대형 챗 AI에서도 동일한 결과가 나올지는 확인하지 않았습니다.

자주 겪는 시행착오

작은 모델에서 발생한 문제는 업무에서 생성형 AI를 테스트할 때 겪는 시행착오와 맞닿아 있습니다.

매끄러운 답변을 정확성의 증거로 삼는다

답변이 빠르고 문장이 정돈되어 있으면 정확해 보입니다. 스터디에서는 매끄러운 설명도, “확인했습니다”라는 답변도 근거로 삼지 않고, 오직 최종 답변만을 정답과 대조했습니다.

한 번에 여러 조건을 변경한다

예시를 추가하고, 표현을 바꾸고, 모델까지 변경하면 어떤 변경 사항 때문에 결과가 달라졌는지 알 수 없습니다. 스터디에서도 변경 사항은 매번 1개로 제한했으며, 조건마다 새로운 대화를 시작했습니다. 단, 재검토만은 동일한 대화 내에서 이어서 요청했습니다.

1회의 결과만으로 판단한다

세 사람의 속도를 묻는 문제처럼 동일한 설정에서도 답변이 흔들리는 문제가 있습니다. 한 번 성공한 것도, 한 번 실패한 것만으로는 판단의 근거가 될 수 없습니다.

좋아진 사례만 남긴다

새로운 방식을 시도하면 개선된 결과만 기억하기 쉽습니다. 거스름돈 계산처럼 원래 맞았던 답이 조치로 인해 오답으로 바뀌는 경우도 있습니다.

어떻게 진행해야 하는가

생성형 AI를 업무에서 테스트할 때는 다음 순서로 진행하면 무엇을 알게 되었는지 설명하기 수월해집니다.

1. 업무에서 실제로 요청하고자 하는 문제를 몇 가지 선정하고, 정답 또는 합격 조건을 먼저 정의한다
2. 조건을 1개만 변경하여 변경 전과 후를 나란히 비교한다
3. 동일한 문제를 여러 차례 반복한다
4. 내용(정확한가)·형식(지정된 양식대로 작성했는가)·완료(끝까지 작성했는가)·시간이라는 4가지 기준으로 기록하며, 좋아진 사례와 나빠진 사례를 모두 남긴다
5. 도입 여부와 어떤 업무에 활용할지는 기록을 바탕으로 사람이 결정한다

이러한 비교 방식은 모델의 규모가 커지더라도 동일하게 적용할 수 있다고 생각합니다.

Cor.주식회사에서는 생성형 AI 및 로컬 LLM의 도입과 교육을 지원하고 있습니다. 이 과정에서 업무에 맞춘 문제 선정 방식과 기록 방법을 함께 정리해 드릴 수 있습니다. 초기 상담 단계에서 업무 실제 데이터나 기밀 문서, 인증 정보를 전송하실 필요는 없습니다.

요약

스터디의 마지막에는 두 가지 방법의 이후 발전 과정을 되돌아보았습니다. 예시를 보여주는 방식은 지시를 따르도록 모델을 학습시키는 방향으로 발전했습니다. 재검토를 요청하는 방식은 생각한 뒤 답변하는 모델이나 답변을 검증하는 시스템으로 발전했습니다. 두 가지 모두 현재의 챗 AI 내부에 반영되어 있다는 이야기로 마무리했습니다. 그렇다고 해도 유창하게 답변하는 것과 올바른 것은 별개의 문제입니다.

예시 추가나 재검토를 통해 결과가 좋아지는 문제도 있지만, 나빠지는 문제도 있습니다. 새로운 방식을 테스트할 때는 정답을 먼저 정의하고, 한 번에 하나씩만 변경하며, 여러 번 반복하여 개선된 사례와 악화된 사례를 모두 기록해야 합니다. 도입 여부는 그 기록을 보고 사람이 판단해야 합니다.

참고 자료

• Qwen2.5-3B-Instruct-GGUF (Qwen, Hugging Face)
• LM Studio Docs
• Brown et al., “Language Models are Few-Shot Learners” (2020, arXiv:2005.14165)
• Ouyang et al., “Training language models to follow instructions with human feedback” (2022, arXiv:2203.02155)
• Huang et al., “Large Language Models Cannot Self-Correct Reasoning Yet” (2023, arXiv:2310.01798)