LLM 애플리케이션 운영 기록

LLM 애플리케이션을 운영하면서 느낀 점...

• 쌓인 데이터를 보고, 패턴을 찾아 프롬프트에 반영하는 작업을 반복해야 한다.
  • 패턴은 프롬프트에 지시로 적을수도, few-shot 에 추가할수도, 또는 RAG 로 추가할수도 있다.
  • 패턴을 어떻게 찾을까? 정답이 없는것 같다.
• 어느 부분이 백엔드 영역인지, AI 엔지니어링 영역인지에 대해 연속적인거 같다.
  • 같은 기능도 비즈니스 로직으로 해결하는게 나을수도, 프롬프트로 해결하는게 나을수도 있다.
  • 이걸 백엔드 개발자와 AI 엔지니어가 협업하는 구조로 일하면 효율이 떨어질거 같다. (한사람이 해야 한다.)

• LLM 애플리케이션이 잘 작동할까? 는 프로덕션에 올려야 알 수 있다.
  • 잘 짜여진 실험, 테스트여도 실제 프로덕션에 쌓이는 데이터를 봐야 정확한 걸 알수있다.
  • 실제 유저 데이터가 쌓이기 전까지는 앱이 안정적으로 작동하는지 알 수 없다.
  • 사용자를 받는것이 무조건 유리하다. 그게 실제 고객이던, 사내 테스트이던, 베타 테스트이던..
  • 빠르게 1000명의 사용자를 받고, 오류를 수정하는 동안 초기 이탈률이 높을건데 (서비스 품질이 초기에 낮아서), 이걸 택하던지 또는 더 비싼 내부 인력(내부 사용자) 를 통해 데이터를 쌓을건지 의사결정을 해야 한다.

• LLM 애플리케이션 개발에서 가장 중요한 것은

1. 평가 - 테스트셋에 대해 잘 작동하는가 (실험 데이터, 운영 데이터 포함)
2. 프롬프트 엔지니어링 - 도메인 지식이 프롬프트로 구현되고, 그게 효율적이어야 한다. 프롬프트 기법, RAG, agent 등 본질은 프롬프트를 잘 짜는것에 있다.

• human-in-the-loop 패턴이라고, 앱이 잘 작동하는지 사람이 검증하는게 현재는 좋은거같다. 대안이 없다.

• LLM 애플리케이션을 개발하는 것 (AI 엔지니어)은 AI 리서처와, 소프트웨어 엔지니어의 중간 지점에 있는 역할인 것 같다. 내 입장은 소프트웨어 엔지니어니까,
  • 소프트웨어 엔지니어가 이 영역을 시도하면 제품화를 빠르게 할 수 있다.
  • 그러나 AI 에 대해 이론적으로 탄탄하지 않아서, 한계가 찾아왔을때 해결하기가 어렵다.
  • 서로 다른 백그라운드를 가진 사람과 협업하는게 베스트가 아닐까? 시간이 지나면 누군가는 둘 다 할수 있겠지만..