AI는 ETL을 재발명하는 데 시간을 낭비해서는 안 됩니다.

최근 AI의 발전은 매우 흥미롭습니다. 사람들은 고객 지원 경험 개선 , 코드 작성 및 실행 , 새로운 음악 만들기 , 심지어 의료 영상 기술 가속화에 이르기까지 모든 종류의 새로운 방식으로 이를 사용하고 있습니다.

그러나 그 과정에서 걱정스러운 추세가 나타났습니다. AI 커뮤니티가 데이터 이동(ETL이라고도 함)을 재창조하는 것 같습니다. 커넥터, 추출기, 통합, 문서 로더 등 무엇이라고 부르든 사람들은 동일한 코드를 작성하여 동일한 API, 문서 형식 및 데이터베이스에서 데이터를 추출한 다음 이를 벡터 DB 또는 LLM용 인덱스에 로드합니다.

문제는 처음부터 강력한 추출 및 로딩 파이프라인을 구축하고 유지하는 것이 엄청난 노력이 필요하다는 것입니다. 그리고 해당 분야에는 선행 기술이 너무 많아서 AI 분야의 거의 모든 엔지니어나 기업이 이를 재구성하는 것은 엄청난 시간 낭비입니다. 거의 매 시간마다 속보가 나오는 공간에서 주요 초점은 보조 퀘스트가 아닌 사용자를 위해 핵심 제품을 믿을 수 있게 만드는 데 있어야 합니다. 그리고 거의 모든 사람에게 핵심 제품은 데이터 이동이 아닙니다. 그것은 당신이 양조하고 있는 AI 기반의 마법 소스입니다.

강력한 ETL(추출, 변환 및 로드) 파이프라인을 구축하는 데 관련된 과제에 대해 많은 글이 작성되었지만( 1 , 2 ) AI 내에서 이를 맥락화해 보겠습니다.

AI에 데이터 이동이 필요한 이유는 무엇입니까?

공공 데이터에 대한 교육을 받은 LLM은 훌륭하지만 더 좋은 것이 무엇인지 아시나요? 우리, 우리 회사, 사용자와 관련된 질문에 답할 수 있는 AI입니다. ChatGPT가 회사 전체 위키를 배우고, 모든 이메일, Slack 메시지, 회의 메모 및 기록을 읽고, 회사의 분석 환경에 연결하고, 질문에 답변할 때 이러한 모든 소스를 사용할 수 있다면 우리는 모두 좋아할 것입니다. 또는 AI를 자체 제품(예: Notion AI ) 에 통합할 때 앱의 AI 모델이 사용자를 도울 때 사용자에 대해 가지고 있는 모든 정보를 알기를 원합니다.

데이터 이동은 이 모든 것을 위한 전제 조건입니다.

모델을 미세 조정하든 RAG(Retrieval-Augmented Generation)를 사용하든 데이터가 있는 위치에서 데이터를 추출하고 모델이 소화할 수 있는 형식으로 변환한 다음 AI 앱이 액세스할 수 있는 데이터 저장소에 로드해야 합니다. 귀하의 사용 사례를 제공합니다.

위의 다이어그램은 RAG를 사용할 때의 모습을 보여 주지만 RAG를 사용하지 않더라도 기본 단계는 변경되지 않을 것이라고 상상할 수 있습니다. 귀하와 귀하의 사용 사례에 특정한 비공개 정보를 아는 AI 모델을 구축하십시오.

데이터 이동이 어려운 이유는 무엇입니까?

API 또는 데이터베이스에서 데이터를 추출하기 위한 기본 기능 MVP를 구축하는 것은 항상 그런 것은 아니지만 일반적으로 빠른(1주 미만) 공지로 가능합니다. 정말 어려운 부분은 이를 프로덕션 준비 상태로 만들고 그대로 유지하는 것입니다. 추출 파이프라인을 구축할 때 염두에 두어야 할 몇 가지 표준 과제를 살펴보겠습니다.

증분 추출 및 상태 관리

의미 있는 데이터 볼륨이 있는 경우 파이프라인이 이전에 보지 못한 데이터만 추출하도록 증분 추출을 구현해야 합니다. 이렇게 하려면 각 연결에서 추출한 데이터를 추적할 수 있는 지속성 계층이 필요합니다.

일시적 오류 처리, 백오프, 실패 시 재개, 에어 갭핑

업스트림 데이터 소스는 항상 존재하며 때로는 명확한 이유 없이 발생합니다. 파이프라인은 이에 대한 복원력을 갖추고 올바른 백오프 정책을 사용하여 재시도해야 합니다. 실패가 일시적이지 않은 경우(그러나 여전히 사용자의 잘못은 아님) 파이프라인은 중단된 위치를 기억하고 업스트림이 수정된 후 동일한 위치에서 재개할 수 있을 만큼 탄력적이어야 합니다. 때로는 업스트림에서 발생하는 문제가 너무 심각하여(예: 레코드에서 일부 중요한 필드를 삭제하는 API와 같이) 무슨 일이 일어나고 있는지 조사하고 수행할 작업을 수동으로 결정할 때까지 전체 파이프라인을 일시 중지하고 싶을 수도 있습니다.

구성 오류 식별 및 사전 예방적 수정

고객의 데이터를 추출하기 위해 데이터 추출 파이프라인을 구축하는 경우 고객을 대신하여 데이터를 추출하기 위해 제공한 모든 구성이 올바른지 확인하고 그렇지 않은 경우 신속하게 몇 가지 방어 검사를 구현해야 합니다. 실행 가능한 오류 메시지를 제공하세요. 대부분의 API는 포괄적인 오류 테이블을 게시하지 않기 때문에 이 작업을 쉽게 수행하지 않으며, 게시하더라도 API 토큰과 같이 할당된 권한을 확인하는 데 사용할 수 있는 엔드포인트를 거의 제공하지 않으므로 포괄적인 균형을 유지하는 방법을 찾아야 합니다. 사용자에 대한 빠른 피드백으로 확인합니다.

인증 및 비밀관리

API는 단순한 전달자 토큰 인증부터 세션 토큰 또는 일회용 토큰 OAuth의 "창의적인" 구현까지 단순함의 범위가 넓습니다. 인증을 수행하고 한 시간에 한 번씩 새로 고쳐질 수 있는 비밀을 관리하는 논리를 구현해야 하며 잠재적으로 여러 동시 작업자 간에 비밀 새로 고침을 조정해야 합니다.

추출 및 로드 속도, 동시성, 속도 제한 최적화

동시 작업자에 관해 말하자면, 추출에 대한 높은 처리량을 달성하기 위해 동시성을 구현하고 싶을 것입니다. 이는 소규모 데이터세트에서는 중요하지 않을 수 있지만 대규모 데이터세트에서는 절대적으로 중요합니다. API가 공식 속도 제한을 게시하더라도 IP를 블랙리스트에 올리거나 속도를 영원히 제한하지 않고 API에서 제공하는 속도 제한을 최대화하기 위한 최상의 병렬 처리 매개변수를 경험적으로 파악해야 합니다.

업스트림 API 변경에 적응

API는 항상 변경되고 문서화되지 않은 새로운 동작이나 특이한 점을 갖습니다. 많은 공급업체가 분기별로 새로운 API 버전을 게시합니다. 이러한 모든 업데이트가 작업에 어떤 영향을 미칠 수 있는지 계속 주시하고 모든 것을 최신 상태로 유지하기 위해 엔지니어링 시간을 투자해야 합니다. 새로운 엔드포인트는 항상 나타나며 일부는 동작을 변경합니다(항상 미리 알 수 있는 것은 아닙니다).

예약, 모니터링, 로깅 및 관찰 가능성

특정 API에서 데이터를 추출하는 코드 외에도 모든 데이터 추출기가 활용하는 몇 가지 수평적 기능을 구축해야 할 수도 있습니다. 일정이 작동하지 않거나 다른 문제가 발생하여 조사해야 할 때를 대비해 일정을 계획하고 로깅 및 모니터링하는 것이 필요할 것입니다. 또한 어제, 오늘, 지난 주 등에 얼마나 많은 레코드가 추출되었는지, 어떤 API 엔드포인트 또는 데이터베이스 테이블에서 추출되었는지 등의 관찰 기능을 원할 수도 있습니다.

데이터 차단 또는 해싱

데이터를 가져오는 위치에 따라 열을 다운스트림으로 보내기 전에 차단 또는 해싱을 위한 일부 개인 정보 보호 기능이 필요할 수 있습니다.

분명히 말하면, 몇 개의 파일을 일회성으로 이동하려는 경우에는 위의 내용이 적용되지 않습니다.

그러나 데이터 이동이 필요한 제품을 구축하는 경우에는 적용됩니다. 조만간 이러한 문제의 대부분을 처리해야 합니다. 그 중 어느 하나도 극복할 수 없는 로켓 과학은 아니지만, 이를 종합하면 신속하게 하나 또는 여러 개의 정규직 일자리를 추가할 수 있으며, 더 많은 데이터 소스에서 가져오면 더욱 그렇습니다.

이것이 바로 데이터 추출 및 파이프라인 유지 관리의 어려움입니다. 비용의 대부분은 해당 파이프라인을 기능적이고 강력하게 유지하는 데 필요한 지속적인 증분 투자에서 발생합니다. 대부분의 AI 엔지니어에게 이는 사용자에게 가장 큰 가치를 추가하는 작업이 아닙니다. 그들의 시간은 다른 곳에서 보내는 것이 가장 좋습니다.

그렇다면 AI 엔지니어는 일부 데이터를 여기로 이동하기 위해 무엇을 해야 할까요?

데이터 추출 및 파이프라인 로드가 필요한 경우 자동으로 자체 솔루션을 구축하는 대신 이미 사용 가능한 솔루션을 사용해 보세요. 귀하의 우려 사항이 전부는 아니더라도 많은 부분을 해결할 수 있을 가능성이 있습니다. 그렇지 않은 경우 최후의 수단으로 직접 구축하십시오.

기존 플랫폼이 필요한 모든 것을 지원하지 않더라도 이식 가능하고 확장 가능한 프레임워크를 사용하면 여전히 대부분의 방식을 얻을 수 있습니다. 이렇게 하면 모든 것을 처음부터 구축하는 대신 플랫폼의 기성 기능을 사용하여 90%를 달성하고 마지막 10%만 구축하고 유지할 수 있습니다. 가장 일반적인 예는 롱테일 통합입니다. 플랫폼이 필요한 API에 대한 통합과 함께 제공되지 않는 경우 좋은 플랫폼을 사용하면 해당 통합을 구축하기 위한 일부 코드 또는 코드 없는 솔루션을 쉽게 작성할 수 있습니다. 여전히 플랫폼에서 제공하는 모든 유용한 기능을 얻을 수 있습니다. 커넥터를 Python 패키지로 가져오고 코드에서 원하는 대로 트리거하는 유연성을 원하더라도 Airbyte 또는 Singer 커넥터와 같은 많은 오픈 소스 EL 도구 중 하나를 사용할 수 있습니다.

분명히 말하면 데이터 이동이 완전히 해결되지는 않았습니다. 기존 솔루션이 실제로 부족하여 새로운 솔루션을 구축해야 하는 상황이 있습니다. 그러나 이것은 AI 엔지니어링 인구의 대다수가 아닙니다. 대부분의 사람들은 Jira, Confluence, Slack, Notion, Gmail, Salesforce 등과 동일한 통합을 반복해서 다시 구축할 필요가 없습니다. 이미 검증을 거쳐 누구나 사용할 수 있도록 공개된 솔루션을 사용하여 사용자가 실제로 관심을 갖는 가치를 추가하는 작업을 계속해 나가겠습니다.