LLM In Production (feat: Project Pluto)

이 글은 LLM Application In Production 강의를 보고 간추려서 정리한 글입니다.

 

Supernews App:

• LLM 을 전문적으로 사용해서 뉴스를 제작하고 있는 Financial Media 앱임
• 하루 최대 1천개의 기사를 제공해준다고 함.
• 중요한 건 글을 써주는 저널리스트 없이 오로지 LLM 이 뉴스를 제작해준다는 점임.

 

데이터 파이프라인 구축:

• RAG 기반의 검색을 위해 다양한 소스들 (e.g WSJ (The Wall Street Journal), CNBC, Bloomberg, Reddit, Twitter) 에서 나온 데이터들을 ELT 방식으로 저장을 하는 것.
• ETL 방식이 아닌 이유는 데이터를 여러 transfrom 방식으로 사용될 수 있기 때문임.

 

RAG Pipeline:

• 하나의 기사를 LLM 이 쓰기 위해서는 다양한 LLM Api Call 을 거치게 되고, 다양한 Vector Store 에서 데이터를 검색하기도 하고, 다양한 외부 데이터를 검색해서 사용하기도 한다. Google 검색이라던지.

 

RAG 를 Production 에서 잘 사용하기 위해서 해결해야하는 문제들:

• 팩트에 기반한 대답이 아니라 잘못된 정보를 뱉어내는 Hallucination 문제
• 연관이 없는 데이터를 기반으로 LLM 이 답변을 하게 드는 Poor Data Retrieval
• LLM 이 제대로 기능을 수행하고 있는지 판단하기 위한 Evaluation
• LLM 을 API 로 이용하는 건 비용이 들어가는데 보다 비용 효율적으로 LLM API 를 사용하는 문제들
• 급증하는 트래픽으로 인해 LLM API Call 이 Rate Limit 에 도달하는 문제들

 

VectorDB Selection:

• 여러가지 Vector Store 가 있지만 Elasticsearch/Opensearch 가 좋아보인다. 결국에는 연관있는 데이터를 잘 찾아오는게 중요한데, Elasticsearch 는 Hybrid 검색 (기존 검색 방식 + 유사성 검색) 이 둘 모두를 제공해주니까.
• Hybrid Search 라고 한다면 Keyword 검색인 (BM25, SPLADE 등) 과 Semantic 검색을 합친 걸 말함.
• 물론 이것 외에도 여러 요구사항이 있을거임. Developer-friendly, 시스템의 안정성 등

 

RAG 에서 중요한 것은 Prompt 안의 Valuable 한 공간을 Context Rich 하게 넣어주는 것이 중요하다:

• 이걸 위한 방법으로 Project Pulto 에서는 Chunk 를 되도록 짧게 쪼개는 방식임. 이게 왜 유용하다고 판단했냐면 유사성 검색을 해서 해당 매칭되는 Chunk 가 있다면 그 Chunk 와 연관관 앞 뒤 Chunk 도 추가 조회해서 Context Rich 하게 뽑아낸다고 함.
• 이런 방식들 중 하나로 Chunk 들을 계층을 매겨서 (= Chunk Hierachy) 조립해서 Context 를 풍부하게 만든다고 함.
• 중요한 건 파편적인 Chunk 들로 구성하기 보다는 연관있는 Chunk 들을 합쳐서 하나의 완전한 글을 빌딩하는게 중요하다고 생각한다.
  • 이래서 RAG 에 지식 그래프 형태가 등장하는건가 싶다.
  • 처음 질문과 연관있는 Chunk 를 뽑은다음에 해당 Chunk 와 연관되어있는 다른 Chunk 들을 검색해서 합치는거지. 그렇게 완전한 Context 를 만드는 것.
  • 이 경우에 끝도없이 찾아낼 수 있기 때문에 연관해서 다른 Chunk 를 찾을 때는 기존 Chunk 와 얼마의 연관도가 있는지 파악해보는거임. 이런건 Embedding 을 이용해서도 계산해나갈 수 있고, LLM 을 통해서도 계산해나갈 수 있음.

 

결국 LLM 이 답변을 더 잘하게 만드는 데에는 뛰어난 사람들이 어떻게 논리를 구성하는지와 많은 연관이 있는 것 같음.

 

Embedding Lookup 을 더 잘하도록 하기 위해서 여러가지 질문을 변형하는 방법도 있음:

• Decompose:
  • 질문을 쪼개는 것
• Step-back prompting:
  • 질문을 상위 수준에서 생각해보는 것.

 

여러 데이터 소스에서 가져온 데이터들도 ReRank 하는 것도 좋은 방법이 될 수 있음:

• 중복된 내용을 없애면서도 연관된 내용을 잘 가져오는 게 중요할듯.
• ReRank 를 위한 Model 들이나 API 들도 제공한다고 함. 아니면 LLM 에게 순위를 매겨달라고 한다던지

 

Prompt Engineering:

• 최종적인 원하는 답변을 얻기 위해서 한번에 LLM 에게 답변을 요구하기 보다는 여러 Chaining 을 써서 조합해서 쓰는게 나을 수 있음. 한 번에 하나의 일만 처리하도록 LLM 에게 맡기는게 좋으니까.
• 프롬포트는 데이터와 같이 버저닝을 잘 해두는게 중요

 

Guard Rails:

• LLM 의 테스크 작업을 평가하기 위해서 사용함.
• Regulation 을 위반하는지 확인 (포맷팅 같은 문제)
• LLM 이 올바른 답변을 안줄 경우 주로 말하는 패턴을 파악해서 확인하는 것도 방법
• Fact Checking 을 위한 LLM 을 돌리는 것도 방법

 

이외 기술적인 Challenge

• Rate Limit 문제 -> Multi key Rotation 사용 or Queueing 사용
• 불규칙한 LLM API 응답 -> Timeout, Retry 를 통해 해결
• 불필요한 LLM 호출 비용 줄이기 -> Caching 으로 해결
• Prompt & RAG 개발을 보다 효율적으로 -> LLMOps 도입

 

RAG Evaluation:

• 실제로 배포를 하기 까지 과정 중 Evaluation 이 제일 많이 차지하고 있다고 한다.
  • 이를 자동화 하기까지 많은 노력들이 있을 것 같긴하다.
  • 자동화해보고 PASS 할 지, FAIL 할 지 결정하는 컴포넌트 들이 있어야 할 듯.
• Evaluation 을 하는데는 주요한 Metric 들이 있다고 함: (이런 Metric 들도 Task 에 맞게 잘 선별하는게 중요할 듯)
  • Faithfulness: 요청에 얼마나 사실적으로 잘 전달하는지
  • Answer Relevancy: 주요한 요청에 얼마나 관련이 있는지
  • Context Precision: 응답에 근거되는 데이터 들을 관련도 높은 순서대로 잘 가져왔는지
  • Context Recall: 답안지와 얼마나 유사하게 가져왔는지
• 여러가지 지표들의 우위가 뒤섞이는 경우도 존재할 듯. 보다 완벽한 상위 호환이 아니라면.
• Evaluation 은 Semantic 한 기준들과 Syntax 한 기준들로 나눠서 보고 있다고 함:
  • Semantic 은 언어의 측면에서 보는 거고
  • Syntax 는 사용하면 안되는 단어나, 무조건 있어야 하는 단어나, 이런 것들을 말함.

 

LLMOps:

• 모델을 비교해서 배포해서 나갈 수 있도록 하면 되지 않을까? Champion 과 Challenger 그리고 이들 중 누가 더 뛰어난지 평가해줄 수 있는 Judge.
  • Judge 의 능력도 달라질 수 있으므로, 심판의 능력도 테스트 할 수 있도록 하면 더 좋을듯
• 모델을 튜닝 하느냐 안하느냐에 따라서도 LLMOps 의 차이가 있음. 추가적인 Fine-tuning 이나 RLHF 가 있다라도 한다면 모델의 학습 과정이 LLMOps 에 포함되는거고, 그런 것들이 없이 LLM 을 쓴다면 프롬포트가 변경되거나, RAG 방식이 바뀌거나, LLM 이 최종적인 응답을 내보내기 전에 Chaining 하는 방법들이 변경되는 걸로 인해 모델의 Task 처리 성능을 비교하는 작업을 할거임. 그리고 이 결과로 인해 배포가 결정되겠고.

 

LLM App 을 만드는데 가장 효과적인 개발 단계:

• Prompt Engineering -> RAG Pipeline -> Evaluation -> 배포 이 주기라고 함.
• 이 과정에서 도메인 전문가와 협업해서 커뮤니케이션 하는게 가장 큰 비용이라고 함.
• 개발자가 도메인 전문가가 되야한다고 생각한다.