Amazon, 티켓 분류에 Sonnet 4.6 대신 Strands Decider 도입해 수백만 달러 절감

티켓 100만 건당 약 $21,700를 절약한다면, 연간 수백만 달러를 절약하려면 $2백만 절약을 달성하기 위해 연간 최소 9,200만 건의 티켓이 필요하다는 뜻입니다. 대략 맞나요?

처음에는 티켓을 단지 고객 지원이나 내부 JIRA 정도로 생각했는데, 기사에서 알람, 보안 발견 사항, 용량 증가 요청 등을 언급하니 규모가 더 그럴듯하게 느껴집니다. 그래도 그렇게 많은 티켓이 시스템을 통과한다는 것이 여전히 놀랍습니다.

Seldon AI(www.seldon-ai.com)의 창업자입니다. 우리는 개발자들이 이런 종류의 리팩토링과 지속적인 프로덕션 작업을 돕기 위한 개발 도구를 만들고 있습니다.

기본적으로 오늘날 애플리케이션 백엔드에는 LLM을 사용하는 온갖 함정 같은 사용 사례가 있습니다. 이는 단지 LLM이 사람들이 프로덕션화하거나 유지보수할 수 없는 것을 구축할 수 있게 해주는 또 다른 사례일 뿐입니다.

오늘날 AI/ML 기술이 전혀 없는 개발자도 LLM으로 멋진 새 기능을 프로토타이핑할 수 있습니다. 예전에는 데이터를 수집하고 큐레이션하여 ML 모델 파이프라인을 학습시킨 다음 프로덕션에 서빙해야 했죠.

문제는 새 기능을 프로덕션에 가져갈 때 발생합니다. 프로토타입/베타 워크로드에서 $20이던 비용이 이제 월 $30k의 LLM 비용이 되고, 200개의 테스트 샘플에서는 결코 발생하지 않았던 환각이 하루에 600번 발생합니다.

그러면 그들은 막히게 됩니다. 프로덕션 ML 파이프라인을 제대로 구축하고 운영할 지식과 예산, 프로덕션 워크로드를 처리하는 데 필요한 인프라 스택이 부족하기 때문입니다. 경영진도 "구식 방법"으로 "작동하는 것처럼 보이는" 것을 재구축하는 데 왜 투자해야 하는지 이해하지 못합니다.

이런 사용 사례에서 이 시스템 원(one) 또는 의사결정 모델은 LLM보다 한 단계 발전한 것입니다. 문제는 많은 애플리케이션 로직에 대해 여전히 다루기 어렵다는 점입니다(표현력이 제한됨). 초기 인기에도 불구하고, 이를 사용해 LLM 기반 백엔드를 리팩토링할 때 많은 마찰과 이미 LLM으로의 프로덕션 롤백 사례를 여러 번 들었습니다.

저는 시스템 원 모드[…]

품질에 대한 언급은 없네요, 적어도 저는 못 봤습니다. 요즘 중요한 것처럼 보이는 것은 속도와 비용뿐입니다.

이 기사는 정말 혼란스럽습니다. 예를 들어, 그들은 Strands Decider 모델을 시도했다가 Gemma 때문에 포기했다고 말한 다음, 계속해서 그들이 사용한 모델을 Strands Decider라고 부릅니다? 제가 뭔가 놓친 걸까요?

좋아요, 그런데 왜 처음에 Sonnet을 선택했을까요? Haiku나 GPT Luna, 아니면 심지어 값싼 중국 소형 모델을 선택할 수도 있었지 않나요?

그렇다면 왜 Haiku 5.5는 시도조차 하지 않았을까요?

아마존이 왜 다른 회사에 가서 조정된 디사이더 모델을 제공하게 했을까요?

아마존은 이미 이 모든 티켓에 라벨이 붙어 있으니 직접 구축할 수도 있었을 텐데요?

20개 그룹 중 하나로 분류한다고요? 누군가 scikit learn을 시도해 봤나요?