The Model Swap Workshop: GPT-5.5 vs Kimi vs DeepSeek vs Mistral — Pamela Fox, Microsoft

한 줄 핵심

서로 다른 모델을 같은 과제로 바꿔가며 실행·평가해 보면서, 실제 사용 시에는 벤치마크보다 자신의 시나리오에 맞는 평가와 프롬프트 최적화가 더 중요하다는 점을 보여주는 실습형 워크숍이다.

시간별 요약

1. 0:00
   워크숍 준비 실습용 저장소와 환경 변수를 바탕으로 여러 Foundry 모델을 바로 바꿔가며 실행하는 방식으로 진행된다. 토큰 한도와 429 오류 가능성까지 고려해 예비 설정을 안내하고, 참가자가 로컬 Python이나 GitHub Codespace로 따라올 수 있게 한다.
2. 2:23
   왜 모델 교체가 필요한가 새 모델이 계속 등장하고, 특정 모델에 대한 접근이 언제든 제한될 수 있으므로 애플리케이션은 다른 모델로 쉽게 갈아탈 수 있어야 한다. 모델별 차이를 체감하고 개선 방법까지 알아야 AI 엔지니어링에서 유연하게 대응할 수 있다.
3. 3:08
   비교할 네 가지 모델 GPT-5.5, Kimi K2.6, DeepSeek V4 Flash, Mistral Large 3를 같은 환경에서 비교한다. 설치 방법과 실행 방식도 함께 정리해, 하나의 코드베이스로 모델만 바꿔가며 실험할 수 있게 만든다.
4. 5:18
   벤치마크와 실제 시나리오의 차이 일반 벤치마크 점수만으로는 실제 업무에서의 성능을 알 수 없고, 자신이 쓰는 구체적 작업에서 직접 시험해야 한다. 이 워크숍은 다양한 시나리오를 통해 모델의 실제 적합성을 확인하는 데 초점을 둔다.
5. 5:38
   알파벳 세기 테스트 아주 단순한 단일 LLM 호출에서조차 모델마다 정답률이 다르게 나온다. GPT-3.5와 Kimi는 맞히지만 DeepSeek와 Mistral은 틀려서, 기본 산술·주의력에서도 차이가 드러난다.
6. 7:48
   프롬프트로 성능 보정하기 문장을 단어별로 나누고 단계적으로 세게 만드는 식의 프롬프트 수정만으로 Mistral의 결과가 개선된다. 같은 모델이라도 지시 방식에 따라 출력 품질이 크게 달라질 수 있음을 보여준다.
7. 8:38
   RAG와 근거성 테스트 질문에 답하되 주어진 자료에만 근거해야 하는 RAG 상황에서는, 모델이 자기 가중치의 지식을 끼워 넣는지 여부가 핵심이다. GPT-5.5와 DeepSeek는 근거 밖 내용을 잘 멈추는 반면, Mistral은 소스에 없는 내용을 섞어 말해 groundedness가 약했다.
8. 13:03
   이미지 입력 테스트 이미지 이해에서는 아우로크스, 악어 구분, 작은 글씨의 표에서 최저가 항목 찾기 같은 작업으로 멀티모달 성능을 본다. GPT-5.5와 Kimi는 잘 처리했지만, Mistral은 일부 이미지를 잘못 읽어 시각적 이해력 차이가 확인된다.
9. 16:18
   언어 전환 같은 멀티모달 과제라도 영어가 아닌 스페인어로 바꾸면 갑자기 성능이 흔들릴 수 있다. 다국어 지원이 필요한 서비스에서는 언어별 성능 편차를 별도로 확인해야 한다.
10. 17:13
    도구 호출 테스트 함수 정의를 JSON schema로 제공하면 모델이 어떤 도구를 어떤 인자로 호출할지 스스로 고른다. 이 단계에서 이름, 설명, 파라미터 설계가 곧 프롬프트 엔지니어링이며, 모델마다 인자 해석의 정확도가 다르다.
11. 21:03
    루프 안의 도구 호출 계산기 도구를 반복 호출하게 하여 복잡한 문제를 풀게 하면, 정답 여부뿐 아니라 호출 횟수와 효율성이 중요한 평가 기준이 된다. GPT-5.5는 한 번에 끝내지만 다른 모델은 여러 번 왕복해 네트워크 비용이 늘어난다.
12. 23:58
    LangChain v1으로 에이전트 만들기 여행 계획 에이전트를 통해 도구 호출 루프를 실제 에이전트 구조로 확장한다. 같은 과제라도 프레임워크별 루프 구현이 다르고, 모델이 도구를 순차적으로 쓰는지 병렬로 쓰는지에 따라 성능이 크게 달라진다.
13. 26:17
    병렬 도구 호출 서로 독립적인 작업은 같은 턴에서 병렬로 실행하는 편이 더 효율적이다. GPT-5.5는 항공편과 호텔 검색을 병렬로 처리해 가장 효율적이었지만, 다른 모델은 병렬화가 약하거나 누락돼 도구 호출 수가 늘었다.
14. 30:27
    문자열 검사 기반 평가 단일 도구 호출에서는 반환된 문자열이나 인자를 직접 비교하는 간단한 평가로도 충분하다. 다만 실서비스에서는 새로운 사용자 사례가 계속 생기므로, 실제 입력을 평가셋에 빠르게 반영하는 체계가 필요하다.
15. 33:42
    평가 프레임워크에 대한 질의응답 LangFuse, LangSmith, Azure AI evaluation SDK, OpenAI.evals, DeepEval 같은 다양한 평가 도구가 소개된다. 단순 문자열 검사는 간단한 검증에 충분하지만, 병렬화나 복잡한 에이전트 평가에는 더 정교한 도구가 필요하다.
16. 35:12
    판정자로서의 LLM 출력이 모호한 경우에는 또 다른 LLM을 판정자로 써서 통과·실패와 사유를 판단하게 한다. 다만 이 방식은 느리고 비용이 크며, 평가자 자체의 품질도 인간 라벨과 맞춰 검증해야 한다.
17. 40:07
    명세로부터 평가 만들기 Microsoft Research의 Assert는 YAML 명세를 바탕으로 평가 기준과 테스트 시나리오를 자동으로 구체화한다. 사람이 일일이 테스트셋을 설계하기 어려운 문제를 줄이고, 실제 배포 전 평가를 빠르게 부트스트랩할 수 있다.
18. 43:32
    모델별 평가 결과 비교 Assert로 만든 평가를 여러 모델에 돌리면, 단순 감이 아니라 수치로 어떤 모델이 덜 위반하는지 확인할 수 있다. 이 실험에서는 GPT-5.5가 가장 낮은 위반 점수를 보여, 해당 시나리오에서 가장 안정적이었다.
19. 45:52
    DSPy를 이용한 프롬프트 최적화 프롬프트를 사람이 손으로 조정하는 대신, 제약 조건과 검사를 코드로 적고 DSPy가 그 조건을 만족하는 프롬프트를 찾아가게 한다. 제약을 만족하는지 평가하면서 점진적으로 프롬프트를 최적화하는 방식이라 모델 독립성이 높아진다.
20. 47:52
    Mistral용 DSPy 프롬프트 DSPy가 생성한 시스템 프롬프트는 특히 Mistral처럼 성능이 까다로운 모델에서 유용하다. 더 작은 모델에서도 원하는 결과를 얻을 수 있어 비용을 낮추고 배포 유연성을 높일 수 있다.
21. 49:22
    Anthropic과 인용 기능 Anthropic은 별도 API를 쓰지만, RAG에서 인용(citations)을 구조화된 형태로 반환하는 점이 강점이다. 프론트엔드에서 출처 링크를 쉽게 연결할 수 있어 근거 제시가 중요한 서비스에 특히 유리하다.
22. 50:32
    마무리 여러 모델을 직접 바꿔 보며 차이를 관찰하고, 평가와 최적화를 통해 지속적으로 개선하는 흐름이 핵심이다. 저장소는 계속 열려 있고, 로컬 llama 같은 다른 모델로도 같은 실험을 이어갈 수 있다.

실무 인사이트

• 실제 운영에서는 단일 벤치마크보다 자신의 도메인 시나리오를 그대로 테스트하는 평가셋이 훨씬 중요하다.
• RAG, 도구 호출, 에이전트는 정답률만이 아니라 근거성, 호출 효율, 병렬화 여부까지 함께 봐야 한다.
• 프롬프트를 수동 조정하는 대신, 평가 기반 최적화(DSPy 같은 접근)로 모델 교체 비용을 줄이는 전략이 효과적이다.