실시간 LLM 파이프라인을 위해서라면?
- 좋은 프롬프트를 만들어야 한다.
- 반복된 실험과 평가가 핵심
- 평가 데이터셋 마련하기
- 중요한 엣지 케이스 포함하고 보완하기
- 자동화된 배치 평가 파이프라인 마련하기
- 배치 평가 파이프라인
- 평가 데이터셋에 배치 평가와 프롬프트 개선 반복하기
- 프로덕션 파이프라인
- 프로덕션 실시간 인퍼런스
- 온라인 지표 모니터링
- 샘플링 분석으로 프롬프트 개선
- 좋은 프롬프트를 만드는 노하우를 체계화하기
- 구분자로 구조를 명확하게표현하기
- 마크다운 문법 사용하는 것도 도움이 된다.
- XML 스타일 태그또한 도움이 된다.
- 요구사항을 구체화하기
- 예) 여러 필드를 가진 사용자 데이터에서 개인정보를 개인정보가 무엇인지 어떻게 제거하고 싶은지 세부사항을 명확하고 구체적으로 지시하기
- 미쳐 생각하지 못한 요구사항을 발견 시 피드백을 통해 강화해나가기
- 예시 활용하기
- 예시를 과하게 주면 안된다. 그 예시에 편향된 데이터를 뱉을 확률이 높아지기 때문이다.
- 예시는 제한적으로 사용하기
- 생각하고 말하게 하기
- 바로 결과를 생성하게 하기보다 단계별로 사고 과정을 작성하도록 한다
- Chain of Thought Prompting (CoT)
- Constrastive Chain Of Thought
- 사용자 인풋을 바로 처리하지 않고 한번 생각하고 말한다.
- 결과를 단순히 말하게 하지 말고, 추론한 이유까지 말하게 하기
- 요약을 먼저 하고 분류하기
- 조건을 먼저 판단하고 조건에 따라 처리하게하기
- Pseudo-Code로 지시하기
- 지사사항과 사용자 입력의 순서도 영향을 준다
- LLM도 요구사항이 컨텍스트가 길면 까먹는 경우가 있다. 따라서 중요한 요구사항이라면 뒤에 배치하는 것도 좋은 방법이다.
- field 이름도 영향을 준다
- 잘 모르면 지어낸다 (할루시네이션)
- 조건을 벗어나거나 예외인 경우 어떻게 처리할지 알려주는 것도 좋다.
- 다시 데이터로 활용하기 위해선 특정 형식으로 출력하게 하기 (json)
- LLM이 json 형식으로 줘도 원하는 형태에서 벗어나는 경우는 후처리한다.
- 실패를 대비하기
- LLM API도 장애날 수 있다.
- 프로덕션이 의존하고 있다면 장애에 대비
- 모델 수명 고려하기
- 기존 버전은 제한된 수명을 가진다. (마치 언어 LTS 버전 유무 처럼)
- 모델의 수명을 반드시 확인해야 한다.
- 성능 평가 후 프롬프트 수정을 통해 성능을 유지해야 한다.
- 사용량 고려하기
- LLM API 사용량 제한하기
- 그렇지 않는다면 모든 파이프라인의 장애로 이어질 수 있다.
- 서비스와 기능의 성공에 집중하기
- 구축하려는 서비스 또는 기능의 성공
- 프로덕션에 성공을 측정하는 지표 관찰 및 집중 - 모니터링에 초점을 맞추기.