제너레이티브 AI 플랫폼 구축

기업들이 제너레이티브 AI 애플리케이션을 배포하는 방식을 연구한 후, 그들의 플랫폼에서 많은 유사성을 발견했습니다. 이 게시물은 제너레이티브 AI 플랫폼의 공통 구성 요소, 그 기능 및 구현 방법을 개요로 제시합니다. 저는 가능한 한 아키텍처를 일반화하려고 노력하지만, 특정 애플리케이션은 편차할 수 있습니다. 이는 전체 아키텍처가 보입니다. 이는 매우 복잡한 시스템입니다. 이 게시물은 가장 간단한 아키텍처부터 시작하여 점차적으로 더 많은 구성 요소를 추가합니다. 가장 간단한 형태에서는, 당신의 애플리케이션이 쿼리를 받으면 이를 모델에 보내고, 모델이 응답을 생성하면 이를 사용자에게 반환합니다. 게드레일 (guardrails) 이나 증강 컨텍스트 (augmented context), 또는 최적화가 없습니다. Model API 박스는 세 번째당 API(예: OpenAI, Google, Anthropic) 와 자체 호스팅 API 를 모두 지칭합니다. 여기서부터 필요에 따라 더 많은 구성 요소를 추가할 수 있습니다. 이 게시원에서 논의된 순서는 일반적이지만, 당신은 정확한 동일한 순서를 따르지 않아도 됩니다. 구성 요소는 시스템이 잘 작동하지 않는 경우를 제외하고는 생략될 수 있습니다. 평가는 개발 프로세스의 각 단계에서 필수적입니다. 컨텍스트 입력을 모델에 외부 데이터 소스와 정보 수집 도구 접근을 제공하여 증강합니다. 시스템을 보호하고 사용자를 보호하기 위해 게드레일을 배치합니다. 복잡한 파이프라인과 더 많은 보안을 지원하기 위해 모델 라우터와 게이트웨이를 추가합니다. 캐시를 사용하여 지연 시간과 비용을 최적화합니다. 시스템의 능력을 극대화하기 위해 복잡한 로직과 액션 작성을 추가합니다. 관찰 가능성 (Observability) 은 모니터링 및 디버깅을 위한 시스템에 대한 가시성을 얻게 해주는 것이며, 오케스트레이션 (orchestration) 은 모든 구성 요소를 연결하는 것을 포함하며, 이는 플랫폼의 두 가지 필수적인 구성 요소입니다. 우리는 이 게시물의 끝에 그것들을 논의할 것입니다. » 이 게시물이 아닌 것 « 이 게시물은 AI 애플리케이션을 배포하기 위한 전체 아키텍처에 초점을 맞춥니다. 어떤 구성 요소가 필요한지 및 이러한 구성 요소를 구축할 때 고려 사항을 논의합니다. AI 애플리케이션을 어떻게 구축하는지에 관해이지, 따라서 모델 평가, 애플리케이션 평가, 프롬프트 엔지니어링, 파인튜닝, 데이터 주석 가이드라인, 또는 RAG 의 chunking 전략에 대해 논의하지 않습니다. 이러한 모든 주제는 나의 다가오는 책 AI Engineering 에서 다루어집니다. 단계 1. 컨텍스트 증강 플랫폼의 초기 확장은 시스템을 각 쿼리에 필요한 정보를 추가할 수 있도록 메커니즘을 추가하는 것을 포함합니다. 관련 정보를 수집하는 것은 컨텍스트 구성 (context construction) 이라고 합니다. 많은 쿼리는 답변하기 위해 컨텍스트를 필요로 합니다. 컨텍스트에 있는 더 많은 관련 정보가 있을수록, 모델은 내부 지식을 의존해야 하는 것이 줄어들며, 이는 훈련 데이터 및 훈련 방법론으로 인해 신뢰할 수 없을 수 있습니다. 연구는 컨텍스트에 관련 정보 접근이 있는 경우 모델이 더 상세한 응답을 생성하고 환각 (hallucinations) 을 줄이는 데 도움이 된다는 것을 보여줍니다 (Lewis et al., 2020). 예를 들어, 쿼리

새로운 정보가 컨텍스트에 포함되지 않으면 t-week 데이터는 이번 주에 대한 질문에 답할 수 없습니다. 모델의 컨텍스트에 최신 정보 (예: fancy-printer-A300 의 최신 사양) 를 업데이트하면, 모델은 cutoff date 를 넘어선 쿼리에 응답할 수 있으며 최신 상태를 유지합니다.

RAGs
컨텍스트 구성을 위한 가장 잘 알려진 패턴은 RAG (Retrieval-Augmented Generation) 입니다. RAG 는 두 가지 구성 요소로 이루어져 있습니다: 생성기 (예: 언어 모델) 와 외부 소스에서 관련 정보를 검색하는 검색기 (retriever).
검색은 RAGs 에만 고유한 것이 아닙니다. 검색 엔진, 추천 시스템, 로그 분석 등 그 핵심을 이룹니다. 전통적인 검색 시스템에서 개발된 많은 검색 알고리즘은 RAGs 에 사용될 수 있습니다.
외부 메모리 소스는 일반적으로 구조화되지 않은 데이터를 포함합니다: 메모, 계약, 뉴스 업데이트 등. 이를 collectively documents 로 부릅니다. 문서의 길이는 10 토큰에서 100 만 토큰까지 다양합니다. 무작위로 전체 문서를 검색하면 컨텍스트가 임의로 길어질 수 있습니다. RAG 는 일반적으로 문서가 모델의 최대 컨텍스트 길이와 애플리케이션의 지연 시간 요구 사항에 따라 관리 가능한 chunks 로 분할되어야 함을 요구합니다. chunking 과 최적의 chunk size 에 대해 자세히 알고 싶다면 Pinecone, Langchain, Llamaindex, 그리고 Greg Kamradt 의 튜토리얼을 참조하세요.

외부 메모리 소스의 데이터가 로드되고 chunked 된 후, 두 가지 주요 접근법을 사용하여 검색이 수행됩니다.
Term-based retrieval
이는 키워드 검색과 같이 간단할 수 있습니다. 예를 들어, 쿼리

시작하는 매력적인 옵션으로 만들 수 있습니다. BM25 와 Elasticsearch 는 산업에서 널리 사용되며 더 복잡한 검색 시스템의 강력한 기준선 (baseline) 을 제공합니다. 임베딩 기반 검색은 계산 비용이 많이 들지만, 시간이 지남에 따라 유의미하게 개선되어 용어 기반 검색을 능가할 수 있습니다. 프로덕션 검색 시스템은 일반적으로 여러 접근법을 결합합니다. 용어 기반 검색과 임베딩 기반 검색을 결합하는 것을 하이브리드 검색 (hybrid search) 이라고 합니다. 일반적인 패턴 중 하나는 순차적 (sequential) 입니다. 먼저, 저렴하지만 정밀도가 낮은 검색기 (예: 용어 기반 시스템) 가 후보를 가져옵니다. 그런 다음, 더 정확하지만 비용이 많이 드는 메커니즘 (예: k-최근접 이웃) 이 이 후보들 중 최선의 것을 찾습니다. 두 번째 단계는 재순위화 (reranking) 라고도 합니다. 예를 들어,

이메일로 검색하고 이메일을 검색할 수 있습니다. 그러나 차이점은 미미하므로 많은 사람들이 action(액션)과 tool(도구)을 교차하여 사용합니다. » Read-only actions vs. write actions « 외부 소스에서 정보를 가져오지만 상태를 변경하지 않는 액션은 읽기 전용 (read-only) 액션입니다. 모델에 쓰기 전용 (write) 액션을 부여하면, 예를 들어 테이블의 값을 업데이트하는 것은 모델을 더 많은 작업을 수행할 수 있게 하지만 또한 더 큰 위험을 초래하며, 이는 나중에 논의될 것입니다. Query rewriting(쿼리 리라이팅) 자주 사용자 쿼리는 올바른 정보를 가져올 확률을 높이기 위해 다시 작성되어야 합니다. 다음 대화 상황을 고려해 보세요. User: When was the last time John Doe bought something from us? AI: John last bought a Fruity Fedora hat from us two weeks ago, on January 3, 2030. User: How about Emily Doe? 마지막 질문인