약 6년 전에 티켓 분류·라우팅 모델과 파이프라인을 만들었음. 초기 버전은 SVM으로 학습했는데, 학습에는 몇 분, 티켓 분류에는 몇 밀리초밖에 걸리지 않았음. 분야 전체가 LLM으로 옮겨갔다가 다시 더 빠르고 저렴한 분류기로 돌아오는 모습이 흥미로움.
논문은 “Linnaeus: A highly reusable and adaptable ML based log classification pipeline”이며, 2021년 International Conference on Software Engineering(ICSE)에 채택됨. https://arxiv.org/abs/2103.06927.
SVM은 2010년에도 맵리듀스로 확장할 수 있어 빅데이터 분야에서 인기가 있었음. 다만 기업들이 여러 고객의 데이터를 합쳐 학습하는 것을 허용하지 않았다는 제약이 있었음. SVM의 각 차원은 조금만 들여다보면 해석할 수 있으니 이해할 만한 제한이며, 범용 데이터셋도 과제에 따라 적합하지 않았음.
결국 매번 처음부터 시작해 특징을 일일이 주석 처리해야 했고, 전체 학습 데이터도 부족한 경우가 많았음. LLM은 기존 규칙을 무시하고 모든 데이터로 학습해 필요한 세상 지식을 끌어들이는 식으로 이를 ‘해결’함. 앞으로 LLM과 기존 머신러닝의 조합을 많이 보게 될 듯함.
LLM의 장점이자 잠재적 위험은 전문 지식 없이도 온갖 작업에 적용할 수 있다는 것임. SVM을 만드는 일 자체는 어렵지 않지만, 보통 데이터 과학자의 참여와 신중한 레이블 데이터셋 설계가 필요함.
모델링 분야에서도 Electron 앱 같은 현상이 나타나는 듯함. 자원을 많이 낭비하는 대신 개발은 쉬워지는 셈임. LLM 비용 변화에 따라 이 흐름이 얼마나 달라질지 궁금함.
달라진 것은 비싼 모델을 즉시 배포해 학습 데이터를 생성하다가, 자체적인 저렴한 모델로 갈아탈 수 있다는 점임. 학습이 몇 분밖에 걸리지 않았다는 계산에는 데이터 수집과 레이블링 작업이 빠져 있음.
이런 변화는 더 자주 나타날 것 같음. 소프트웨어 공학에서는 거대한 모놀리식 구조가 해답이 아니라는 사실을 오래전에 배웠음. 작고 전문화된 구성 요소들의 협업이 개별 작업의 성능과 유지보수에 유리하고, 다른 부분에 영향을 주지 않으면서 일부만 업그레이드하기도 쉬움. 왜 모든 것을 할 수 있는 단일 모델에 집중하는지 모르겠음.
로그 행의 임베딩으로 ‘블랙 스완’ 같은 이례적인 사건을 탐지하는 아이디어를 떠올린 적이 있음. 로컬에서 실행하는 작은 모델이면 충분하고, 이후에는 주성분 분석(PCA)이나 SVM 같은 전통적인 방법을 쓰면 될 듯함. 직접 본 적은 없지만 어딘가에서는 이미 시도했을 것 같음.
티켓 100만 건당 약 21,700달러 절감이라면, 연간 200만 달러를 아끼려면 적어도 9,200만 건을 처리해야 한다는 계산인데 맞는지 궁금함.
처음에는 고객 지원이나 내부 JIRA 티켓만 생각했지만, 글에 경보·보안 탐지 결과·용량 증설 요청도 나와서 그 정도 규모가 좀 더 그럴듯하게 느껴짐. 그래도 이렇게 많은 티켓이 시스템을 거친다는 사실은 놀라움.
정말 모든 일에 티켓이 생김. 퇴사한 지 수십 년이 지난 사람 이름으로도 티켓이 생성됨.
AWS가 관리하는 VPN 지점 간 연결을 쓴다면 이해가 감. VPN 인스턴스마다 매주 AWS 메일이 끝없이 오고, 결국 휴지통에 넣어야 함.
글이 상당히 혼란스러움. Strands Decider를 시험한 뒤 Gemma를 선택했다고 해놓고, 이후에도 사용한 모델을 Strands Decider라고 부름. 내가 놓친 부분이 있는 건가?
Seldon AI(www.seldon-ai.com) 창업자임. 이런 리팩터링과 지속적인 운영 작업을 돕는 개발 도구를 만들고 있음. 요즘 애플리케이션 백엔드에는 LLM을 적용했다가 빠져나오기 어려워지는 용도가 많음. LLM 덕분에 만들 수는 있지만 실제 서비스로 운영하거나 유지보수할 수는 없는 시스템이 생기는 것임.
예전에는 데이터를 수집·정제하고 ML 모델 파이프라인을 학습시켜 서비스해야 했던 기능을, 이제는 AI/ML 지식이 없는 개발자도 LLM으로 시제품까지 구현할 수 있음. 하지만 실제 서비스에 투입하면 시제품·베타 단계의 20달러 비용이 월 3만 달러로 뛰고, 테스트 표본 200개에서는 없던 환각이 하루 600번씩 발생함.
개발자는 운영용 ML 파이프라인과 인프라를 제대로 구축할 지식과 예산이 없어 막히고, 경영진은 ‘잘 작동하는 것처럼 보이는’ 기능을 왜 ‘구식 방법’으로 다시 만들어야 하는지 이해하지 못함.
시스템 1 모델이나 의사결정 모델은 이런 용도에서 LLM보다 한 단계 나은 접근이지만, 표현력이 제한돼 여러 애플리케이션 로직에 적용하기가 여전히 어려움. 초기 인기에 비해 LLM 기반 백엔드를 이 모델들로 리팩터링하는 과정에서 마찰이 많고, 운영 환경에서 LLM으로 되돌린 경우도 여러 번 접함. 방향은 타당하고 큰 진전도 가까워 보이지만, 제대로 작동하게 하려면 모델 위 계층에서 더 많은 작업이 필요함.
같은 내용을 보내도 JSON 키 순서만 바꾸면 출력 확률이 최대 0.19까지 달라졌다는데, 이건 해로운 특성 아닌가?
애초에 왜 Sonnet을 선택했을까? Haiku나 GPT Luna, 혹은 작고 저렴한 중국 모델을 선택할 수도 있지 않았을까?
정확도 때문인 듯함. 작은 모델은 부정확성이 너무 커서 실용적이지 않을 수 있음.
꼭 작은 중국 모델일 필요도 없을 듯함. Amazon은 더 큰 중국 모델도 토큰당 낮은 비용으로 실행할 하드웨어와 인프라를 갖췄을 것임. Sonnet도 자체 인프라에서 추론하니 할인받을 가능성이 있지만, Anthropic에 지급하는 몫을 없애면 절감액이 상당할 듯함.
Rust 크레이트 bonsai를 쓰면 더 효율적으로 구현할 수 있음. 제어권이 더 많고 논리 흐름을 구성할 수 있어서, 아주 저렴한 모델로도 훨씬 나은 결과를 얻을 수 있음.
나는 플레이어가 가상의 캐릭터들과 상호작용하는 실시간 음성 스토리를 만들었음. 응답 지연이 없고 캐릭터도 모두 설정을 유지함. 효과가 놀라울 정도임.
‘bonsai + 저렴한 모델’이 글에서 사용한 ‘Amazon 내부에서 실행할 수 있는 저렴한 오픈소스 의사결정 모델’보다 어떻게 더 나은지 모르겠음.
어디에서 더 자세히 읽어볼 수 있을까?
왜 아직 Bedrock에서 의사결정 모델을 제공하지 않는지 이해가 안 됨. 모델을 계속 실행하는 것이 아니라면 Sagemaker나 Lambda는 꽤 비쌈.
20개 그룹 중 하나로 분류하는 작업이라면 scikit-learn은 시도해 봤을까?
너무 자주 하는 말이긴 하지만, BERT라면 더 적은 메모리로 더 빠르게 처리할 수 있음.