실제 비즈니스 가치를 창출하는 GenAI는 실제 노력이 필요하지만 그만한 가치가 있습니다.
원본 이미지는 The Everett Collection의 Shutterstock에서 제공되었습니다. 이미지는 저자에 의해 편집되었습니다.
GenAI는 어디에서나 보이며, 각 산업의 조직들은 팀에 압력을 가하고 경쟁에 참여하도록 하고 있습니다 — 비즈니스 리더의 77%는 이미 GenAI의 혜택을 놓치고 있다고 우려하고 있습니다.
데이터 팀들은 호소에 대답하기 위해 분주하다. 하지만 실제로 비즈니스 가치를 창출하는 생성 모델을 구축하는 것은 정말 어렵다.
그리고 장기적으로, OpenAI API와 빠른 통합만으로는 충분하지 않습니다. GenAI이지만, 경쟁 우위는 어디에 있나요? 사용자들이 ChatGPT보다 왜 당신을 선택해야 하나요?
그 상자를 빠르게 체크하는 것은 한 걸음 앞으로 나아가는 것 같지만, 이미 LLMs와 독점 데이터 및 비즈니스 맥락을 연결하여 차별화된 가치를 실제로 창출하는 방법에 대해 고려하지 않고 있다면, 당신은 뒤쳐져 있습니다.
과장이 아닙니다. 이번 주에만 이 주제로 반열을 이루는 데이터 리더들과 대화를 나눴습니다. 그들 중 아무도 놓치지 않았다는 것은 이것이 경쟁이라는 사실입니다. 결승선에는 승자와 패자가 있을 것입니다. 블록버스터와 넷플릭스처럼요.
만약 당신이 스타터 건이 울렸지만 여전히 출발선에서 스트레칭을 하고 '버블'과 '흥분'에 대해 이야기하는 팀이 있다면, 나는 태만함을 흔들어내는 데 도움이 되는 5가지 진실을 모았습니다.
현실 #1: 당신의 생성적 AI 기능은 잘 받아들여지지 않고 수익화가 느립니다.
“바르, GenAI가 그렇게 중요하다면, 왜 우리가 현재 구현한 기능들이 그렇게 열악하게 채택되고 있는 건가요?”
그 이유는 몇 가지가 있습니다. 첫째, AI 계획이 명확한 사용자 문제의 급격한 증가에 대한 대응으로 구축되지 않았습니다. 대부분의 데이터 팀에게는 그 이유가 있습니다. 그것은 당신이 경쟁하고 있고 초기 단계이며 어떤 경험을 쌓고 싶기 때문입니다.
그러나 사용자들이 GenAI로 가장 잘 해결할 수 있는 문제를 겪게 될 때까지는 오래 걸리지 않을 것이며, 그런 상황이 오면, GenAI를 사용 사례에 연결하는 방법을 고민하는 타이거 팀보다 훨씬 더 나은 채택률을 보게 될 것입니다.
그리고 이것이 일찍이라면, 통합된 생성적 AI 기능은 단지 'ChatGPT지만 여기서'일 뿐입니다.
예를 들어보겠습니다. 매일 사용하는 생산성 애플리케이션을 생각해보세요. 이 앱은 조직적인 지식을 공유하기 위해 사용될 수 있습니다. 이와 같은 앱은 구조화되지 않은 텍스트 블록에 대해 '이것을 요약해줘', '더 길게 만들어줘', '어조를 바꿔줘'와 같은 명령을 실행할 수 있는 기능을 제공할 수 있습니다. 한 번의 명령은 한 개의 AI 크레딧과 동일합니다.
네, 도움이 되긴 하지만, 차별화되지 않았어요.
팀이 AI 크레딧을 구매하기로 결정할지도 모르고, 아니면 그들은 단순히 다른 탭을 클릭하고 ChatGPT에 질문할지도 모릅니다. ChatGPT에 독점 데이터를 노출시키지 않는 이점을 완전히 무시하거나 경시하고 싶지는 않지만, 이것은 국가 각지의 수익 전화에서 그려지는 것보다 더 작은 해결책과 비전입니다.
That pesky middle step from concept to value. Image courtesy of Joe Reis on Substack.
그러니 고려해 보세요: 당신의 GenAI 차별화 요소와 가치는 무엇인가요? 힌트를 드릴게요: 고품질의 독점 데이터입니다.
그래서 RAG 모델(또는 때로는 세밀하게 조정된 모델)이 Gen AI 프로젝트에 중요한 이유입니다. 이 모델은 LLM에 기업의 독점 데이터에 접근할 수 있게 합니다. 아래에서 설명하겠습니다.
현실 #2: 당신은 Gen AI와 더 많은 일을 하기를 두려워합니다.
그것은 사실입니다: 생성적 AI는 위협적입니다.
확실히, 당신은 AI 모델을 조직의 프로세스에 더 깊게 통합할 수 있지만, 그것은 위험하게 느껴집니다. 우리가 직면한 사실은, ChatGPT는 환각을 일으키고 예측할 수 없습니다. 사용자들이 오래된 출력에 노출되도록 하는 지식의 차단이 있습니다. 데이터 처리 오류와 소비자에게 실수로 오도된 정보를 제공하는 것에는 법적인 결과가 따릅니다.
Sounds real enough, right? Llama 2 sure thinks so. Image courtesy of Pinecone.
당신의 데이터 실수는 결과를 가져옵니다. 그래서 GenAI에게 정확히 무엇을 입력하고 있는지, 그리고 데이터가 정확한지를 알아야 하는 것이 중요합니다.
데이터 리더들에게 보낸 익명의 조사에서 우리 팀이 GenAI 사용 사례를 가능하게 하는 데 얼마나 멀리 떨어져 있는지 묻는 질문에 대한 하나의 응답은 다음과 같습니다. '우리 인프라가 우리를 막고 있는 것은 아니라고 생각합니다. 우리는 여기서 매우 신중하게 움직이고 있습니다. 랜드스케이프가 너무 빨리 변하고 있고 '이방인' 챗봇으로 인한 평판 손상의 위험이 있기 때문에 우리는 불을 붙이지 않고 하이프가 조금 가라앉을 때까지 기다리고 있습니다!'
많은 데이터 리더들과 이야기를 나눌 때 이는 널리 공유되는 감정입니다. 데이터 팀이 갑자기 고객과 직접 상호작용하는 안전한 데이터를 제시했다면, 그들은 책임을 져야 합니다. 데이터 거버넌스는 매우 중요한 고려사항이며, 이를 충족시키는 것은 높은 기준입니다.
이것들은 해결이 필요한 실제 위험들이지만, 구경만 하고 있어서는 해결되지 않을 것입니다. 누가 먼저 그것을 깨달아서 근본적으로 비즈니스가 방해받는 위험도 실제로 존재합니다.
LLM을 내부 데이터에 파인 튜닝 및 RAG로 기반을 구축하는 것은 이 퍼즐의 큰 조각이지만 쉽지 않습니다...
현실 #3: RAG는 어렵다.
미래의 기업 생성적 AI의 중심 요소는 RAG(검색 보강 생성) 및 세밀한 조정이라고 믿습니다. 그러나 대부분의 경우 RAG가 더 간단한 접근 방식이지만, RAG 앱을 개발하는 것은 여전히 복잡할 수 있습니다.
우리 모두 RAGing을 시작할 수 없을까요? 큰 문제가 뭐죠? 이미지는 Reddit에서 제공됨.
RAG는 LLM을 사용자 정의하는 명백한 해결책으로 보일 수 있습니다. 그러나 RAG 개발은 가장 재능 있는 데이터 엔지니어들에게도 학습 곡선이 따릅니다. 그들은 prompt engineering, 벡터 데이터베이스 및 임베딩 벡터, 데이터 모델링, 데이터 오케스트레이션, 데이터 파이프라인... 이 모든 것을 RAG를 위해 알아야 합니다. 그리고 2020년 Meta AI에 의해 새롭게 도입되었기 때문에(Meta AI가 2020년에 소개함), 많은 회사들은 아직 충분한 경험을 쌓지 못하여 최상의 실천 방법을 수립하지 못하고 있습니다.
RAG 애플리케이션 아키텍처. 이미지 제공: Databricks._
여기에 RAG 애플리케이션 아키텍처의 과도한 단순화가 있습니다:
- RAG 아키텍처는 정보 검색과 텍스트 생성 모델을 결합하여 사용자의 질문에 답하려고 할 때 데이터베이스에 액세스할 수 있습니다.
- 데이터베이스는 독점 데이터를 포함하는 신뢰할 수 있는 소스여야 하며, 모델이 최신 및 신뢰할 수 있는 정보를 답변 및 추론에 통합할 수 있도록 합니다.
- 백그라운드에서 데이터 파이프라인은 다양한 구조화된 및 비구조화된 소스를 데이터베이스로 가져와 정확하고 최신 상태를 유지합니다.
- RAG 체인은 사용자 쿼리(텍스트)를 가져와 데이터베이스에서 관련 데이터를 검색한 다음 해당 데이터와 쿼리를 LLM에 전달하여 매우 정확하고 개인화된 응답을 생성합니다.
이 아키텍처에는 많은 복잡성이 있지만 중요한 이점이 있습니다:
- 정확한 독점 데이터를 기반으로 하여 LLM을 보강하여 그 가치를 훨씬 높입니다.
- 상대적으로 간단하고 비용 효율적인 방식으로 모델을 데이터에 가져오는 대신 데이터를 모델에 가져오게 합니다.
현대 데이터 스택에서 이것이 현실이 되고 있는 것을 볼 수 있습니다. 주요 기업들은 엔터프라이즈 데이터가 저장되는 환경 내에서 LLM을 제공함으로써 RAG를 더 쉽게 만들기 위해 초고속으로 작업하고 있습니다.
Snowflake Cortex는 이제 기관이 데이터를 신속하게 분석하고 AI 앱을 Snowflake에서 직접 구축할 수 있게 합니다. Databricks의 새로운 Foundation Model APIs는 Databricks 내에서 LLMs에 직접적으로 빠르게 접근할 수 있도록 합니다. Microsoft는 Microsoft Azure OpenAI Service를 출시했으며, Amazon은 최근 Amazon Redshift Query Editor를 출시했습니다.
스노우플레이크 데이터 클라우드. 이미지는 Medium의 Umesh Patel에게 속합니다.
나는 이러한 기능들이 모두 높은 채택률을 유도할 가능성이 있다고 믿지만, 이러한 기능들은 또한 이러한 데이터 저장소들의 데이터 품질에 대한 주목을 높이게 될 것이다. RAG 파이프라인에 공급되는 데이터가 이상하거나 오래되었거나 신뢰할 수 없는 경우, 생성적 AI 이니셔티브의 미래는 어떻게 될 것인가?
현실 #4: 여러분의 데이터는 아직 준비되지 않았습니다.
당신의 데이터 인프라를 면밀히 살펴보세요. 완벽한 RAG 파이프라인, 세밀하게 조정된 모델, 그리고 내일 즉시 사용할 수 있는 명확한 사용 사례가 있다고 해도 (그렇다면 좋겠죠?) 여전히 깨끗하고 잘 모델링된 데이터셋이 준비되어 있지 않을 것입니다.
가정해 봅시다. 챗봇이 고객과 상호 작용하도록 하려고 합니다. 유용한 작업을 수행하려면 해당 기관과 고객 간의 관계를 알아야 합니다. 현재 기업 기관이라면, 이 관계는 아마도 150개의 데이터 소스와 5개의 격리된 데이터베이스를 통해 정의될 것입니다... 그 중 3개는 여전히 온프레미스에 있습니다.
당신의 조직이 그에 해당한다면, 당신의 데이터 인프라가 GenAI에 준비되기까지 1년(또는 2년!) 정도의 시간이 필요할 수 있습니다.
이것은 즉, GenAI와 곧 언젠가 _무언가_를 수행할 옵션을 원한다면, 현대적인 데이터 플랫폼에서 유용하고 매우 신뢰할 수 있으며 통합되고 잘 문서화된 데이터셋을 어제 만들어 두어야 합니다. 그렇지 않으면 코치가 당신을 경기에 불러들이고 당신의 바지가 내려갈 것입니다.
당신의 데이터 엔지니어링 팀은 데이터 건강을 보증하는 중추입니다. 또한, 현대적인 데이터 스택은 데이터 엔지니어링 팀이 미래에도 지속적으로 데이터 품질을 모니터링할 수 있도록 합니다.
혹독한 진실 #5: 당신은 그것을 모르고 중요한 Gen AI 플레이어들을 배척했습니다.
생성적 AI는 특히 개발에 있어 팀 스포츠입니다. 많은 데이터 팀이 GenAI 타이거 팀에서 주요 플레이어를 배제하는 실수를 저지르고 있으며, 그것이 장기적으로 그들에게 손해를 입힙니다.
AI 타이거 팀에는 누가 있어야 할까요? 리더십 또는 주요 비즈니스 이해자는 이니셔티브를 주도하고 그룹에 비즈니스 가치를 상기시키기 위해 필요합니다. 코드를 개발하고 사용자를 대상으로 하는 애플리케이션 및 API 호출을 개발하는 소프트웨어 엔지니어가 필요합니다. 새로운 사용 사례를 고려하고 모델을 세밀하게 조정하며 팀을 새로운 방향으로 이끌어야 하는 데이터 과학자가 필요합니다. 여기서 누가 빠졌을까요?
데이터 엔지니어.
데이터 엔지니어는 GenAI 계획에 중요합니다. 그들은 ChatGPT보다 경쟁 우위를 제공하는 독점적인 비즈니스 데이터를 이해할 수 있을 것이며, 그들은 그 데이터를 LLM을 통해 RAG를 통해 사용할 수 있게 하는 파이프라인을 구축할 것입니다.
만약 데이터 엔지니어가 같은 방에 없다면, 여러분의 타이거 팀은 완전한 강도가 아닙니다. GenAI의 가장 선구적인 기업들은 이미 모든 개발 팀에 데이터 엔지니어를 포함시키고 있다고 말하고 있습니다.
GenAI 경주에서 우승하기
만약 이러한 현실이 당신에게 해당된다면 걱정하지 마십시오. 생성적 AI는 아직 초기 단계에 있어 다시 시작하고 이번에는 도전을 받아들일 시간이 충분히 남아 있습니다.
고객의 요구 사항을 이해하고 AI 모델이 해결할 수 있는 문제를 파악하기 위해 한 걸음 물러나고, 초기 개발 단계에서 데이터 엔지니어를 도입하여 시작부터 경쟁 우위를 확보하고, 안정적인 고품질 데이터를 지속적으로 제공할 수 있는 RAG 파이프라인을 구축하는 데 시간을 투자하십시오.
그리고 데이터 품질을 우선시하는 현대적인 데이터 스택에 투자하세요. 왜냐하면 고품질 데이터 없는 생성적 AI는 그저 허무맹랑할 뿐이기 때문입니다.