정말 LLM이 필요한가요?

AI 요약

저자는 라즈베리 파이 4(메모리 4GB)에서 Ollama로 smollm2:360m과 qwen2.5:1.5b를 실행해 식별자 추출, 메시지 분류, 문서 질의응답을 시험했습니다. 데이터는 가상 와이너리에 관한 질문 95개이며, 분류 메시지 50개에는 의도적으로 모호한 사례 16개를 넣었습니다. 시험 전 워크플로별 예측 22개를 기록해 결과를 본 뒤 기대를 바꾸지 않도록 했습니다. 저자는 필요한 계산량을 결정적 코드, 소형 로컬 모델, GPU가 필요한 대형 로컬 모델, 원격 프런티어 모델의 네 단계로 나눕니다.

식별자 추출: 정규식이 이긴 작업

주문 번호 ORD-와 숫자 여섯 자리를 찾는 30개 사례에서 정규식은 30개를 모두 맞혔고 처리 시간은 0밀리초였습니다. qwen2.5:1.5b는 28개를 맞혔습니다. 한 사례에서는 ORD- 접두사를 빠뜨렸고, 다른 사례에서는 주문 번호가 분명히 있는데도 없다고 답했습니다. 후자는 실제 업무 흐름에서 주문이 존재하는 환불 요청을 누락할 수 있는 오류입니다. smollm2:360m은 22개 주문 번호를 모두 찾아냈지만 접두사를 보존한 답은 8개뿐이었습니다. 회원 번호, 운송장 번호, 전화번호 같은 오답 후보도 그대로 내놓았습니다. 저자는 모델이 후보를 찾고 정규식이 형식을 검증하는 결합 방식을 제안하지만, 직접 시험한 결과는 아니라고 밝힙니다. 이 작업의 판정은 불필요입니다. 정규식으로 해결할 수 있습니다.

메시지 분류: 주제와 처리 결정을 구분해야 합니다

예약, 결제, 재고 문의, 불만, 질문, 담당자 확인 요청 등 여섯 라벨로 50개 메시지를 분류했습니다. qwen2.5:1.5b의 정확도는 46%였고, smollm2:360m은 30%였습니다. 작은 모델은 50개 중 43개에 에스컬레이션 라벨을 붙여 사실상 분류하지 못했습니다. qwen 모델은 불만과 질문 같은 주제 라벨은 각각 6/6, 9/10으로 맞혔지만, 사람의 확인이 필요한 에스컬레이션은 0/12였습니다. 부상 신고와 상표권 관련 통지, 심각한 알레르기 문의를 다른 업무 큐로 보냈고, 결제 문제도 불만으로 분류했습니다. 저자는 주제는 문장의 표현으로 드러나지만, 어떤 담당자가 처리해야 하는지는 업무 정책과 결과에 달렸다고 설명합니다. 에스컬레이션 규칙은 모델에 맡기지 말고 별도로 구현하자는 판정입니다. 다만 클래스별 사례가 6~12개뿐이고 모델도 하나라는 한계를 명시합니다.

문서 질의응답: 단일 사실 조회는 가능하지만 검토가 필요합니다

650토큰 분량의 와이너리 자료를 바탕으로 15개 질문을 냈습니다. 답이 한 문단에 있는 8개 질문에서 qwen2.5:1.5b는 8개를 맞혔고, smollm2:360m은 7개를 맞혔습니다. 두 문단의 정보를 합쳐야 하는 질문은 qwen 모델이 3개 중 1개, 작은 모델은 0개를 맞혔습니다. 자료에 답이 없는 질문 4개에서는 qwen 모델이 2개를 거부하고 2개를 지어냈으며, 작은 모델은 4개 모두 답을 만들어냈습니다. 특히 포도 수확 당시 당도를 나타내는 Brix 값을 병에 든 와인의 알코올 도수처럼 제시했습니다. 관련된 실제 숫자를 가져왔지만 질문에 답하지 못한 사례입니다. 따라서 판정은 사람이 답을 확인하는 조건에서만 쓸 수 있는 '경계선'입니다.

지연 시간과 실행 환경

qwen 모델의 중앙 처리 시간은 추출 5초, 분류 2.9초, 질의응답 6.9초였습니다. 저자는 프롬프트가 길어지는 것보다 생성 답변이 길어지는 쪽이 지연 시간에 더 큰 영향을 줬다고 설명합니다. 질의응답 프롬프트는 97토큰에서 708토큰으로 늘었지만 출력 전 대기 시간은 15% 증가했습니다. 전체 중앙 처리 시간은 3.6초에서 6.9초로 늘었고, 가장 느린 호출은 98초였습니다. 첫 실행에서는 팬 없이 방열판만 사용해 라즈베리 파이가 온도 제한에 걸렸습니다. 펌웨어 확인 결과 스로틀링이 발생했고, 저자는 해당 지연 시간 기록을 폐기했습니다. 네트워크 경로를 끊은 상태에서도 세 워크플로 호출이 작동했지만, 이 결과가 보안이나 개인정보 보호를 보장하지는 않는다고 선을 긋습니다.

저자는 결과를 '입력에 답이 그대로 있고, 답이 하나이며, 출력이 짧고, 모델 밖에서 결과를 검증하는 수단이 있는가'라는 조건으로 정리합니다. 어느 하나라도 빠지면 이 실험에서는 모델 사용을 권하기 어렵다고 봅니다. 다만 두 모델, 단일 보드, 단일 양자화 설정, 95개 사례로 진행한 실험이므로 벤치마크가 아니라 방법을 보여주는 사례라고 설명합니다. 재현 자료와 실행 기록은 GitHub 저장소에 공개했습니다.

dev.to 반응

• @makeev — 외국 발행사의 6-K 공시에서 실적 발표를 찾는 문제에도 '무엇인가'를 식별하는 관점이 잘 맞습니다. 제목과 보고 기간의 규칙, 특정 지표 개수만으로 처리했습니다. 규칙을 작성하는 일은 쉬웠고, 실제 공시 60일치를 디스크에 캐시해 수정할 때마다 전체 사례를 몇 초 안에 다시 돌릴 수 있었던 점이 효과를 냈습니다. 첫 버전은 Nebius의 발표를 사전 공지로 읽어 거부했습니다. 분류 작업이 부적합 판정을 받았다면 패턴으로 확인할 만한 것이 있을까요, 아니면 큐 라벨에는 붙잡을 단서가 없을까요?
  • @kenwalger — 규칙을 바꿀 때마다 실제 공시 60일치를 돌려보는 방식이 흥미롭습니다. 예상한 사례만 처리한다고 패턴이 맞다고 여기지 않고 Nebius 같은 사례를 발견할 수 있기 때문입니다. 메시지가 무엇에 관한지 알아내는 일과 다음에 무엇을 해야 할지 결정하는 일은 다릅니다. 키워드로 결제 문제를 찾을 수는 있지만 부상 신고나 법률 통지를 사람에게 넘기는 일은 주제보다 결과에 관한 정책이 필요합니다. 의무 에스컬레이션 규칙부터 만들고 나머지 큐에는 더 좁은 패턴을 적용한 뒤, 모호한 사례는 사람이 확인하도록 하는 방법을 같은 50개 메시지에서 시험하겠습니다. 이번 실험에는 그런 기준선을 만들지 않아 더 낫다고 단정할 수는 없습니다. 다만 에스컬레이션 0/12 결과는 조사할 이유가 됩니다.
  • @makeev — 메시지의 이름을 붙이는 일과 다음 행동을 결정하는 일의 구분은 저희가 택한 방식과도 맞습니다. 분류기는 각 공시에 라벨만 붙이고 모든 공시는 감사 기록에 남습니다. 게시 여부는 별도 스위치로 통제했고, 실제 게시 전 그림자 모드에서 게시될 내용을 읽었습니다.
• @copyleftdev — 다양한 환경을 결정적으로 처리하는 알고리즘은 수십 년 동안 축적됐습니다. 제약 솔버, 그래프 알고리즘, 상태 머신, 최적화 기법, 확률적 방법을 제대로 조합하면 강력합니다. LLM을 아키텍처의 중심에 두기보다 의미 해석이나 생성형 추론, 모호성이 필요한 경우에만 전문 하위 프로세스로 호출할 수 있습니다. Jev by TypeSafe 같은 엔진을 쓰면 결정적 알고리즘으로 조율과 제약을 처리하고, 확률 모델로 범위가 정해진 판단을 맡기며, LLM은 열린 추론에 쓸 수 있습니다. 어떤 계산 방식이 각 문제에 맞는지 골라 조합하는 일이 실제 과제입니다. 입력 세계가 결정적이지 않아도 실행을 결정적으로 만들 수 있습니다. 질문은 LLM이 필요한지에 그치지 않고 비용과 복잡도, 확신 수준에 맞춰 계산 자원을 쓰도록 시스템을 설계했는지에 있습니다. 지능은 아키텍처가 아니라 아키텍처가 활용하는 자원일 수 있습니다.
  • @kenwalger — 이 실험이 다루려던 문제를 아키텍처 관점으로 확장해 주셨습니다. LLM이 유용한가보다 문제를 먼저 살피지 않고 기본 계산 수단으로 삼았는지가 질문입니다. 입력이 예측 불가능하거나 불완전하고 모호해도 이후의 모든 결정을 확률적으로 처리할 필요는 없습니다. 계산 자원을 고르는 일에 더해 권한도 봐야 합니다. 모델이 모호한 요청을 해석하더라도 결과에 따른 행동이 허용되는지는 결정적 정책이 정할 수 있습니다. Jev도 살펴볼 목록에 있습니다.

원문: dev.to / 번역·요약: Trawling