[요즘 우아한 AI 개발] Part 2 프롬프트 엔지니어링

Part 2 - AI로 더 편리한 서비스 만들기 

 

배민 검색

•  이제 "치킨"같은 음식 이름뿐만 아니라 "금요일", "매운", "해장음식" 등 키워드를 넣어도 추천해줌

 

프롬프트 엔지니어링

 

구체적인 프롬프트 작성

• 상황과 형식을 명확하게 제시
  • 예: "첨부한 문서를 요약해주세요" -> "첨부한 회의록을 3가지 핵심 사항으로 요약하고 마크다운 형식으로 정리해주세요."
  • 예: "저화질인지 판단하세요" -> "이미지 내부의 주요한 객체가 선명하지 않거나 화질이 깨졌는지 판단하세요."

 

프롬프트 일반화

• 프롬프트를 너무 구체화하면 예외 케이스를 놓칠 수 있다.
  • 예: "워터마크처럼 합성된 글씨가 있는지 판단하세요"
  • 워터마크는 잘 잡지만, 다른 합성 텍스트는 놓칠 수 있다.
  • -> "워터마크와 같이 인위적으로 합성된 글씨가 있는지 판단하세요."

 

응답 최적화

• 구조화된 응답 유도
  • 응답을 JSON 형식으로 포매팅하여 반환하도록 적용
• 생성 지식 프롬프트(Generated Knowledge Prompting)
  • LLM이 자체적으로 생성한 지식을 활용하여 특정 질문에 대한 응답을 강화하거나 보완하는 프롬프트 설꼐 기법. 모델이 학습 데이터 외부의 지식을 포함한 질문에 답변할 때 활용된다.
  • 이는 생각의 사슬(Chain of Thought, CoT)와 유사한 방식
    • 예: GPT가 이미지 내부의 모습 설명을 생성하고, 이 설명을 바탕으로 최종 응답을 도출하도록 하는 방법
    • 이렇게하면 응답의 일관성이 약 40% 향상됨
• Latency 최적화
  • input 프롬프트 최적화도 필요하지만, 불필요한 응답을 줄이는 것이 훨씬 중요하다.
  • 예: 응답 사유를 한 문장으로만 반환하도록 하기

 

 

프롬프트 구조와 형식 개선

• 이미지와 테스트 순서
  • 이미지와 텍스트를 함께 사용할 때는 이미지를 텍스트 프롬프트보다 먼저 배치하는 것이 도움된다. -> 응답 정확도 향상
• 마크다운과 코드 스타일 활용
  • 텍스트 프롬프트를 구조화하기 위해 마크다운 형식을 활용
  • 중요한 내용을 강조하기 위해 헤더(#)를 사용해 섹션을 구분
  • 여러 정보나 정책 항목을 나열할 때는 목록 형태로 표시
  • 프롬프트의 전체적인 구조를 코드 스타일로 정리(파이썬의 딕셔너리같은 데이터 구조로)

# instructions = '이미지를 정책(policies)에 따라 분석하고 지정된 JSON 형식으로 결과를 반환하세요.'
# policies = { 
	1: '주요한 음식에 초점이 맞지 않습니다.', 
	2: '해상도가 낮아서 픽셀단위로 질감이 보입니다.'
	# (생략) 
}

 

 

GPT 한계 극복: 하이브리드 접근의 필요성

• 이미지 속 객체 인식 잘 못 함 -> 정확한 객체 탐지 및 좌표 반환을 못 함
  • gpt 파인 튜닝: https://openai.com/index/introducing-vision-to-the-fine-tuning-api/
• 저작권/상표권/초상권 등 이미지 속에 포함된 캐릭터나 로고에 저작권 문제 없는지 판단 못 함 -> 최신 캐릭터에 대한 정보를 몰라서

 

실시간 반응형 추천 시스템

어떻게 하면 짜장면을 먹고 싶은 사용자에게 중식 가게를, 아이스 아메리카노가 갑자기 당기는 사용자에게 카페를 추천할 수 있을까?

• 3 가지 컴포넌트를 개발
  1. 실시간 행동 이력 스트리밍
  2. 인코더 모델 학습 및 임베딩 추출
  3. 벡터 유사도 검색 (Vector Similarity Search, VSS)

 

컴포넌트 1: 실시간 행동 이력 스트리밍

• 사용자가 클릭한 가게나 검색한 검색어 등의 행동 이력을 실시간으로 스트리밍해 몽고디비에 적재
• 실시간 행동 이력 조회 API를 통해 몽고디비에 적재된 사용자의 행동 이력을 조회
• Apache Flink + Amazon EKS(Elastic Kubernetes Service)로 실시간 로그 파이프라인 구축

 

컴포넌트 2: 인코더 모델 학습 및 임베딩 추출

• 가게와 검색어를 같은 벡터 공간에 임베딩 형태로 표현하는 인코더 모델을 개발
• 가게의 메타 정보와 검색 로그 등을 활용해 가게와 검색어가 유사할수록 더 가까운 벡터 공간에 위치시키는 인코더 모델을 학습시킴.
• 학습된 인코더 모델로 가게 및 검색어의 임베딩을 추출하고, 이를 VSS 컴포넌트가 사용하는 VectorDB에 업로드

 

컴포넌트 3: 벡터 유사도 검색

• 사용자의 행동 이력과 추천 후보 가게 간의 유사도를 계산
• 사용자의 행동 이력과 추천 후보 가게 목록이 주어졌을 때 벡터디비에서 각 임베딩 값을 조회한 후, 이들 사이의 코사인 유사도를 계산해 응답하는 컴포넌트를 개발.
• 여기서는 AWS RDS PostgreSQL을 벡터디비로 사용.

 

 

벡터 유사도 검색

• Exact-KNN(K-Nearest Neighbor)
  • 임베딩 벡터 공간 내의 좌표 간 거리를 정확하게 계산하는 것
• ANN(Approximate Nearest Neighbor)
  • recall(재현율)을 합리적으로 희생하면서도 검색 성능을 올리는 알고리즘
  • Exact-KNN보다 많이 쓰임
  • IVFFlat이나 HNSW 같은 알고리즘이 이 예다.
  • ANN 알고리즘은 미리 인덱스를 빌드해놓고, 검색 시점에서는 인덱스를 통해 성능을 향상시키는 방식의 알고리즘이다. 
• 고려 사항
  • 검색 대상 후보군을 좁힌 다음에 이 후보군에 대해서만 벡터 유사도 검색을 진행하면 인덱스 빌드 시점에 전체를 대상으로 만든 인덱스를 활용하기 어렵다.
• HNSW 알고리즘에서 보는 pre filter의 문제
  • HNSW는 일종의 그래프를 활용하여 가까운 검색 대상을 효율적으로 찾는 알고리즘이다. 
  • 모든 연결 그래프를 다 탐색하면 시간이 걸리니, 미리 검색에 사용할 밀도를 낮춘 그래프를 레이어 기반으로 인덱스 빌드 시점에 만들어둔다.
  • ANN의 성능 개선은 대체로, 검색 전에 데이터를 기준으로 미리 인덱스를 만들고, 검색 시점에 인덱스를 사용하는 데서 나온다.  우리의 프리 필터 문제는 좁혀둔 후보군에 대응하는 인덱스가 없기 때문에 ANN을 사용할 수 없다.

 

 

 

 

---

기억에 남는 내용

• 벡터 유사도 검색에서 pre filter 문제

 

출처

- [요즘 우아한 AI 개발]