GenAI 시스템의 숨겨진 기술 부채

소개

고전적인 머신러닝과 생성형 AI 워크플로를 광범위하게 비교해 보면, 일반적인 워크플로 단계는 둘 다 비슷하다는 것을 알 수 있습니다. 둘 다 데이터 수집, 피처 엔지니어링, 모델 최적화, 배포, 평가 등을 필요로 하지만 실행 세부 정보와 시간 할당은 근본적으로 다릅니다. 가장 중요한 것은 생성형 AI는 제대로 관리하지 않으면 빠르게 누적될 수 있는 기술 부채의 고유한 원인을 야기한다는 것입니다. 여기에는 다음이 포함됩니다.

• 툴 스프롤 - 급증하는 에이전트 툴을 관리하고 선택하는 데 따르는 어려움
• 프롬프트 스터핑 - 유지 관리가 불가능해질 정도로 지나치게 복잡한 프롬프트
• 불투명한 파이프라인 - 적절한 추적 기능이 없어 디버깅이 어렵습니다
• 부적절한 피드백 시스템 - 인간의 피드백을 효과적으로 수집하고 활용하지 못함
• 이해관계자 참여 부족 - 최종 사용자와 정기적으로 소통하지 않음

이 블로그에서는 기술 부채의 각 형태를 차례로 살펴보겠습니다. 궁극적으로, 클래식 ML에서 생성형 AI로 전환하는 팀은 클래식 ML 프로젝트에서 주를 이루었던 데이터 정제 및 피처 엔지니어링보다는 평가, 이해관계자 관리, 주관적인 품질 모니터링, 계측에 더 많은 시간을 할애하여 새로운 부채 원인을 인식하고 그에 따라 개발 관행을 조정해야 합니다.

고전적 머신러닝(ML)과 생성형 인공지능(AI) 워크플로는 어떻게 다른가요?

이 분야가 현재 어느 수준에 있는지 이해하려면, 생성형 AI 워크플로를 고전적인 machine learning 문제에 사용하는 워크플로와 비교해 보는 것이 도움이 됩니다. 다음은 개략적인 개요입니다. 이 비교에서 알 수 있듯이 광범위한 워크플로 단계는 동일하게 유지되지만, 실행 세부 정보의 차이로 인해 강조되는 단계가 달라집니다. 앞으로 살펴보겠지만 생성형 AI는 새로운 형태의 기술 부채를 도입하기도 하며, 이는 프로덕션 환경에서 시스템을 유지 관리하는 방식에 영향을 미칩니다.

GenAI 프로젝트에서 머신 러닝 개발자는 시간을 어떻게 다르게 할애하고 있을까요?

가격 예측 프로젝트와 도구 호출 에이전트 구축 프로젝트를 동시에 진행해 본 결과, 모델 개발 및 배포 단계에 몇 가지 주요한 차이점이 있다는 것을 알게 되었습니다.

모델 개발 루프

내부 개발 루프는 일반적으로 machine learning 개발자가 모델 파이프라인을 구축하고 개선할 때 거치는 반복적인 프로세스를 의미합니다. 보통 프로덕션 테스트 및 모델 배포 전에 발생합니다.

기존 ML 및 GenAI 전문가는 이 단계에서 시간을 다음과 같이 다르게 사용합니다.

고전적인 ML 모델 개발의 시간 낭비 요인

• 데이터 수집 및 특징 미세 조정: 고전적인 머신러닝 프로젝트에서는 대부분의 시간을 특징과 입력 데이터를 반복적으로 미세 조정하는 데 사용합니다. Databricks 특징점과 같이 피처를 관리하고 공유하는 도구는 관련된 팀이 많거나 수동으로 쉽게 관리하기에는 피처가 너무 많은 경우에 사용됩니다.
  
  반면에 평가는 간단합니다. 모델을 실행하여 정량적 측정항목이 개선되었는지 확인한 후, 더 나은 데이터 수집과 특징으로 모델을 어떻게 향상시킬 수 있을지 다시 고민하는 과정을 거칩니다. 예를 들어, 저희 가격 예측 모델의 경우, 저희 팀은 대부분의 예측 오류가 데이터 이상치를 고려하지 못했기 때문에 발생했다는 것을 발견했습니다. 그래서 저희는 모델이 이러한 패턴을 식별할 수 있도록 이러한 이상치를 나타내는 특징을 포함하는 방법을 고려해야 했습니다.

생성형 AI 모델 및 파이프라인 개발 시간 소모 요인

• 평가: 생성형 AI 프로젝트에서는 데이터 수집 및 변환과 평가 간의 상대적인 시간 할당이 뒤바뀝니다. 데이터 수집은 일반적으로 모델에 대한 충분한 컨텍스트를 수집하는 것을 포함하며, 이는 비정형 지식 베이스 문서나 매뉴얼 형태일 수 있습니다. 이 데이터는 광범위한 정리가 필요하지 않습니다. 하지만 평가는 훨씬 더 주관적이고 복잡하며, 결과적으로 더 많은 시간이 소요됩니다. 모델 파이프라인뿐만 아니라 평가 세트도 반복해야 합니다. 그리고 기존 ML보다 엣지 케이스를 처리하는 데 더 많은 시간이 소요됩니다.
  
  예를 들어, 초기 10개의 평가 질문 세트가 사용자가 지원 봇에게 할 수 있는 질문의 전체 범위를 다루지 못할 수 있으며, 이 경우 더 많은 평가를 수집해야 합니다. 또는 설정한 LLM 심사위원이 너무 엄격하여 관련성 있는 답변이 테스트에 실패하지 않도록 프롬프트를 수정해야 할 수도 있습니다. MLflow의 평가 데이터 세트 는 항상 올바르게 작동해야 하는 예제의 '골든 세트'를 버전 관리, 개발 및 감사하는 데 유용합니다.
• 이해관계자 관리: 또한 응답 품질은 최종 사용자의 입력에 따라 달라지므로 엔지니어는 비즈니스 최종 사용자 및 제품 관리자와 만나 요구 사항을 수집하고 우선순위를 정하며 사용자 피드백을 반복하는 데 훨씬 더 많은 시간을 할애합니다. 역사적으로 고전적 ML은 최종 사용자를 광범위하게 대면하지 않는 경우가 많았습니다(예: 시계열 예측) 또는 비기술 사용자에게 덜 노출되었기 때문에 생성형 AI의 제품 관리 요구 사항이 훨씬 더 높습니다. Databricks Apps 에서 호스팅되고 MLflow 피드백 API 를 호출하는 간단한 UI를 통해 응답 품질 피드백을 수집할 수 있습니다. 그런 다음 피드백을 MLflow 추적 및 MLflow 평가 데이터 세트에 추가하여 피드백과 모델 개선 간의 선순환을 만들 수 있습니다.

다음 다이어그램은 기존 ML과 생성형 AI의 모델 개발 루프 시간 할당을 비교합니다.

모델 배포 루프

모델 개발 루프와 달리 모델 배포 루프는 모델 성능 최적화에 중점을 두지 않습니다. 대신 엔지니어는 프로덕션 환경에서의 체계적인 테스트, 배포, 모니터링에 중점을 둡니다.

여기서 개발자는 프로젝트 업데이트를 더 쉽게 하기 위해 구성을 YAML 파일로 옮길 수 있습니다. 또한 Pandas 대신 PySpark와 같은 더 강력한 프레임워크를 사용하여 정적 데이터 처리 파이프라인을 스트리밍 방식으로 실행되도록 리팩터링할 수 있습니다. 마지막으로 모델 품질을 유지하기 위해 테스트, 모니터링, 피드백 프로세스를 설정하는 방법을 고려해야 합니다.

이 시점에서는 자동화가 필수적이며, 지속적인 통합 및 제공은 필수 요구 사항입니다. Databricks에서 데이터 및 AI 프로젝트를 위한 CI/CD를 관리하는 데는 Databricks Asset Bundles 가 일반적으로 선택되는 도구입니다. 이를 통해 Databricks 리소스(예: 작업 및 파이프라인)를 소스 파일로 기술하고, 프로젝트의 소스 파일과 함께 메타데이터를 포함할 수 있습니다.

모델 개발 단계에서와 마찬가지로, 이 단계에서 생성형 AI 프로젝트와 기존 ML 프로젝트 간에 가장 많은 시간이 소요되는 활동은 동일하지 않습니다.

기존 ML 모델 배포 시간 소모 요인

• 리팩터링: 기존 machine learning 프로젝트에서 노트북 코드는 상당히 지저분할 수 있습니다. 다양한 데이터 세트, 피처, 모델 조합을 지속적으로 테스트하고, 폐기하고, 재결합합니다. 결과적으로 노트북 코드를 더 견고하게 만들기 위해 리팩터링하는 데 상당한 노력을 기울여야 할 수 있습니다. 정해진 코드 리포지토리 폴더 구조(예: Databricks 자산 Bundles MLOps Stacks 템플릿)가 있으면 이 리팩터링 프로세스에 필요한 스캐폴딩을 제공할 수 있습니다.
  
  리팩터링 활동의 몇 가지 예는 다음과 같습니다.
  • 헬퍼 코드를 함수로 추상화하기
  • 유틸리티 함수를 여러 번 가져와서 재사용할 수 있도록 헬퍼 라이브러리 생성하기
  • 노트북에서 YAML 파일로 구성 옮기기
  • 더 빠르고 효율적으로 실행되는 더 효율적인 코드를 구현하기(예: 중첩된 for 루프 제거) 
     
• 품질 모니터링: 데이터 오류는 다양한 형태로 나타날 수 있고 감지하기 어려워서 품질 모니터링은 시간을 많이 소모하는 또 다른 작업입니다. 특히 Shreya Shankar 등이 “Operationalizing Machine Learning: An Interview Study” 논문에서 언급했듯이, “데이터 포인트에 있는 몇 개의 null 값 특성과 같은 소프트 오류는 덜 해롭고 여전히 합리적인 예측을 생성할 수 있으므로 감지하고 정량화하기 어렵습니다.” 게다가 다양한 유형의 오류에는 각기 다른 대응이 필요하며, 적절한 대응을 결정하는 것이 항상 쉬운 것은 아닙니다.
  
  또 다른 과제는 다양한 유형의 모델 드리프트(피처 드리프트, 데이터 드리프트, 레이블 드리프트 등)를 다양한 시간 단위(일별, 주별, 월별)에 걸쳐 측정해야 하므로 복잡성이 가중된다는 점입니다. 프로세스를 더 쉽게 만들기 위해 개발자는 Databricks Data Quality 모니터링 을 사용하여 전체적인 프레임워크 내에서 모델 품질 메트릭, 입력 데이터 품질, 모델 입력 및 예측의 잠재적 드리프트를 추적할 수 있습니다.

생성형 AI 모델 배포 시 시간이 많이 소요되는 부분

• 품질 모니터링: 생성형 AI의 경우 모니터링에도 상당한 시간이 소요되지만 그 이유는 다릅니다.
  • 실시간 요구사항: 고객 이탈 예측, 가격 예측 또는 환자 재입원과 같은 작업을 위한 기존의 머신러닝 프로젝트는 하루, 일주일 또는 한 달에 한 번씩 실행되는 배치 모드로 예측을 제공할 수 있습니다. 하지만 많은 생성형 AI 프로젝트는 가상 지원 에이전트, 실시간 스크립트 작성 에이전트 또는 코딩 에이전트와 같은 실시간 애플리케이션입니다. 결과적으로 실시간 모니터링 도구를 구성해야 하며, 이는 실시간 endpoint 모니터링, 실시간 추론 분석 파이프라인, 실시간 알림을 의미합니다.
    
    Databricks AI Gateway와 같은 API 게이트웨이를 설정하여 LLM API에 대한 가드레일 검사를 수행하면 안전 및 데이터 개인정보 보호 요구사항을 지원할 수 있습니다. 이는 오프라인 프로세스로 수행되는 기존 모델 모니터링과는 다른 접근 방식입니다.
  • 주관적인 평가: 앞서 언급했듯이 생성형 AI 애플리케이션에 대한 평가는 주관적입니다. 모델 배포 엔지니어는 추론 파이프라인에서 주관적인 피드백 수집을 운영하는 방법을 고려해야 합니다. 이는 모델 응답에 대해 실행되는 LLM 심사관 평가의 형태를 띠거나, 모델 응답의 일부를 선택하여 도메인 전문가에게 평가를 의뢰하는 형태일 수 있습니다. 독점 모델 제공업체는 시간이 지남에 따라 모델을 최적화하므로 이들의 “모델”은 실제로는 성능 저하가 발생하기 쉬운 서비스이며, 평가 기준은 자체 학습 모델에서처럼 모델 가중치가 고정되어 있지 않다는 사실을 고려해야 합니다.
    
    자유 형식의 피드백과 주관적인 평가를 제공하는 기능이 가장 중요해집니다. Databricks Apps 및 MLflow Feedback API 와 같은 프레임워크는 이러한 피드백을 수집하여 특정 LLM 호출과 다시 연결할 수 있는 더 간단한 사용자 인터페이스를 지원합니다.
• 테스트: 생성형 AI 애플리케이션에서는 몇 가지 이유로 테스트에 시간이 더 많이 소요되는 경우가 많습니다.
  • 아직 해결되지 않은 과제: 생성형 AI 애플리케이션 자체는 점점 더 복잡해지고 있지만, 평가 및 테스트 프레임워크는 아직 이를 따라잡지 못하고 있습니다. 테스트를 어렵게 만드는 몇 가지 시나리오는 다음과 같습니다.
    • 여러 턴으로 이루어진 긴 대화
    • 기업의 조직적 맥락에 대한 중요한 세부 정보를 포착할 수도 있고 그렇지 않을 수도 있는 SQL 출력
    • 체인에서 올바른 도구 사용을 관리하기
    • 애플리케이션에서 여러 에이전트 평가하기
      이러한 복잡성을 처리하는 첫 번째 단계는 일반적으로 에이전트 출력의 추적(도구 호출, 추론, 최종 응답의 실행 기록)을 가능한 한 정확하게 캡처하는 것입니다. 자동 추적 캡처와 수동 계측을 조합하면 에이전트 상호작용의 전체 범위를 포괄하는 데 필요한 유연성을 확보할 수 있습니다. 예를 들어 MLflow Traces trace 데코레이터 는 모든 함수에 사용하여 입력과 출력을 캡처할 수 있습니다. 동시에 특정 코드 블록 내에 사용자 지정 MLflow Traces 스팬을 생성하여 더 세분화된 작업을 기록할 수 있습니다. 계측을 사용하여 에이전트 출력에서 신뢰할 수 있는 진실의 원천을 집계한 후에야 개발자는 실패 모드를 식별하고 그에 따라 테스트를 설계할 수 있습니다.
  • 사람의 피드백 통합: 품질을 평가할 때 이러한 입력을 통합하는 것이 중요합니다. 그러나 일부 활동은 시간이 많이 소요됩니다. 예를 들어, 다음과 같은 접근 방식이 있습니다.
    • 주석 작성자가 따를 가이드라인으로 루브릭 설계하기
    • 다양한 시나리오에 대해 다양한 측정항목과 평가 기준을 설계합니다(예: 출력이 안전한지 또는 유용한지).
      
      에이전트가 어떻게 응답해야 하는지에 대한 공유된 평가 기준을 만들기 위해서는 보통 오프라인 토론 및 워크숍이 필요합니다. 인간 주석가의 의견이 일치된 후에야 MLflow의 make_judge API 또는 SIMBAAlignmentOptimizer와 같은 함수를 사용하여 그 평가를 LLM 기반 판정기에 안정적으로 통합할 수 있습니다.

AI 기술 부채

기술 부채는 개발자가 장기적인 유지 관리성을 희생하면서 임시방편의 솔루션을 구현할 때 쌓입니다.

기존 ML 기술 부채

Dan Sculley 등은 이러한 시스템이 축적할 수 있는 기술 부채의 유형에 대한 훌륭한 요약을 제공했습니다. 그들은 논문 '머신러닝: 기술 부채의 고금리 신용카드' 에서 이를 세 가지 광범위한 영역으로 나눕니다.

• 데이터 부채 문서화가 제대로 되어 있지 않거나, 설명되지 않거나, 조용히 변경되는 데이터 종속성
• 시스템 수준 부채 광범위한 글루 코드, 파이프라인 '정글', '데드' 하드코딩된 경로
• 외부 변경 사항 수정된 임계값(예: 정밀도-재현율 임계값) 또는 이전에 중요했던 상관관계 제거

생성형 AI는 새로운 형태의 기술 부채를 야기하며, 그중 다수는 명확하게 드러나지 않을 수 있습니다. 이 섹션에서는 이러한 숨겨진 기술 부채의 원인을 살펴봅니다.

도구 확산

도구는 LLM의 기능을 확장하는 강력한 방법입니다. 하지만 사용하는 도구의 수가 늘어날수록 관리가 어려워질 수 있습니다.

도구 확산은 검색 가능성 및 재사용 문제를 야기할 뿐만 아니라 생성형 AI 시스템의 품질에 부정적인 영향을 미칠 수도 있습니다. 도구가 확산되면 다음과 같은 두 가지 주요 실패 지점이 발생합니다.

• 도구 선택: LLM은 다양한 도구 중에서 호출할 올바른 도구를 정확하게 선택할 수 있어야 합니다. 주간 판매 통계와 월간 판매 통계를 얻기 위해 데이터 API를 호출하는 등 도구가 거의 비슷한 작업을 수행하는 경우, 올바른 도구를 호출하기가 어려워집니다. LLM이 실수를 하기 시작할 것입니다.
• 도구 parameter: 호출할 적절한 도구를 성공적으로 선택한 후에도 LLM은 사용자의 질문을 파싱하여 도구에 전달할 올바른 parameter 집합으로 만들어야 합니다. 이것은 고려해야 할 또 다른 실패 지점이며, 여러 도구가 유사한 매개변수 구조를 가질 때 특히 어려워집니다.

도구 확산에 대한 가장 깔끔한 솔루션은 팀이 사용하는 도구를 전략적이고 최소한으로 유지하는 것입니다.

그러나 올바른 거버넌스 전략은 점점 더 많은 팀이 GenAI를 프로젝트와 시스템에 통합함에 따라 여러 도구와 액세스 관리를 확장 가능하게 만드는 데 도움이 될 수 있습니다. Databricks 제품인 Unity Catalog와 AI Gateway는 이러한 유형의 확장을 위해 구축되었습니다.

프롬프트 스터핑

최신 모델은 수 페이지 분량의 지침을 처리할 수 있지만, 지나치게 복잡한 프롬프트는 모순되는 지침이나 오래된 정보와 같은 문제를 유발할 수 있습니다. 이는 특히 프롬프트가 편집되지 않고, 시간이 지나면서 여러 도메인 전문가나 개발자에 의해 내용이 추가되기만 할 때 발생합니다.

다양한 실패 모드가 발생하거나 새로운 query가 범위에 추가될 때 LLM 프롬프트에 지침을 계속해서 더 많이 추가하고 싶은 유혹이 듭니다. 예를 들어, 프롬프트는 재무 관련 질문을 처리하기 위한 지침을 제공하는 것으로 시작한 다음 제품, 엔지니어링 및 인적 리소스 관련 질문으로 확장될 수 있습니다.

소프트웨어 엔지니어링에서 "god class"가 좋은 아이디어가 아니며 분리되어야 하는 것과 마찬가지로, 메가 프롬프트도 더 작은 단위로 분리해야 합니다. 실제로 Anthropic은 프롬프트 엔지니어링 가이드에서 이 점을 언급하며, 일반적인 규칙으로 길고 복잡한 프롬프트 하나보다는 여러 개의 더 작은 프롬프트를 사용하는 것이 명확성, 정확성, 문제 해결에 도움이 됩니다.

프레임워크는 프롬프트 버전을 추적하고 예상 입력 및 출력을 강제함으로써 프롬프트를 관리하기 쉽게 유지하는 데 도움이 될 수 있습니다. 프롬프트 버전 관리 도구의 예시로는 MLflow Prompt Registry가 있으며, Databricks에서 실행할 수 있는 DSPy 와 같은 프롬프트 옵티마이저는 프롬프트를 개별적으로 또는 전체적으로 최적화할 수 있는 독립적인 모듈로 분해할 수 있습니다.

불투명한 파이프라인

최근 추적(tracing)이 주목받는 데에는 이유가 있습니다. 대부분의 LLM 라이브러리와 추적 도구는 LLM 체인의 입력과 출력을 추적하는 기능을 제공하기 때문입니다. 응답이 "죄송합니다, 질문에 답변할 수 없습니다"와 같은 오류를 반환하는 경우, 중간 LLM 호출의 입력과 출력을 검토하는 것이 근본 원인을 정확히 파악하는 데 중요합니다.

저는 이전에 SQL 생성이 워크플로에서 가장 문제가 되는 단계일 것이라고 초기에 가정했던 애플리케이션 작업을 한 적이 있습니다. 하지만 추적 결과를 검토해 보니 이야기가 달랐습니다. 가장 큰 오류의 원인은 실제로는 사용자 질문의 엔터티를 데이터베이스 값과 일치하는 엔터티로 업데이트하는 쿼리 재작성 단계였습니다. LLM은 재작성이 필요 없는 쿼리를 재작성하거나 원래 쿼리에 온갖 종류의 추가 정보를 채워 넣기 시작했습니다. 이로 인해 후속 SQL 생성 프로세스가 정기적으로 엉망이 되었습니다. 여기서 추적은 문제를 신속하게 식별하는 데 도움이 되었습니다.

올바른 LLM 호출을 추적하는 데는 시간이 걸릴 수 있습니다. 기본으로 제공되는 추적 기능을 구현하는 것만으로는 충분하지 않습니다. MLflow Traces와 같은 프레임워크를 사용하여 앱에 관찰 가능성을 제대로 계측하는 것은 에이전트 상호 작용을 더 투명하게 만들기 위한 첫 번째 단계입니다.

인간 피드백을 수집하고 활용하기 위한 부적절한 시스템

LLM이 놀라운 이유는 몇 가지 간단한 프롬프트를 전달하고 결과를 함께 연결하면 뉘앙스와 지침을 정말 잘 이해하는 것처럼 보이는 결과물을 얻을 수 있기 때문입니다. 하지만 사용자 피드백으로 응답의 기반을 다지지 않고 이 길을 너무 멀리 가면 품질 부채가 빠르게 쌓일 수 있습니다. 이때 가능한 한 빨리 “데이터 플라이휠” 을 만드는 것이 도움이 될 수 있으며, 이는 세 단계로 구성됩니다.

• 성공 지표 결정하기
• 사용자가 효과가 있는 부분에 대한 피드백을 제공하는 데 사용할 수 있는 UI를 통해 이러한 측정항목을 측정하는 방법을 자동화합니다.
• 측정항목을 개선하기 위해 프롬프트 또는 파이프라인을 반복적으로 조정하기

저는 스포츠 통계를 쿼리하는 text-to-SQL 애플리케이션을 개발하면서 인간 피드백의 중요성을 다시 한번 깨달았습니다. 도메인 전문가는 스포츠 팬이 데이터와 어떻게 상호작용하고 싶어 하는지, 무엇을 중요하게 생각하는지를 명확히 설명해 주었고, 스포츠를 거의 보지 않는 저로서는 결코 생각하지 못했을 다른 인사이트를 제공해 주었습니다. 그들의 의견이 없었다면 제가 만든 애플리케이션은 사용자의 니즈를 충족하지 못했을 것입니다.

사람의 피드백을 수집하는 것은 매우 중요하지만, 보통은 시간이 너무 많이 걸립니다. 먼저 도메인 전문가와 시간을 조율하고, 전문가 간의 차이를 조정하기 위한 평가 기준을 만든 다음, 개선을 위해 피드백을 평가해야 합니다. 비즈니스 사용자가 액세스할 수 없는 환경에서 피드백 UI가 호스팅되는 경우, IT 관리자와 협의하여 적절한 수준의 액세스 권한을 제공하는 과정이 끝이 없는 것처럼 느껴질 수 있습니다.

정기적인 이해관계자 점검 없이 빌드

올바른 결과물을 만들고 있는지 확인하기 위해 최종 사용자, 비즈니스 스폰서, 인접 팀과 정기적으로 협의하는 것은 모든 종류의 프로젝트에서 기본입니다. 하지만 생성형 AI 프로젝트에서는 이해관계자와의 소통이 그 어느 때보다 더 중요합니다.

빈번하고 긴밀한 커뮤니케이션이 중요한 이유:

• 소유권과 통제권: 정기적인 회의는 이해관계자가 애플리케이션의 최종 품질에 영향을 미칠 방법이 있다고 느끼도록 돕습니다. 비평가에 그치는 대신 협력자가 될 수 있습니다. 물론 모든 피드백이 다 똑같지는 않습니다. 일부 이해관계자들은 필연적으로 MVP에 구현하기에는 시기상조이거나 현재 LLM이 처리할 수 있는 범위를 벗어나는 것들을 요청하기 시작할 것입니다. 달성할 수 있는 것과 없는 것에 대해 모든 사람과 협상하고 교육하는 것이 중요합니다. 그렇지 않으면 또 다른 위험이 나타날 수 있습니다. 즉, 제동 없는 과도한 기능 요청입니다.
• 우리가 무엇을 모르는지 모른다는 점: 생성형 AI는 매우 새로운 기술이므로 기술 및 비기술 인력을 막론하고 대부분의 사람들은 LLM이 무엇을 제대로 처리할 수 있고 없는지 알지 못합니다. LLM 애플리케이션을 개발하는 것은 관련된 모든 사람에게 배움의 과정이며, 정기적인 소통은 모두에게 최신 정보를 계속 공유하는 방법입니다.

생성형 AI 프로젝트에서는 적절한 데이터 액세스 제어 시행, 안전을 관리하고 프롬프트 주입을 방지하기 위한 가드레일 마련, 비용 급증 방지 등을 포함하여 해결해야 할 다른 여러 형태의 기술 부채가 있을 수 있습니다. 여기서는 가장 중요해 보이면서도 쉽게 간과될 수 있는 것들만 포함했습니다.

결론

고전적인 ML과 생성형 AI는 동일한 기술 분야의 서로 다른 종류입니다. 두 시스템 간의 차이점을 인식하고 이러한 차이점이 솔루션을 구축하고 유지 관리하는 방식에 미치는 영향을 고려하는 것이 중요하지만, 어떤 진실은 변하지 않습니다. 즉, 소통은 여전히 격차를 해소하고, 모니터링은 여전히 재앙을 예방하며, 깨끗하고 유지 관리하기 쉬운 시스템은 장기적으로 혼란스러운 시스템보다 여전히 뛰어난 성능을 발휘합니다.

귀 조직의 AI 성숙도를 평가하고 싶으신가요? 가이드 읽기: AI 가치 실현: 기업을 위한 AI 준비 가이드.

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)