AI 엔지니어링 - 아키텍처와 사용자 피드백

아키텍처

![[assets/ai 엔지니어링 - 아키텍처와 사용자 피드백/architecture.png|625]]

• 기본 : 유저로부터 query를 받아서 모델이 응답을 생성해 반환한다
• Context construction
  • 적절한 응답을 생성하는 데 필요한 컨텍스트를 구축할 수 있도록 함 (RAG, 에이전트, 질의 재작성)
    • 도구 사용, 웹 검색, 이미지 검색, 텍스트 검색
• 가드레일
  • 입력 가드레일
    • 외부API로 개인정보가 유출되는 것 방지
      • 사용자가 문제가 되는 정보를 프롬프트에 복사해 서드파티 api로 전송하거나, 도구가 내부 데이터베이스에서 개인정보를 컨텍스트에 추가하는 경우 등
      • 개인정보(주민번호, 계좌번호, 전화번호) / 사람 얼굴 / 회사 지적 재산이나 기밀 정보와 관련된 키워드,문구 등을 민감 데이터로 정의하고 탐지
    • 시스템을 망가뜨릴 수 있는 악성 프롬프트 방지
  • 출력 가드레일
    • 품질 : 잘못된 형식, 환각(사실과 불일치), 전반적으로 수준이 낮은 응답
    • 보안: 유해한 응답, 개인정보/민감한 정보 포함, 원격 도구나 코드 실행을 유발, 브랜드에 위험을 초래하는 응답
      • 보안 실패뿐 아니라 false refusal rate도 확인
    • 많은 실패는 간단한 재시도 로직으로 완화할 수 있음(응답은 확률적이므로 재시도하면 다른 응답) -> 지연 시간 이슈, 순차가 아닌 병렬 처리
  • 트레이드오프: 신뢰성과 지연 시간
    • 모델을 자체 호스팅하는지 서드파티 API를 쓰는지(자체 가드레일 제공)
• 모델 라우터와 게이트웨이
  • 라우터
    • 하나의 모델만 사용하는 것 대비 질의 유형별로 여러 솔루션을 사용 = 각 질의에 알맞는 성능의 특화 모델 사용, 불필요한 비싼 모델을 사용하지 않아 비용 절약
    • 라우터는 보통 사용자의 의도를 예측하는 의도 분류기로 구성 + 다음 행동 예측기
    • 많은 경우 GPT-2, BERT, 라마7B 같은 작은 언어 모델을 사용 (라우터는 빠르고 저렴해야 하기 때문)
    • 컨텍스트 한계가 있는 모델로 라우팅할 때 라우터는 컨텍스트 조정의 역할까지 해야 할 수 있음
  • 게이트웨이
    • 자체 호스팅 모델과 상용 API 뒤에 있는 모델을 포함한 다양한 모델에 통합 인터페이스를 제공
    • 코드 유지보수가 쉬워짐 (모델 API가 변경되더라도 다른 영역 애플리케이션이 아닌 모델 게이트웨이만 업데이트)
    • 사용자/애플리케이션 별로 어떤 모델에 접근을 허용할 것인지 access control
    • API 호출 사용량을 모니터링, 제한하는 비용 관리 기능
    • API 실패나 이슈 상황에서 fallback policy 구현
• 캐싱
  • 완전 일치 캐싱
    • 정확히 같은 항목이 요청될 때만 캐시된 항목을 사용
    • 벡터 검색을 반복하지 않기 위해 임베딩 기반 검색에도 사용
    • 해당 질의가 다시 호출될 가능성이 얼마나 높은지에 따라 캐시에 보관할 기간을 판단해야 함(이를 결정하기 위한 분류기를 사용할 수도 있음)
    • 개인적인 정보가 포함되어 캐싱되면 정보 유출이 발생할 수 있으므로 주의
  • 시맨틱 캐싱
    • 의미적으로 비슷한 항목이 요청될 때 캐시된 항목을 사용 = 두 질의가 의미적으로 유사한지를 판단할 수 있는 방법(질의에 대한 임베딩을 저장하기 위한 벡터 데이터베이스)가 있어야 함. 벡터 검색에 필요한 시간과 연산량, 복잡도를 고려하면 명확한 이점이 있을 때만 도입해야
• 에이전트 패턴
  • 복잡한 애플리케이션에서 만약 시스템이 출력 생성 후 작업이 완료되지 못했다고 판단한다면 이를 새롭게 컨텍스트에 포함해서 다시 응답 생성(그림 생성 출력 -> 컨텍스트 화살표)
  • 이메일 작성, 주문하기 등 쓰기 작업을 호출할 수 있음
• 모니터링, observability
  • 모니터링(시스템 출력에 대한 지표를 보는 것, 원인 파악에 대한 보장은 없음) vs. observability(시스템의 출력으로 내부 상태를 추론 -> 시스템을 계측하고 디버깅하는 전체 과정)
  • 지표
    • 지표의 목적은 잘못됐을 때 알려주고 개선할 기회를 찾는 것
    • 어떤 실패 유형을 잡아내고 싶은지를 먼저 정의하고 이를 중심으로 지표를 설계하는 게 중요
      • 모델 실패, 생성 품질(사실 일관성, 간결성, 긍정성), 유해성, 거부율, 가드레일 작동률, 이상한 질의 자체를 탐지, 사용자의 피드백(평균 턴 수, 토큰 수/분포), 지연 시간, 비용
      • 여러 지표들 간의 상관관계 / 비즈니스 핵심 지표와의 관계
      • 표본 검사 vs. 전수검사
    • [[AI 엔지니어링 - 평가]]
  • 로그와 트레이스
    • 지표만 보고 알 수 없는 것들을 확인할 수 있게 해줌
    • 로깅의 일반적인 원칙은 모든 것을 로깅하는 것 = 양이 매우 빠르게 증가할 수 있음
    • 트레이스는 관련 이벤트들을 하나로 연결해 타임라인을 만든 것
  • 드리프트 감지
    • 시스템 프롬프트 변경, 사용자의 행동 변화, 기반 모델 변경
• Orchestration
  • 구성 요소 정의 : 시스템이 어떤 구성 요소들을 쓰는지 오케스트레이터에 알려준다 (다양한 모델, 검색을 위한 외부 데이터 소스, 시스템이 사용할 수 있는 도구들, 평가/모니터링 도구)
  • 체이닝 (파이프라이닝): 질의 받는 순간부터 작업 완료까지 시스템이 수행하는 단계를 오케스트레이터에게 알려줌
  • 처음에는 오케스트레이션 도구 없이 개발 -> 후반 과정에서 복잡도가 올라가면 도입 (통합과 확장성, 파이프라인 관리 고급 기능 지원, 사용 편의성 등을 고려)