데이터 수집(Data Ingestion)을 프로덕션 준비 상태로 만들기: LangChain 기반 Airbyte Destination

지난 몇 달 동안 저희의 주요 초점은 팀들이 프로토타입 단계에서 프로덕션 단계로 나아갈 수 있도록 하는 것이었습니다. 한 시간 만에 개발한 애플리케이션을 실제로 신뢰성 있게 사용할 수 있는 곳으로 가져가는 것입니다. 논란의 여지가 있지만, LangChain이 활성화하는 가장 큰 범주의 애플리케이션은 검색 기반 애플리케이션(LLM을 자체 데이터에 연결하는 경우)입니다. 검색 기반 애플리케이션을 프로토타입에서 프로덕션으로 옮기기 위해서는 몇 가지 요소가 필요합니다.

그중 하나는 데이터 쿼리(querying)와 관련된 모든 것입니다. 이것이 바로 LangSmith를 출시한 이유인데, LLM이 사용자 쿼리와 검색된 문서와 어떻게 상호 작용하는지 디버깅하고 모니터링하는 데 도움을 주기 위해서입니다. 또 다른 거대한 측면은 쿼리 알고리즘과 그 주변의 UX이며, 이것이 바로 저희가 대화형 검색 에이전트(Conversational Retrieval Agents) 같은 기능에 집중하는 이유입니다. (만약 이 부분에 특히 관심이 있으시다면, 8월 9일에

첫째, Airbyte는 수백 가지의 추가 소스(source)와 강력한 오케스트레이션 로직은 물론, 더 많은 소스를 생성할 수 있는 도구까지 제공합니다. 오케스트레이션 로직에 초점을 맞춰보겠습니다. 데이터 인덱스에 접근하는 챗봇을 만들 경우, 데이터를 한 번만 인덱싱하고 끝내고 싶지 않습니다. 주기적으로 재인덱싱(reindex)하여 항상 최신 상태를 유지해야 합니다. 이러한 유형의 데이터 파이프라인은 Airbyte가 탁월하게 잘 수행해왔으며 지속적으로 발전시켜 왔습니다.

둘째, 데이터 수집 과정은 단순히 소스에서 목적지(destination)로 데이터를 이동시키는 것만을 의미하지 않습니다. 효과적인 검색(retrieval)을 가능하게 하는 중요하고, 사소하지 않으며 미묘한 변환(transformation) 과정들도 필요합니다. 그중 가장 중요한 두 가지는 텍스트 분할(text splitting)과 임베딩(embedding)입니다.

텍스트를 분할하는 것은 벡터 저장소(vectorstore)에 넣을 데이터 청크(chunk)를 생성해야 하기 때문에 중요합니다. 이 청크들은 검색되었을 때 자체적으로 의미가 통하도록, 즉 의미론적으로 유의미해야 합니다. 이것이 단순히 1000자마다 텍스트를 분할하는 것보다 종종 더 까다로운 이유입니다. LangChain은 다양한 알고리즘에 의해 구동되며 여러 텍스트 유형(마크다운 대 Python 코드 등)에 최적화된 15가지 이상의 텍스트 분할 구현체를 제공합니다. 이러한 다양한 텍스트 스플리터가 무엇을 제공하는지 탐색하는 데 도움을 드리고자, 저희는 사용하기 쉬운 플레이그라운드를 오픈 소스로 공개하고 호스팅했습니다.

임베딩은 이러한 청크들을 검색 가능하게 하는 데 중요하며, 이는 종종 사용자 쿼리의 임베딩과 수집된 문서의 임베딩을 비교하는 방식으로 수행됩니다. 매우 다양한 임베딩 제공업체와 호스팅 플랫폼이 있으며, LangChain은 이 중 50가지가 넘는 곳과의 통합 기능을 제공합니다.

전반적으로 저희는 이번 LangChain - Airbyte 통합에 대해 매우 기대하고 있습니다. 이는 LangChain의 변환 로직과 통합 기능을 활용하는 동시에 수집 작업(ingestion jobs)에 대한 강력한 오케스트레이션 및 스케줄링을 제공합니다. 또한 데이터 수집 과정을 프로덕션 준비 상태로 만들기 위해 추가할 기능(및 통합)이 더 있다고 생각하며, 앞으로 몇 주 동안 더 많은 내용을 기대해 주시기 바랍니다.