Patterns for Building LLM-based Systems
Patterns for Building LLM-based Systems이라는 긴 아티클을 읽고 중요하다고 생각되는 부분만 뽑아서 정리한 내용
Aug 05, 2023
시작 문장 : For example, self-driving: It’s easy to demo a car self-driving around a block, but making it into a product takes a decade.
완전 맞는말. 자율주행 가능할 정도로 기술 발전했다 = 웨이모의 설립일자(2009년)으로 약 14년 전인데, 여전히 실제로 상용화에 성공하기위해서 많은 회사가 노력을 하고있고 몇몇 회사는 실패해서 사라지기도 했다,,
7개의 키 패턴들. 크게 2개로 나뉜다 1. 성능 개선 vs cost/risk 줄이기 2. closer to the data vs closer to the user.
- Evals: To measure performance
- RAG: To add recent, external knowledge
- Fine-tuning: To get better at specific tasks
- Caching: To reduce latency & cost
- Guardrails: To ensure output quality
- Defensive UX: To anticipate & manage errors gracefully
- Collect user feedback: To build our data flywheel
RAG이 중요한 이유 : 사람에게 더 도움이 되는 답변을 제시해줄 수 있고(근거 확보, hallucination 방지 등), 파인튜닝을 하지 않고 더 쉽고 싸게 데이터를 활용하는 방법이 된다.
RAG는 LLM의 단점을 보완하기 위한 방법. 잘 아는 부분이니 많은 부분들을 스킵했습니다
LLM을 쓰는 회사들의 88%가 retrieval이 우리에게 중요한 컴포넌트다라고 응답
텍스트끼리의 임베딩이 주되긴하지만 이미지, 유저의 활동 내역(clicks, likes), graph 등 모든 데이터는 mapping이 가능하고, retrieval을 위해 활용가능하다.(뇌파도 임베딩 가능)
Pre-training 과정에서도 매번 현재 학습할 텍스트에 대해 Retrieval로 텍스트를 가져온 다음 학습해서 성능을 개선했다(RETRO) - 논문을 읽진 않고 설명만 봐서 정확한진 모르겠습니다..
인터넷 검색 → 리트리벌 → 답변에 활용
쿼리와 document에 다른 모델을 사용하려고 하는데 학습할/eval할 쌍이 없으면 어떡하지? → 제로샷 Dense Retrieval
질문 → 가상의 문서로 변환(LLM 사용해서) → 임베딩 후 document와 유사도 계산해서 Retrieval!(저번에 시도한 방법,, 잘 못해서 실패했는데 이론상 맞았네요)
항상 하이브리드 방법이 잘만 적용하면 embedding-only보다는 낫다.
traditional 검색 방법(= 키워드 매칭, 인덱싱 등)과 임베딩 베이스 검색을 합쳐서 활용 → 여기서는 BM25와 cosine similarity 두개 썼더니 더 나았다고 말함(항상 다른 임베딩 모델들 논문에서도 지표로 하이브리드가 낫다고 제시)
openAI의 text-embedding-ada—002(최신모델)에 대해서도 말함 근데 Nonetheless, experience and anecdotes suggest it’s not as good for retrieval.
최근데는 instruction으로 학습한 instructor model이 이 분야에서도 SOTA를 보여준다. 인스트럭션을 사용해서 task-specific한 임베딩을 수행한다. 예를 들어 QA라면 쿼리에는 query:를 붙이고, document에는 passage:를 붙여서 임베딩을 수행했을 때 둘이 가까워질 가능성이 높아진다(e5 모델이 여기에 해당함..!)
Fine tuning에 관하여
파인튜닝도 여러가지로 사용되니 좀 더 분해해보자면
- Pre-training의 확장 : 추가 corpus를 트레이닝
- Instruction 파인튜닝 : 인스트럭션과 답변으로 학습
- 특정 Task에 맞도록 파인튜닝
- RLHF
파인튜닝을 하는 이유 3가지(엄청 크리티컬하진 않은 것 같습니다)
1) 성능 향상 가능 2) 특정 태스크에 맞는 튜닝을 통해서 모델의 사이즈를 줄일 수 있음 3) 우리만의 모델로 우리 정보가 외부에 노출되는걸 방지 가능
근데 쉽진 않기 때문에 문제
InstructGPT paper에서는 인스트럭션-출력 쌍을 13000개, 리워드 모델링을 위해 33000개, RLHF를 위해 31000개를 사용(당연히 3.5, 4는 훨씬 많이 사용)
모델이 있다고 할 때 전체 모델을 fine-tuning시키는건 항상 리스크가 존재한다 → Soft prompt tuning(임베딩을 학습시켜 입력으로 사용), prefix tuning(태스크에 맞는 추가 가중치만 학습-Transformer에 적용되는), adapter(추가로학습하는 작은 외부 모듈을 추가) 등을 사용하기도 함(production 단에서는 거의 못본 것 같긴함)
LoRA와 QLoRA도 존재(이게 꽤 많이 리소스를 아껴주는 것 같습니다 추가 공부 필요)
QLoRA는 간략하게 LoRA와 비슷하면서도 파인튜닝시 16 bit model을 사용하는게 아니라 4-bit quantized model을 학습
(Fun fact: During a meetup with Tim Dettmers, he quipped that double quantization was “a bit of a silly idea but works perfectly.” Hey, if it works, it works.)
Caching
한번 답했던 질문에 대해서 저장해뒀다가 비슷한 질문 혹은 같은 질문이 들어오면 그걸 그냥 다시 보여주자. 물론 이건 프로덕션 단에서는 조심해야한다. 유저들은 같은 답변을 보고싶어하지 않을 수 있음
cache hit rate - 일정 확률에만 이전걸 보여주고, 아니면 새로 생성 등등 해야함
Defensive UX : AI를 유저에게 제공하는 서비스들이 어떻게 UX를 구성해야하는지 제공하는 마소, 구글, 애플의 가이드북이 있다.
- Microsoft’s Guidelines for Human-AI Interaction is based on a survey of 168 potential guidelines, collected from internal and external industry sources, academic literature, and public articles.
- Google’s People + AI Guidebook is rooted in data and insights drawn from Google’s product team and academic research. In contrast to Microsoft’s guidelines which are organized around the user, Google organizes its guidelines into concepts that a developer needs to keep in mind.
- Apple’s Human Interface Guidelines for Machine Learning differs from the bottom-up approach of academic literature and user studies.
마소는 AI 사용자들에게 전하는 내용, 구글은 AI를 활용하여 서비스를 제공하는 개발자, 제작자들에게 전하는 내용, 애플은 주로 디자인에 관한 내용이 담겨있음(회사의 성격이 드러나는..)
항상 인공지능은 완벽하진 않다는걸 유저에게 인지시켜야 한다 등의 내용이 적혀있네요
Collect user feedback : 항상 유저의 피드백 데이터를 모아둬야한다. → 모델 향상에 기여. 의도적으로 피드백을 유도해야함.
explicit feedback뿐만 아니라 implicit 피드백도( = 이미지 생성해놓고 저장안하고 나가면 negative)
Share article
Subscribe to our newsletter