Gemini 모델 A/B 테스트: 3.5 flash vs 3.1 flash-lite
검색형 Assistant의 모델을 교체할 때, 보통은 최종 답변만 비교하기 쉽다. 하지만 같은 정답을 내더라도 한 모델은 검색 결과 하나만 보고 답하고, 다른 모델은 추가 문맥과 예외 조건까지 확인한 뒤 답할 수 있다.
이번에는 gemini-3.5-flash와 gemini-3.1-flash-lite를 대상으로 다음 가정을 확인했다.
gemini-3.5-flash는 검색 및 Tool Calling을 더 적극적으로 수행하며, 그 차이가 최종 정답성으로도 이어질 것이다.
실험 결과, Retrieval 깊이의 차이는 분명했지만 정답률 차이는 관측되지 않았다. 두 모델이 같은 결론에 도달하는 과정은 상당히 달랐고, 그 차이를 어떻게 평가해야 하는지가 이번 테스트의 핵심이었다.
실제 사례와 문서는 특정 제품 및 전문 도메인을 식별할 수 없도록 일반화했다. 원문 질의, 문서 내용, 내부 도구 이름과 시스템 식별자는 포함하지 않았다. 이 글은 검색형 QA의 실행 특성을 비교한 것으로, 특정 전문 분야의 유효성이나 실제 업무 적합성을 검증한 평가는 아니다.
I. 무엇을 비교할 것인가
두 모델 모두 Function Calling을 지원한다. 다만 공식 설명에서 gemini-3.5-flash는 복잡한 추론과 Agentic workflow에, gemini-3.1-flash-lite는 대량의 비교적 가벼운 작업과 낮은 지연 시간에 초점을 둔다.
따라서 아래 세 가지 가설을 세웠다.
- Retrieval 깊이: 3.5가 검색을 반복하거나 상세 문맥 조회 도구를 더 자주 사용할 것이다.
- 최종 정답성: 더 깊게 검색한 결과가 어려운 사례의 판정 정확도를 높일 것이다.
- Clarification(추가 정보 요청): 정보가 부족한 질의에서 3.5가 사용자에게 필요한 정보를 더 안정적으로 요청할 것이다.
여기서 중요한 점은 Retrieval 깊이와 정답성을 별도 지표로 분리한 것이다.
1
2
검색을 많이 했다 ≠ 정답이다
검색을 적게 했다 ≠ 근거가 부족하다
Tool Calling의 횟수는 답변을 만드는 과정에 대한 지표이고, 정답 여부는 결과에 대한 지표다. 둘을 한 지표로 묶으면 “열심히 검색한 답변”을 “정확한 답변”으로 오해하기 쉽다.
II. 테스트 대상 구조
테스트한 Assistant는 모델 설정과 실행 구조가 분리되어 있다. 공통 모델 팩토리에서 모델만 교체하고, Agent와 Tool의 구성은 그대로 유지할 수 있다.
flowchart LR
A[Test Client] -->|질의| B[SSE API]
B --> C[Application Use Case]
C --> D[Agent Runner]
D <--> E[LLM]
D --> F[Request-scoped Tool Registry]
F --> G[문서 검색]
F --> H[상세 문맥 조회]
F --> I[Clarification]
G --> J[Document Corpus]
H --> J
D -->|tool_call / result / error / token| B
B -->|SSE Event| A
Retrieval은 크게 두 단계로 동작한다.
- 문서 검색: 질의와 관련된 후보 문서를 찾는다.
- 상세 문맥 조회: 검색 결과의 앞뒤 문맥을 추가로 읽는다.
모델은 첫 검색 결과만으로 답할 수도 있고, 문맥이 부족하다고 판단하면 검색을 반복하거나 상세 문맥을 조회할 수도 있다. 질의에 필요한 조건 자체가 부족하다면 Clarification 도구를 호출할 수 있다.
SSE에서는 다음 이벤트를 관찰할 수 있도록 구성되어 있었다.
| 이벤트 | 확인한 내용 |
|---|---|
tool_call | 어떤 종류의 도구를 몇 번 호출했는가 |
tool_result | 검색 또는 문맥 조회가 정상적으로 끝났는가 |
tool_error | 도구 실행 중 오류가 발생했는가 |
token | 최종 답변이 정상적으로 생성되었는가 |
done / error | 실행이 정상 종료되었는가 |
최종 답변만 저장해서 비교한 것이 아니라, 모델이 답을 찾는 과정 전체를 이벤트 단위로 확인했다.
III. 실험 방법
1. 모델 이외의 조건 고정
비교 시 변경한 값은 모델 식별자뿐이다.
- 동일한 Agent 코드
- 동일한 System Prompt
- 동일한 Tool 구성
- 동일한 검색 코퍼스
- 동일한 질의
- 동일한 실행 제한
모델 설정을 변경한 뒤 실행 인스턴스를 새로 만들었으며, 각 Run은 새 대화에서 시작했다. 이전 대화의 요약이나 최근 메시지가 다음 Run에 영향을 주지 않도록 대화를 격리했다.
2. 테스트 구성
테스트는 세 단계로 나눴다.
| 단계 | 목적 | 사례 수 | 반복 |
|---|---|---|---|
| Tool Calling 기본 동작 | 두 모델에서 Tool 연동이 정상인지 확인 | 6종 | 각 1회 |
| Clarification 동작 | 조건이 부족한 질의에서 추가 정보를 요청하는지 확인 | 2종 | 각 5회 |
| 정답성 | 정형 사례와 검색이 어려운 사례의 최종 판정 확인 | 정형 3종 + 하드 3종 | 각 5회 |
하드 사례는 일반적인 질문을 임의로 만든 것이 아니라, 테스트 코퍼스 원문을 직접 읽고 구성했다.
- 검색 결과 안쪽에 근거가 묻혀 있는 사례
- 여러 조건을 함께 해석해야 하는 사례
- 본문이 아닌 예외 문구까지 읽어야 하는 사례
정답 역시 검색 결과의 요약문이 아니라 원본 문서에서 직접 확정했다.
3. 과정과 결과를 분리한 채점
| 구분 | 측정 항목 |
|---|---|
| Retrieval 과정 | 검색 횟수, 상세 문맥 조회, Clarification 호출 |
| 실행 안정성 | Tool 오류, 최종 실행 실패 |
| 최종 결과 | 기대 판정과의 일치 여부 |
| 답변 품질 | 조건, 예외, 근거를 얼마나 구체적으로 설명했는가 |
정답성은 답변 원문을 직접 읽어 판정했다. 초기에는 키워드 기반 자동 채점을 시도했지만, 한국어의 조사와 어미 변화, 조건문, 부정 표현을 안정적으로 구분하지 못해 폐기했다.
IV. 실험 결과
1. 기본 Tool Calling
6개의 기본 시나리오에서는 두 모델 모두 정상적으로 도구를 호출했다.
| 항목 | gemini-3.5-flash | gemini-3.1-flash-lite |
|---|---|---|
| Tool 오류 | 0건 | 0건 |
| 최종 실행 실패 | 0건 | 0건 |
이 결과는 두 모델이 현재 Tool 계약과 호환된다는 의미다. 6회만으로 안정성이나 성능이 동등하다고 판단할 수는 없다.
2. Clarification 동작
조건이 부족한 두 종류의 질의를 각각 5회 반복했다.
| 사례 | gemini-3.5-flash | gemini-3.1-flash-lite |
|---|---|---|
| 조건 부족 A | 3/5회 Clarification, 실행 실패 1건 | 5/5회 Clarification |
| 조건 부족 B | 1/5회 Clarification | 0/5회 Clarification |
한 사례에서는 3.1이 Clarification을 더 자주 요청했고, 다른 사례에서는 3.5만 요청했다. 즉, 3.5가 일관되게 우세하다는 패턴은 없었다.
두 모델 모두 특정 종류의 필수 조건을 안정적으로 확인하지 못했다. 이 문제는 모델 선택보다 “어떤 조건에서 반드시 Clarification을 요청해야 하는가”를 Prompt와 Tool policy에 더 명확히 정의해야 할 가능성이 크다.
3. 정형 사례
정형 사례 3종을 각각 5회 실행했다.
- 정상 완료된 답변의 최종 판정은 두 모델 모두 기대값과 일치했다.
gemini-3.5-flash에서는 실행 실패가 1건 발생했다.gemini-3.1-flash-lite에서는 실행 실패가 없었다.
실행 실패를 제외한 답변만 놓고 보면 판정 차이는 없었지만, 실패한 Run을 정답으로 처리해서는 안 된다. 따라서 이 결과를 단순히 “두 모델 모두 15/15”로 표현하지 않았다.
4. 하드 사례
하드 사례에서는 최종 정답과 Retrieval 과정을 함께 비교했다.
| 사례 | 확인할 내용 | gemini-3.5-flash | gemini-3.1-flash-lite |
|---|---|---|---|
| Hard A | 묻힌 근거와 경쟁 검색 결과 구분 | 5/5 | 5/5 |
| Hard B | 여러 조건을 조합한 판정 | 5/5 | 5/5 |
| Hard C | 예외 문구를 반영한 판정 | 5/5 | 5/5 |
| 합계 | 최종 판정 | 15/15 | 15/15 |
세 종류의 하드 사례를 각각 5회 실행했을 때, 두 모델의 모든 답변이 기대 판정과 일치했다. 다만 답을 찾는 방식은 크게 달랐다.
| Retrieval 동작 | gemini-3.5-flash | gemini-3.1-flash-lite |
|---|---|---|
| 기본 패턴 | 검색 반복 후 상세 문맥 확인 | 첫 검색 후 바로 답변 |
| Hard A 상세 문맥 조회 | 5/5회 | 0/5회 |
| 하드 사례 전체 상세 문맥 조회 | 반복적으로 사용 | 0/15회 |
| 검색 깊이 | 일부 Run에서 최대 7회까지 검색 | 일관된 단발 검색 |
| 답변 서술 | 조건과 예외를 비교적 구체적으로 명시 | 필요한 판정을 간결하게 제시 |
gemini-3.5-flash는 검색 결과를 바로 신뢰하기보다 주변 문맥을 추가로 확인하는 경향이 명확했다. 반면 gemini-3.1-flash-lite는 첫 검색 결과에 필요한 근거가 있으면 추가 조회 없이 답을 완성했다.
Retrieval 깊이의 차이는 실재했고 반복 실행에서도 재현되었다. 하지만 이번 하드 사례에서는 그 차이가 최종 판정의 차이로 이어지지 않았다.
V. 더 깊게 검색했는데 왜 정답률은 같았을까
1. 첫 검색 결과만으로도 판정에 충분했다
현재 코퍼스와 질의에서는 첫 검색이 이미 정답 근거를 포함한 결과를 상위에 노출했다. 3.1은 해당 근거만으로 판정을 끝냈고, 3.5는 같은 결론을 상세 문맥에서 다시 확인했다.
1
2
3
4
5
gemini-3.1-flash-lite
검색 → 충분한 근거 발견 → 답변
gemini-3.5-flash
검색 → 추가 검색 → 상세 문맥 확인 → 답변
3.5의 추가 조회가 무의미하다는 뜻은 아니다. 이번 테스트 범위에서는 판정을 바꾸는 새로운 근거보다 기존 근거를 보강하는 정보를 더 많이 가져왔다.
2. 판정 정확도와 설명 충실도는 다른 지표다
최종 판정을 맞음/틀림으로만 평가하면 두 모델은 같았다. 그러나 3.5의 답변은 적용 조건, 예외, 부가 설명을 더 구체적으로 포함하는 경우가 많았다.
이 차이를 정답률에 포함하려면 별도의 평가 기준이 필요하다.
- 필수 조건을 빠짐없이 설명했는가
- 예외 조건을 명시했는가
- 인용한 근거가 답변을 실제로 뒷받침하는가
- 검색 결과에 없는 내용을 추가하지 않았는가
이번 실험에서는 이 항목을 사전에 점수화하지 않았기 때문에, 3.5의 답변이 더 풍부했다는 관찰까지만 가능하다. 상세 문맥 조회가 풍부한 서술의 직접 원인이라고 단정할 수도 없다.
3. 추가 검색에는 비용이 따른다
3.5는 더 많은 Tool 호출을 사용했고 응답 완료까지 기다리는 시간도 더 길게 관찰되었다. 반복 검색은 지연 시간뿐 아니라 Tool 실패에 노출되는 횟수도 증가시킨다.
다만 이번 테스트에서는 지연 시간, Token, 실제 비용을 별도의 측정값으로 수집하지 않았다. 따라서 “몇 배 느리다”거나 “얼마나 비싸다”는 식의 정량 결론은 내릴 수 없다.
1
2
조건을 충족하면 가능하다.
조건을 충족하지 않으면 가능하지 않다.
최종적으로 자동 채점 결과를 버리고 답변 원문을 읽어 판정을 다시 확정했다. 다음 실험에서는 실행 전에 아래와 같은 고정 Rubric을 먼저 정의하는 편이 낫다.
| 평가 항목 | 기준 |
|---|---|
| 최종 판정 | 기준 답안과 일치하는가 |
| 필수 근거 | 답변에 반드시 필요한 사실이 포함되었는가 |
| 조건과 예외 | 적용 범위와 예외를 정확히 설명했는가 |
| 근거 없는 주장 | 검색 문서에 없는 내용을 추가했는가 |
| 인용 정확성 | 인용이 실제 주장과 연결되는가 |
가능하다면 모델 이름을 가린 상태에서 사람이 교차 검토하고, LLM Judge는 보조 지표로만 사용하는 것이 안전하다.
4. 입력은 끝까지 동일하게 유지해야 한다
모델별 결과를 보고 질의를 조금씩 다듬으면 더 이상 같은 조건의 비교가 아니다. 이번 재실험에서는 질의와 시스템 조건을 유지하고, 반복 횟수와 채점 방법만 보강했다.
VI. 어떻게 해석할 것인가
이번 결과만으로 한 모델이 다른 모델보다 정확하다고 말할 수는 없다. 선택 기준은 Assistant에서 무엇을 우선하는지에 따라 달라진다.
| 우선순위 | 해석 |
|---|---|
| 복잡한 문서에서 근거를 더 확인하는 성향 | 3.5의 다단계 Retrieval이 정성적 안전 여유가 될 수 있음 |
| 간결한 판정과 적은 Tool 호출 | 3.1도 합리적인 후보 |
| 지연 시간과 비용 | 실제 Latency, Token, 호출 비용을 추가 측정해야 함 |
| 안정적인 Clarification | 모델 교체보다 Prompt와 Tool policy 개선이 우선 |
방어 가능한 결론은 다음 정도다.
gemini-3.5-flash는 상세 문맥 조회를 포함한 다단계 Retrieval을 일관되게 수행했고,gemini-3.1-flash-lite는 단발 검색으로 답하는 경향을 보였다. 그러나 정형 사례와 세 종류의 하드 사례에서는 두 모델 간 최종 판정의 정확도 차이가 관측되지 않았다. 3.5의 장점은 이번 테스트에서 증명된 정답성 우위가 아니라 어려운 사례를 한 번 더 확인하는 성향과 답변 서술의 풍부함이었다. 반대로 적은 Tool 호출과 빠른 응답이 중요하다면 3.1도 검토할 수 있으며, 최종 선택에는 더 넓은 코퍼스와 정량적인 Latency·비용 측정이 필요하다.