MZ._.GPT

IBM STAIR의 실용성 검토: 목차 기반 검색부터 Hybrid RAG, GraphRAG, 온톨로지까지 뭐가 가장 좋을까?최근 공개된 문서의 목차를 활용해 질문에 답할 섹션을 찾는 IBM의 STAIR 논문을 살펴봤습니다. 검색 결과를 보면 기존 비교군보다 성능이 높습니다. 다만 실제 문서와 질문을 기준으로 생각하면, 그 수치만으로 검색 구조를 바꿔도 되는지는 별개의 문제입니다. 제품 상세 페이지와 FAQ에는 일관된 목차가 없을 수 있습니다. 긴 매뉴얼에 목차가 있더라도 필요한 예외나 변경 사항까지 한 항목에서 찾을 수 있다는 보장은 없습니다. 구조를 새로 추출하고 검색 모델을 학습해야 한다면, 그 비용도 성능과 함께 따져야 합니다. 이 글은 IBM STAIR를 먼저 소개한 뒤, 논문에서 확인한 성과를 ..

2026년 9월 22일 기준TypeSafe AI는 2026년 9월 15일 판단 작업에 특화한 모델 Jev를 얼리 액세스로 공개했습니다. 회사가 System One 모델로 명명한 제품군의 첫 번째 모델입니다. 자연어로 작성한 자료와 판단 기준을 입력받고, 자유로운 설명문 대신 선택 결과·점수·확률을 반환합니다.Jev를 검토할 때 중요한 것은 범용 LLM보다 모든 작업을 잘하는지 여부가 아닙니다. 생성이 필요 없는 분류·판정·평가 작업에서 필요한 정확도를 유지하면서 비용과 지연을 줄일 수 있는지가 핵심입니다.공개 평가에서도 이러한 특성이 확인됩니다. TypeSafe의 네 가지 워크플로 평균 정확도는 67.8%로 최상위 모델보다 낮지만, 일부 모델과 비슷한 정확도를 훨씬 낮은 비용과 짧은 처리 시간으로 제공합..

콜센터 도메인 특화 STT 모델과 공개 모델·파인튜닝 변형을 포함한 총 6종을 비교했습니다. 자사 모델은 내부 실제 통화 평가셋에서 가장 낮은 CER를 기록했고, 공개 AI Hub 전화·상담 평가셋에서는 Whisper가 앞섰습니다. 이번 비교의 핵심은 특정 모델의 보편적인 우열이 아니라, 적용 환경과 평가 기준에 따라 모델의 강점이 달라진다는 점입니다. 시간 없으신 분들을 위해 단순하게 최종 결과 표 먼저 공유하도록 하겠습니다.한국어 ASR 6종 평가 결과 표 1. 왜 직접 비교했는가한국어 음성 인식 모델을 고를 때 가장 먼저 살펴보는 것은 공개 벤치마크 점수입니다. 하지만 우리가 실제로 운영하는 전화 환경은 공개 평가셋과 다를 수 있습니다. 낮은 대역의 전화 음성, “네”, “아니요” 같은 짧은 응답,..

"AICC STT, 고스펙 GPU가 정말 더 많은 요청을 처리할까?"H100·RTX PRO 6000·RTX 8000 실측으로 본 처리량과 비용 대비 효율AICC STT 서버를 구성할 때 일반적으로 고성능 GPU일수록 더 많은 요청을 처리할 것이라고 예상합니다.H100처럼 연산 성능과 메모리 대역폭이 높은 GPU를 사용하면 RTX 계열 GPU보다 처리량도 큰 폭으로 증가할 것이라는 판단입니다. 하드웨어 사양만 보면 자연스러운 예상입니다. 그러나 STT는 GPU에서 큰 행렬 연산만 반복하는 작업이 아닙니다. 음성 전처리, 인코더, 자기회귀 디코더, beam search, 후처리와 요청 스케줄링이 연결된 구조입니다. 따라서 실제로 확인해야 할 질문은 다음과 같습니다.H100의 높은 이론 성능이 STT 처리량에..

LLM을 실제 서비스에 적용할 때는 vLLM, SGLang과 같은 다양한 서빙 프레임워크를 사용하게 됩니다. 새로운 모델이 공개되면 우선 기존 서빙 환경에 올려보고 처리 속도, 동시성, 메모리 사용량 등을 확인합니다. 그런데 새 모델이 정상적으로 실행된다고 해서 항상 모델 설계대로 효율적으로 서빙되는 것은 아닙니다. 모델 아키텍처가 기존 모델과 다르거나, 서빙 프레임워크가 해당 구조를 아직 충분히 반영하지 못한 경우에는 기대보다 낮은 처리량이 나올 수 있습니다. 이때 단순히 모델이 무겁다거나 GPU 성능이 부족하다고 판단하면 실제 원인을 놓칠 수 있습니다. 특히 새로운 모델과 기존 모델, 또는 다른 후보 모델을 비교해야 하는 상황에서는 이러한 문제가 더 중요합니다. 서빙 프레임워크가 모델 구조를 제대로 ..

최근 AI 관련 직무에 있다 보면 자연스럽게 드는 고민이 있습니다. 에이전트가 코드를 짜주고 인프라까지 세팅해주는 시대에, 결국 사람한테 남는 일은 무엇일까 하는 것입니다. 최근 제가 일하면서 정리하게 된 생각을 적어보려고 합니다. 그냥 일기장 느낌의 글은 처음 써보는 것 같네요. 저는 크게 세 가지 영역을 다루고 있습니다. 인프라, AI 리서치, 그리고 AI 엔지니어(빌더) 쪽입니다. 영역마다 AI를 활용하는 정도와 사람이 개입해야 하는 지점이 조금씩 다르다고 느꼈습니다.인프라: 알고 하는 것과 모르고 하는 것의 차이요즘 쿠버네티스를 공부하고 있습니다. 사실 AI를 쓰면 세팅부터 Pod 구성까지 다 할 수 있습니다. 그럼에도 공부를 하는 이유는, 알고 하는 것과 모르고 하는 것이 다르기 때문입니다. 특..

기존 AICC(인공지능 콜센터)의 기본 아키텍처는 사용자의 음성을 텍스트로 변환(STT)한 뒤, 이를 LLM이 추론하여 텍스트 답변을 생성하고, 마지막으로 다시 음성으로 합성(TTS)하는 순차적 파이프라인 구조가 많았습니다. 하지만 이 방식은 각 모듈이 이전 단계의 처리가 끝날 때까지 대기해야 하는 차단(Blocking) 특성으로 인해, 아무리 최적화를 거쳐도 최소 800ms에서 1200ms에 이르는 물리적 지연(Latency)이 발생한다는 뚜렷한 한계가 존재했습니다. 이러한 병목 현상을 타개하기 위해 최근 AICC에서 연구가 집중된 분야가 바로 네이티브 멀티모달입니다. 기존처럼 오디오(INPUT) → 텍스트(STT) → 텍스트(LLM) → 오디오(TTS) → 오디오 스트리밍 출력(OUTPUT)의 무거운..

NVIDIA가 2026년 4월 21일, 서울 마포 프론트원에서 열린 'Nemotron Developer Days Seoul' 키노트에서 한국 시장 전용 데이터셋 Nemotron-Personas-Korea를 공개했습니다. 같은 날 Hugging Face에도 업로드되었고, 일반인에게 무료로 풀린 합성 페르소나 데이터셋으로는 한국어 기준 첫 사례입니다. 이 글에서는 이 데이터셋이 어떤 배경에서 만들어졌고, 어떻게 구성되어 있으며, 실제로 어떻게 쓸 수 있는지를 자료를 토대로 정리해 보았습니다.1. 왜 이런 데이터셋이 필요했는가NVIDIA가 공개한 사례 중 인상적인 부분이 있습니다. 한국에서 활동하는 글로벌 LLM들에게 한국인의 직업 분포를 추론하게 시키면, 어떤 모델은 한국인의 90%를 돌봄 제공자(careg..

서론: 응답 생성 -> 자율적 문제 해결(Agent)로의 패러다임 전환LLM의 발전은 단순한 텍스트 완성과 챗봇 형태의 일회성 상호작용을 넘어, 복잡한 워크플로우를 독립적으로 계획하고 실행하는 에이전트(Agentic) 시스템으로 이동하고 있습니다. 2026년 현재, 이러한 패러다임 전환의 중심에는 파라미터의 밀집도를 낮추면서도 추론(Reasoning) 및 실행 능력을 극대화한 Open-weights 모델들이 존재합니다. 최신 기술 동향을 가장 뚜렷하게 대변하는 대표적인 두 모델 제품군은 알리바바 클라우드(Alibaba Cloud)의 Qwen3.6 시리즈와 구글(Google)의 Gemma 4 생태계입니다. 과거의 언어 모델 설계가 매개변수(Parameter)의 단순한 양적 확장에 의존했다면, 최근 공개된 ..

최근 저희 사내 모든 부서(AI, 마케팅, 경영지원, 영업팀 등)가 공통으로 활용할 수 있는 업무 자동화 및 공유 지식 베이스 구축하고 있습니다. 로컬 LLM과 사내 메신저, 그리고 Hermes Agent를 결합해 각 부서별 업무 자동화 및 도메인 지식을 유기적으로 연결하는 것이 핵심입니다. 개인적으로 Andrej Karpathy의 'LLM Wiki' 아이디어를 차용해 VectorDB + GraphDB + Wiki를 결합하여 정보를 탐색하고 추론하는 에이전트를 개발하던 중이었는데요. 이번 Hermes Agent v0.8.0 업데이트에 'LLM Wiki Skills'가 공식적으로 추가되었길래 문서가 많지 않은 사내에서는 Wiki만으로도 어느정도 지식 베이스를 구축할 수 있을 것 같아서 적용해보려합니다. ..