프로덕션 AI 애플리케이션을 위한 가장 유용하고 현실적인 레포지토리 청사진

이것은 프로덕션 AI 애플리케이션을 위한 가장 유용하고 현실적인 레포지토리 청사진 중 하나입니다.

요청 처리 및 모델 통합부터 보안, 관측 가능성(observability), 평가(evaluations), 배포에 이르는 LLM 주변의 엔지니어링 전반을 다룹니다.

각 부분은 명확한 책임을 가집니다:

api/: 요청 처리, 타입 스키마(typed schemas), 인증 및 속도 제한(rate limits).

application/: 워크플로우(workflows), 비즈니스 규칙(business rules), 예산(budgets) 및 출력 유효성 검사.

providers/: 모델 통합, 마감일(deadlines), 바운디드 재시도(bounded retries) 및 취소 기능.

security/: ID(identity), 테넌트 격리(tenant isolation), 접근 제어(access control) 및 도구 권한(tool permissions).

prompts/: 템플릿, 입력 계약(input contracts), 모델 구성(model configuration) 및 버전 참조.

observability/: 요청 추적(request tracing), 지연 시간(latency), 오류, 모델 사용량 및 비용.

evals/: 버전 관리된 데이터셋(versioned datasets), 품질 검사(quality checks), 보류 승인 테스트(held-out acceptance tests) 및 샘플링된 프로덕션 평가.

tests/: 단위(unit), 통합(integration), 보안 및 실패 경로 테스트.

deploy/: 빌드, 인프라, 상태 확인(health checks) 및 안전한 롤아웃(safe rollouts).

RAG, 에이전트(agents), 캐싱(caching), 도구 실행(tool execution), 영속성(persistence) 및 백그라운드 워커(background workers)는 별도의 사용 사례 의존적 기능으로 구성됩니다.

일부 애플리케이션은 이러한 기능을 처음부터 필요로 합니다. 검색 증강 생성(RAG)에 크게 의존하는 제품은 RAG가 필요할 수 있으며, 에이전트 기반 애플리케이션은 도구 실행 및 오케스트레이션에 크게 의존할 수 있습니다. 이 구조는 모든 애플리케이션을 동일한 아키텍처로 강제하지 않으면서 둘 다 수용합니다.

모델 호출은 시간 초과될 수 있습니다. 사용자는 접근 권한이 없는 데이터를 요청할 수 있습니다. 모델 및 프롬프트 변경은 단일 단위 테스트를 깨지 않고도 답변 품질을 저하시킬 수 있습니다.

따라서 애플리케이션은 이러한 경우들을 처리하고, 권한을 강제하며, 배포 전후에 문제를 식별하기 위해 엔지니어에게 충분한 추적(tracing), 테스트 및 평가 기능을 제공해야 합니다.

레포지토리 구조 자체가 이 모든 것을 작동하게 만들지는 않습니다. 다만 이러한 책임들이 코드베이스 내에서 명확한 위치를 갖도록 해줄 뿐입니다.

작게 시작하세요. 제품이 필요로 할 때 기능을 추가하십시오.