생성형 AI 애플리케이션 구축 시 흔한 실수

기초 모델 (foundation models) 을 활용한 애플리케이션 개발 초기 단계에 있으므로 실수를 하는 것은 당연합니다. 이는 저의 공개 사례 연구와 개인 경험에서 본 가장 흔한 실수 중 일부에 대한 예시를 담은 짧은 메모입니다. 이러한 실수가 흔하므로, AI 제품 작업을 해본 적이 있다면 아마도 이미 본 적이 있을 것입니다.

1. 필요 없는 곳에 생성형 AI 를 사용
   새로운 기술이 등장할 때마다 저는 항상 다음과 같은 고도의 엔지니어들의 collective sigh를 들을 수 있습니다: "모든 것이 nails(나사)가 아닙니다." 생성형 AI 는 예외가 아닙니다 — 그 무한해 보이는 능력은 모든 것에 생성형 AI 를 사용하는 경향을 더욱 악화시킵니다.

팀이 저에게 에너지 소비 최적화에 생성형 AI 를 사용하라는 아이디어를 제안했습니다. 그들은 가정의 에너지 집약적 활동 목록과 시간별 전기 요금을 LLM (Large Language Model) 에 입력하고, 비용 최소화를 위한 스케줄을 만들도록 요청했습니다. 그들의 실험은 가정의 전기세를 30% 줄일 수 있다고 보여주었습니다. 무료 돈입니다. 누가 앱을 사용하지 않을까요? 저는 다음과 같이 물었습니다: "그것은 단순히 전기 요금이 가장 저렴할 때 에너지 집약적 활동을 스케줄링하는 것과 어떻게 비교되는지? 예를 들어, 저녁 10 시 이후 세탁기 및 차량 충전기를 사용하는 것." 그들은 나중에 시도해보고 결과를 알려주겠다고 대답했습니다. 그들은 결코 후속 조치를 취하지 않았으며, 곧 이 앱을 포기했습니다.

저는 이러한 탐욕적인 스케줄링이 상당히 효과적일 수 있다고 생각합니다. 그것이 아니더라도, 생성형 AI 보다 훨씬 저렴하고 신뢰할 수 있는 최적화 솔루션이 있습니다. 예를 들어 선형 계획법 (linear programming) 이 있습니다. 저는 이 시나리오를 반복해서 본 적이 있습니다.

대기업이 네트워크 트래픽의 이상 징후를 감지하기 위해 생성형 AI 를 사용하고 싶고, 다른 회사는 향후 고객 통화 부하를 예측하고 싶어하며, 병원에서는 환자가 영양실조인지 감지하고 싶어합니다 (정말 권장되지 않음). 새로운 접근법을 탐구하는 것이 가능할 것임을 이해하는 데 도움이 될 수 있습니다. 다만, 당신의 목표가 문제를 해결하는 것이 아니라 솔루션을 테스트하는 것이라고 인지해야 합니다.

"우리는 문제를 해결한다"와 "우리는 생성형 AI 를 사용한다"는 매우 다른 헤드라인이며, 불행히도 많은 사람들은 후자를 선호합니다.

2. '나쁜 제품' 과 '나쁜 AI'를 혼동하기
   스펙트럼의 반대편에 있는 팀들은 사용자들이 그것을 싫어했기 때문에 그들의 문제를 해결하는 데 생성형 AI 가 유효한 해결책이 아님을 무시했습니다. 그러나 다른 팀은 유사한 사용 사례에서 성공적으로 생성형 AI 를 사용했습니다. 저는 두 팀만 조사할 수 있습니다.

두 경우 모두 문제의 핵심은 AI 가 아니라 제품 (product) 이었습니다. 많은 사람들이 저에게 그들의 AI 애플리케이션 기술적 측면이 간단하다고 말했습니다. 어려운 부분은 사용자 경험 (UX) 입니다. 제품이 어떻게 인터페이스를 가져야 할까요? 제품을 사용자의 워크플로우에 어떻게 원활하게 통합해야 할까요? 인간-인-루프 (human-in-the-loop) 를 어떻게 포함해야 할까요? UX 는 항상 도전적이었지만, 생성형 AI 와는 더욱 그렇습니다.

우리는 생성형 AI 가 우리가 읽는 방식, 쓰는 방식, 배우는 방식, 가르치는 방식, 일하는 방식, 여가 생활을 하는 방식 등을 어떻게 바꾸고 있는지 알고 있지만, 아직 그 방법을 정확히 알지 못합니다. 미래의 읽기/학습/작업은 어떤 모습일까요?

사용자가 원하는 것이 역설적일 수 있으며 엄격한 사용자 연구가 필요함을 보여주는 몇 가지 간단한 예시입니다.

저의 친구는 회의 전사 (transcripts) 를 요약하는 애플리케이션을 개발하고 있습니다. 처음에는 그녀의 팀이 올바른 요약 길이를 얻는 데 집중했습니다. 사용자는 3 문장 요약이나 5 문장 요약을 선호할까요? 그러나 결과적으로 그들의 사용자들은 실제 요약에 관심이 없었습니다. 그들은 특정한 행동 항목 (action items) 만 원했습니다.

각 회의에서 사용자를 분리합니다. LinkedIn 이 기술 적합성 평가용 챗봇을 개발했을 때, 사용자들은 정확한 답변이 아닌 도움이 되는 답변을 원한다는 것을 발견했습니다. 예를 들어, 사용자가 직업을 위해 적합한지 챗봇에게 물어보고 챗봇이 "너는 전혀 적합하지 않다"라고 대답하면, 이는 정확할 수 있지만 사용자에게 도움이 되지 않습니다. 사용자는 어떤 격차가 있는지, 그 격차를 어떻게 좁힐 수 있는지에 대한 팁을 원합니다. Intuit 는 세무 관련 질문에 답하도록 도와주는 챗봇을 만들었습니다. 처음에는 lukewarm(반갑지 않은) 피드백을 받았습니다 — 사용자가 챗봇이 유용하지 않다고 느꼈습니다. 조사 결과, 사용자들은 타이핑 자체를 싫어한다는 것을 발견했습니다. 빈 채의 챗봇 앞에 앉아 있는 사용자는 챗봇이 무엇을 할 수 있는지, 무엇을 입력해야 하는지 알지 못했습니다. 따라서 각 상호작용마다 사용자가 클릭할 몇 가지 제안된 질문을 추가했습니다. 이는 사용자가 챗봇을 사용할 때 마찰을 줄이고 사용자의 신뢰를 점진적으로 구축했습니다. 이후 사용자 피드백은 훨씬 더 긍정적이었습니다. (이 내용은 Grace Hopper 의 패널에서 Intuit AI VP Nhung Ho 가 공유했습니다.) 현재 모든 사람이 동일한 모델을 사용하므로, AI 제품의 AI 구성 요소는 유사하고 차별화는 제품입니다.

3. 초기에 너무 복잡하게 시작함 이 함정의 예: 직접 API 호출이 작동할 때 에이전트 프레임워크를 사용합니다. 단순한 단어 기반 검색 솔루션 (vectordb 를 필요로 하지 않음) 이 작동할 때 어떤 벡터 데이터베이스를 사용할지 고민합니다. 프롬프트가 작동할 때 fine-tuning 을 강요합니다. 의미론적 캐싱을 사용합니다. 많은 화려한 새로운 기술이 있기 때문에, 바로 이를 사용하려는 유혹에 빠지기 쉽습니다. 그러나 외부 도구를 너무 일찍 통합하면 2 가지 문제가 발생할 수 있습니다: 중요한 세부 사항을 추상화하여 시스템을 이해하고 디버깅하기 어렵게 만듭니다. 불필요한 버그를 도입합니다. 도구 개발자는 실수를 할 수 있습니다. 예를 들어, 프레임워크의 코드베이스를 검토할 때 기본 프롬프트에 오타가 있음을 자주 발견합니다. 사용하는 프레임워크가 프롬프트를 업데이트하지 않고 알려주지 않으면, 애플리케이션의 동작이 변경될 수 있고 그 이유를 알지 못할 수 있습니다. 결국 추상화는 좋습니다. 그러나 추상화는 최선의 관행을 통합하고 시간이 지남에 따라 테스트되어야 합니다. AI 엔지니어링은 아직 초기 단계이며, 최선의 관행은 여전히 진화 중이므로 추상화를 채택할 때 더 주의 깊어야 합니다.

4. 초기 성공에 과도하게 집중 LinkedIn 은 원하는 경험의 80% 를 달성하는 데 1 개월을, 95% 를 초과하는 데 추가 4 개월을 가졌습니다. 초기 성공은 제품 개선이 얼마나 어려운지, 특히 환각 (hallucinations) 에 대해 어떻게 어려운지를 과대평가하지 못하게 했습니다. 각 후속 1% 의 향상을 달성하는 것이 얼마나 어렵고 discouraging(위축적) 한지 발견했습니다. AI 판매 보조를 개발하는 스타트업은 0 에서 80% 로 가는 데 걸리는 시간이 80% 에서 90% 로 가는 데 걸리는 시간과 같다고 말했습니다. 그들이 직면한 도전: 정확도/지연율의 트레이드오프: 더 많은 계획/자기 수정 = 더 많은 노드 = 더 높은 지연율 도구 호출: 에이전트가 유사한 도구를 구별하는 것이 어렵습니다 시스템 프롬프트에서 톤 요청 (예: "럭셔리 브랜드 컨시어지처럼 말하다") 를 완벽하게 준수하는 것이 어렵습니다 에이전트가 고객의 의도를 완전히 이해하는 것이 어렵습니다 특정 단위 테스트 세트를 생성하는 것이 어렵습니다. 쿼리의 조합은 기본적으로 무한하기 때문입니다. Thanks Jason Tjahjono for sharing this.

UltraChat 논문에서 Ding et al. (2023) 은 " 0 에서 60 으로 가는 여정은 쉽지만, 60 에서 100 으로 진전되는 것은 극도로 어렵습니다"라고 공유했습니다. 이는 AI 제품을 빠르게 구축한 사람들이 배우는 첫 번째 고통스러운 교훈 중 하나일 수 있습니다. 데모를 만드는 것은 쉽습니다,

하지만 제품을 구축하는 것은 어렵습니다. 언급된 환각 (hallucinations), 지연 시간 (latency), 지연 시간/정확도 트레이드오프, 도구 사용, 프롬프트 엔지니어링, 테스트 등 문제 외에도 팀들은 다음과 같은 문제를 겪기도 합니다: API 제공자에서의 신뢰성. 한 팀이 저에게 10% 의 API 호출이 타임아웃을 경험했다고 말했습니다. 또는 기본 모델이 변함에 따라 제품의 행동이 변합니다. 컴플라이언스 (Compliance), 예를 들어 AI 출력 저작권, 데이터 접근/공유, 사용자 프라이버시, 검색/캐싱 시스템으로부터의 보안 리스크, 그리고 훈련 데이터 선계 (training data lineage) 에 대한 모호성 등입니다. 안전성 (Safety), 예를 들어 악의적인 행위자가 제품을 남용하거나, 제품이 무감각하거나 모욕적인 응답을 생성하는 경우 등입니다. 제품의 마일스톤과 자원을 계획할 때 이러한 잠재적 장애물을 고려해야 합니다. 한 친구는 이를 "주의 깊게 낙관론자 (being cautiously optimistic)"라고 부릅니다. 그러나 많은 멋진 데모가 훌륭한 제품으로 이어지지 않는다는 것을 기억하세요.

5. 인간 평가를 포기하지 마세요
   AI 애플리케이션을 자동으로 평가하기 위해 많은 팀은 AI-as-a-judge (또는 LLM-as-a-judge) 접근 방식을 선택합니다 — AI 모델을 사용하여 AI 출력을 평가합니다. 일반적인 함정은 인간 평가를 포기하고 AI 판사에게 완전히 의존하는 것입니다. AI 판사는 매우 유용할 수 있지만 결정론적이지 않습니다. 판사의 품질은 underlying judge 의 모델, 판사의 프롬프트, 그리고 사용 사례에 따라 달라집니다. AI 판사가 제대로 개발되지 않으면 애플리케이션의 성능에 대해 오해의 평가가 될 수 있습니다. AI 판사는 모든 다른 AI 애플리케이션과 마찬가지로 시간이 지남에 따라 평가되고 반복되어야 합니다. 제가 본 최고의 제품 팀들은 자동 평가를 보완하기 위해 인간 평가를 모두 가지고 있습니다. 매일, 그들은 애플리케이션 출력의 일부 subset 을 인간 전문가들이 평가하며, 이는 30 에서 1000 개의 예제까지 다양합니다. 일일 수동 평가는 세 가지 목적을 수행합니다: 인간 판단과 AI 판단을 상관관계 (Correlate) 합니다. 인간 평가자의 점수가 감소하지만 AI 판사의 점수가 증가한다면 AI 판사를 조사하고 싶을 수 있습니다. 사용자가 애플리케이션을 사용하는 방식을 더 잘 이해할 수 있으며, 이는 애플리케이션을 개선하는 아이디어를 줄 수 있습니다. 자동 데이터 탐색이 놓칠 수 있는 사용자의 행동 패턴과 변화를 현재 사건에 대한 지식으로 감지합니다.

인간 평가의 신뢰성은 잘 작성된 annotation guidelines 에도 의존합니다. 이러한 annotation guidelines 는 모델의 인스트럭션을 개선할 수 있습니다 (인간이 인스트럭션을 따르는 데 어려움을 겪는다면, 모델도 마찬가지입니다). 나중에 finetune 을 선택하는 경우 이를 finetuning 데이터 생성에 재사용할 수도 있습니다. 제가 참여한 모든 프로젝트에서 데이터를 15 분 동안 바라보는 것만으로도 몇 시간의 고생이 절약될 수 있는 통찰을 얻었습니다. Greg Brockman 은 "데이터의 수동 검토는 머신러닝 활동 중 가치/prestige 비율이 가장 높은 활동입니다"라고 트위터에 게시했습니다.

6. Use cases 를 crowdsourcing 하세요
   이는 초기 days 에 기업들이 생성형 AI 채택에 열광했을 때 제가 본 실수입니다. 어떤 use cases 에 집중할 전략을 세우지 못했기 때문에, 많은 기술 executives 는 전 회사에서 아이디어를 crowdsourcing 했습니다. "우리는 똑똑한 사람들을 고용합니다. 그들이 우리에게 무엇을 해야 할지 말해달라." 그런 다음 이 아이디어들을 하나씩 구현하려고 합니다. 그리고 이것이 우리가 100 만 개의 text-to-SQL 모델, 100 만 개의 Slack bots, 그리고 10 억 개의 code plugins 을 만들게 된 것입니다. 똑똑한 사람들이라고 해서 들을 것은 좋은 생각이지만, 개인들은 자신의 일일 업무에 즉시 영향을 미치는 문제들보다 가장 높은 수익을 가져올 수 있는 문제들에 대해 편향될 수 있습니다.

투자 측면에서 보면, 전체적인 전략을 고려하지 않으면 작은 규모의 저 영향력 애플리케이션 시리즈로 편입되어 생성형 AI 가 ROI 를 갖지 않는다는 잘못된 결론에 도달하기 쉽습니다.

요약
단순히 말해, 일반적인 AI 엔지니어링 함정들은 다음과 같습니다:

1. 불필요할 때 생성형 AI 사용: 모든 문제에 대한 해결책으로 생성형 AI 는 하나에 맞는 해법이 아닙니다. 많은 문제는 AI 를 필요로 하지 않습니다.

2. '나쁜 제품'과 '나쁜 AI' 혼동: 많은 AI 제품에 있어 AI 는 쉬운 부분이고, 제품은 어려운 부분입니다.

3. 지나치게 복잡한 시작: 화려한 새로운 프레임워크와 Fine-tuning 은 많은 프로젝트에 유용할 수 있지만, 첫 번째 행동으로 삼지 않아야 합니다.

4. 초기 성공에 과도하게 집중: 초기 성공은 오해의 소지가 있습니다. 데모 준비에서 프로덕션 준비로 가는 것은 첫 번째 데모를 만드는 것보다 훨씬 더 오래 걸립니다.

5. 인간 평가 포기: AI 판별자는 체계적인 인간 평가와 상관관계를 검증해야 합니다.

6. 사용 사례Crowdsource: 투자 수익을 극대화하기 위한 전체적인 전략을 세우세요.