회사 출근 대신 AWS Startup 이벤트에 간 날
사실, 안드로이드 앱 개발자로써 aws 서비스를 직접적으로 사용해본 경험이 많지 않다
그래서 aws infra 라던가 백엔드 관련 서비스에 대한 기초지식이 부족한 상태였고, 발걸음을 때보고자 최신 트랜드도 볼 겸 참여하게 되었다
✏️ From Data to AI : ‘AWS로 시작하는 Generative AI’
이번 컨퍼런스는 AI 기능을 AWS 서비스와 결합해서 함께 쓰는 것에 중점을 두었다
2024년은 생성형 AI POC에서 Production으로 전환할 것
회사 내 workflow에 AI가 점점 도입할 것이다
그러나 AI로 부터 시작해서 Production이 되려면 걸림돌들이 존재한다
- 콘텐츠 신뢰성: LLM 편향, 환각에 대한 통제
- 프롬프트 생성 비용 적절성
- 데이터의 깊이, 품질
- Responsible AI를 위한 안전장치
이러한 점들로 파운데이션 모델은 완벽하지 않고, 따라서 회사는 Responsible Ready에 대한 준비가 필요하다
파운데이션 모델: 대규모 데이터 세트를 바탕으로 훈련된 대규모 딥러닝 신경망 모델
이 아래부터는 강연을 들으며 메모한 내용으로, 즉석에서 들으며 작성한 터라 틀린 부분이 있으면 지적 부탁드립니다
AI 언제 무엇을 사용하는지?
- 일반적 실시간X, 간단하고 일반적일 때 → 프롬프트 엔지니어링
- 일반적 실시간X, 작업이 복잡하거나 특정 도메인에 최적화 → 파인튜닝
- 외부정보 또는 최신정보가 필요, 비교적 정적인 정보 → 임베딩 기반 검색 OR RAG (가지고 있는 지식을 활용할 수 있게하는 기술)
- 외부정보 또는 최신정보가 필요, 동적인 정보(오늘 날씨, API, 실시간 인터넷, 주식) → ReAct, tools, Agents 등을 통해 보강
- 좋은 프롬프트를 만들기 위해서?
- XML 태그, 예시 사용..
프롬프트 엔지니어링 사용 예시
- 사용자의 리뷰에 대한 감정 분석
- 상품의 메타데이터 JSON 자동 생성
- RAG(Retrieval Augmented Generation) 사용 예시
- LLM을 이용한 대화형 봇(Context를 동적으로 제공)
RAG 원리
- 정보들을 VECTOR DATA STORE에 저장
- 기존에는 정확히 맥락이 일치해야 검색이 가능했으나, 이제는 유사도에 따라 검색할 수 있게 되었다. (시멘틱 서치)
RAG 구현이 어려운 이유
- 검색이 잘 안됨
- Vector search, Lexical Search(키워드 기반)의 검색전략 필요
- 데이터 Ingestion이 어려움
- 데이터를 어떤 단위로 분할해서 저장할지
- 이미지나 표, PDF, PPT 등 복잡한 문서 처리
- 해결방안
- Advanced RAG 패턴
- Lexical 및 Semantic 동시 고려 (Hybrid search)
- Query + Context 동시 고려한 relevance
- ReRanker 라는 검색 후 점수를 판별하는 시스템을 도
- Advanced RAG 패턴
Agents란?
- 결과나 환경에 대해 관찰하고 관찰 결과를 판단 후 행동을 반복하여 최종 작업 수행
- 연결가능 서비스
Agents 내 기능 Function Calling
- 특정 질의에 함수를 미리 정의할 수 있는 기능
- Agents ↔ Bedrock 연동
- Lambda 연결 가능
Agents 활용 예시
- 현재 사용자의 취향에 맞는 상품 추천
파인튜닝
- 모델 가중치 조정
파인튜닝 활용
- 큰 사이즈 모델
- AWS SageMaker 를 이용한 파인튜닝
- 작은 사이즈의 모델(LLAMA3, Claude 3 Haiku)을 이용한 파인튜닝
- AWS Bedrock 활용
- stable diffusion 모델에 사용자 얼굴 학습(LoRa)
- Inpainting을 이용해 이미지를 자유롭게 수정
- SAM을 활용하면 좀 더 손쉬움
생성형 AI를 왜 사용해야 하는가?
- 애플리케이션 유즈케이스에 맞는 설계 필요
- 파운데이션 모델 활용 및 패턴, 신뢰성, 비용, 프로토타이핑, 보안, 인프라
- 구현 패턴
✏️생성형 AI를 위한 end to end 데이터 전략
현재, AI는 환멸의 골짜기 상태
데이터 전략, 구성요소
- Generative AI - 생성형 AI
- Embedded intelligence - 리소스가 제한된 디바이스나 시스템에 AI를 통합
- Data partnering - 데이터를 추상화, 분리
왜 중요한가?
- 더 빠르게 나은 의사 결정
- e.g 건강 형평성 개선
- 예상치 못한 상황에 대응
- e.g 중고 사기 감소
- 고객 경험
- e.g 음식,여행지 개인화 추천
현대적 데이터 전략
- Mindset(신조) - 프로덕트 중심, 고객 집중
- 실행가능한 인사이트를 창출, 고객의 경험 향상, 더 많은 것을 요구하게 끔 만듬
- 크게 생각하고, 작게 시작하고, 빠르게 확장
- 비즈니스 IT 오너십 확대
- 비즈니스 우선순위를 빠르게 전달하는데 집중
- 데이터 생산자와 소비자 전반의 민첩성 향상
- 개인정보 보호, 보안 및 규정 준수를 통해 신뢰와 자신감 구축
- 핵심 원칙(Tenet)을 수립하고 경영진부터 소통하기
- e.g 특정 유즈케이스를 지원하는데 꼭 필요한 경우에만 데이터를 이동한다
- 데이터를 활용하여 시장에서 경쟁사와 차별화된 서비스를 제공한다 등..
- e.g 특정 유즈케이스를 지원하는데 꼭 필요한 경우에만 데이터를 이동한다
- 어떻게?
- 비즈니스 전략 목표와 연계
- Business priorities
- Usecase
- K..?
- 비즈니스 전략 목표와 연계
- 실행가능한 인사이트를 창출, 고객의 경험 향상, 더 많은 것을 요구하게 끔 만듬
- People & Process - 교차 기능 조직, 자율, 연합 민첩
- 조직 모델 조정하기
- 기존 방법
- 중앙 집중식 거버넌스 및 제어 (규제가 심한 도메인, 제어에 대한 인덱스 초과) - 느린 의사 결정, 병목 현상 등 문제 발생
- 비즈니스 라인 내 분산 (자급자족하는 팀, 비즈니스/기술 연계) - 규정 준수 및 보안 위험, 제한된 제어, 설계상 중복 발생
- 그래서 어떻게 해야하나?
- “현대적 데이터 커뮤니티를 통한 균형 잡힌 접근 방식” (탈중앙화된 의사 결정)
- 데이터 생산자 ↔ 데이터 마켓플레이스 ↔ 데이터 소비자
생산자 - 공급업체, 고객, 직원, 프로덕트
마켓플레이스 - 데이터 품질 및 ETL 도구, 데이터 카탈로그
소비자 - 재무보고, 수요 예측 모델
프로덕트 사고방식
1차 프로덕트 - 원천 데이터 e.g 거래기록, 고객정보, 로그
n차 프로덕트 - 파생 데이터 e.g 고객 세그먼테이션
n차 프로덕트 - 알고리듬 e.g 고객 이탈 모형
n차 프로덕트 - 의사 결정 지원 e.g 고객 분석 대시보드
2Pizza 데이터팀 구성 예시
데이터 과학자/데이터 인프라/ …
단일 스레드 리더십
민첩성, 협업, 생산성 향상
도메인 지향 및 교차 기능
신속한 실험과 혁신
- 데이터 생산자 ↔ 데이터 마켓플레이스 ↔ 데이터 소비자
- “현대적 데이터 커뮤니티를 통한 균형 잡힌 접근 방식” (탈중앙화된 의사 결정)
- 기존 방법
- 조직 모델 조정하기
- Technology - 목적에 맞게 구축, 유연성, 확장성
현대적 데이터 거버넌스를 만들기 위한 순서?
- 우리의 회사가 어떠한 단계에 있는지 파악해야 한다.
- 프로덕트 중심의 사고, 지금 우선 필요한 것은?
AWS DataZone 활용
- 생산자가 데이터를 안전하게 공유 가능
- e.g 데이터를 이동/복제하여 공유하면 규정이 위반될 수 있음, 이를 안전하게 처리하기 위해
D2E program
- 마인드셋 도움
✏️ Text2SQL
유저가 데이터에 접근을 원할 때, 자연어 → SQL로 변환
Schema Linking - 어느 테이블에서 어느 정보를 찾을지 자연어와 연결시켜 주는 것
프롬프트 엔지니어링 과정
- 모든 테이블 스키마 주입
- 테이블이 많으면? → 학습(파인튜닝)을 시키면 된다
- Instruction-based FT이 가능한가 자연어-SQL 데이터셋이 많아야해서 보통 어렵다
- 테이블이 많으면? → 학습(파인튜닝)을 시키면 된다
- SQL 쿼리 생성에 필요한 정보를 검색해서 쓰자
- 테이블 이름/설명/쿼리, 컬럼이름/타입 등 메타정보 이용.. 어렵다
- RAG로 테이블을 검색
- Table정보는 LLM으로 요약한다. LLM에게 명령문을 만들 수 있도록 설명
- 생성된 Query가 정확하고, 실행 가능해야 함
- 참고할 샘플을 제공하자
- 질의와 관련있는 샘플을 제공
- RAG로 샘플쿼리도 검색해서 제공
- 쿼리에 대한 설명도 LLM으로 만들 수 있게 한다
- 참고할 샘플을 제공하자
Text-To-SQL 모델 순위
- PET-SQL
- DAIL-SQL + GPT4 + Self-Consistency
- …
파운데이션 모델을 우선 사용하면 스트레스를 덜 받을 것..
Agent, tools를 어떻게 사용할까?
- 오케스트레이션이 중요
용도에 따른 적절한 방법
- 테이블/샘플이 적을 때 - 프롬프트
- 자연어, 쿼리 데이터가 많으면 - 파인튜닝
- 테이블/샘플이 너무 많으면 - RAG(검색 증강 생성)로 검색
✏️ RAG 심화
프롬프트 엔지니어링 기법들
- 제로샷 Zeroshot 프롬프팅 (예시없이 LLM에게 작업 수행 요구하는 기법)
- LLM의 일반화된 학습 능력을 활용
- 퓨샷 Few-Shot 프롬프팅
- LLM에게 몇 가지 예제를 제공하여 특정 작업을 참조하도록 하는 프롬프트 엔지니어링 기법
- 데이터 부족 상황에서 유용
- 수학적 판단에서 정확도 하락
- 사고의 페인 Chain-of-Thought 프롬프팅
- 복잡한 추론 문제 해결을 위해 사고의 단계를 연속적으로 기술하도록 하는 기법
- 사고의 단계를 명확히 기술, 대수학적 풀이 과정과 유사한 접근 방식
- 프롬프트 체인 Prompt Chain
- 복잡한 작업을 효과적으로 수행하기 위해 여러 연속된 프롬프트를 활용하는 방법
- 각 단계에서 생선된 출력을 다음 단계의 입력으로 사용하여 문제 해결 유도
- 리액트 ReAct(Reason + Act) 프롬프팅
- LLM이 reasoning traces와 task-specific action를 상호 교차하여 생성 (agent 컨셉의 기초로 사용됨)
- 사고 과정을 추적하고 업데이트하며, 외부 정보와 상호작용하여 정확한 응답 생성
- 인간의 학습, 의사결정 모방
Agent란?
- 어떤 목적을 달성하기 위해, 사용자와 환경, 즉 외부 시스템과 상호작용을 통해 어떤 액션을 취할 수 있는 기능
- LLM Agent Framework
- 일반적인 기능을 가진 대형 언어 모델 LLM이 브레인 역할 수행
- 프롬프트 템플릿을 통해 에이전트의 운영 방식 및 사용 가능한 도구 정의
- 잦은 LLM호출로 인한 Latency 와 비용의 증가를 고려해야 함
- agent를 더 잘 사용하기 위해? Multi agent 전략들 활용하기
- 여러가지가 있다..
Multi Agent - sLM 파인튜닝하기
- 단순한 모델에 사용하기에는 아깝다
- 복잡한 모델을 위해서 사용.
- PEFT(parameter-efficient fine-tuning)
검색 증강 생성(RAG)
- 검색 유형
- 규칙 기반 - 문서 비정형 데이터
- 구조화된 데이터
- 시맨틱 검색 - 단어 기반 등
일반적인/고급 RAG 차이
- Pre-Retrieval
- chunk 데이터를 추가
- Hybrid-fusion
- Lexical + Semantic
정확도는 정답의 Context 내 위치와 관련
LLM이 컨텍스트 내에 처음이나 끝에 관련 정보를 두는것이 효과적
나머지 내용은 검색 후 작업 …
기존의 정적인 데이터를 기반으로 한 AI의 한계점을 해결하기 위해
Retrieval Augmented Generation (RAG) 사용
User → Embedded Database → Vector Database → Prompt…
실제 데이터는 Vector Database에 저장
Embedding 과정을 통해 사용자 질의에 3차원 형태인 Vector Database에서 정보를 가져오며,
Prompt 결과에 통합
속도를 높히기 위한 기법
- IVFFlat: 거리 기반, 그룹화
- HNSW: 그래프 기반, 자식 추가, 시간이 조금 더 걸린다
나머지는 bedrock과 postgre를 통해 RAG 만드는 과정
Streaming pipeline
데이터는 시간이 지날수록 가치가 떨어진다
Source → Stream ingestion(소스를 외부나 AWS서비스로 넘김) → Stream storage(데이터를 받은 순서대로 설정된 기간동안 보존/저장) → Stream processing → Destination
데이터 처리 차이
- 배치: 주기적, Bounded data sets(tables)
- 스트리밍: 연속적, Unbounded data sets (streams)
Stream ingestion 서비스
- AWS DMS 등..
Stream storage 서비스
- Amazon kinesis data streams
- Amazon MSK, Apache kafka
Stream processing 서비스
- AWS Lambda - 손쉬운 프로그래밍, 인터페이스 확장
- Amazon Managed Service for Apache Flink - 낮은 지연
- AWS Glue
ⓒ 굿햄 2024. daryeou@gmail.com all rights reserved.
댓글