LEC05: Compound AI Systems & the DSPy Framework w/ Omar Khattab

Compound AI System

처음 들어보는 개념이라 메모메모📝

사람과 마찬가지로 AI 또한 오류로부터 자유롭지 못한데, 단일체 AI의 경우에는 이러한 오류를 잡기 위한 디버깅이 까다롭기 때문에 통제 및 제어가 매우 어렵다고 해요. 그래서 여러 AI가 각각 특화된 구성요소 하나로서 동작하는 모듈러 시스템을 만들겠다는 의미예요. 쉽게 말해, 모든 태스크를 하나의 AI로 해결하는 대신 태스크를 세분화해서 각각 하나의 AI에게 맡기겠다는 거죠.

 

RAG(Retrieval-Augmented Generation)도 이러한 예시 중 하나예요. 어떤 질문이 들어왔을 때, 물론 요즘 LLM은 워낙 방대한 양의 데이터로 학습해서 굳이 RAG 없이도 동작할 수 있지만.. 자사의 비공개 문서들에서 정보를 찾아야 하는 경우 LLM을 통째로 fine-tuning 하는 대신 retriever에게 연관성 높은 정보를 검색해주게끔 하고, 이 정보들을 바탕으로 생성모델(generator)이 답변을 하는 두 단계로 나눈 거죠. 유사한 예시로 multi-hop retriever, compositional report generation 등을 들어줬네요.

 

이렇게 하면 투명성, 효율성, 통제가능성(controllability), 심지어는 원하는 응답의 질(quality)까지 많은 것들이 향상된다는 장점이 있어요. 사람도 업무를 분담하는 게 혼자 다 하는 것보다 나은 것처럼.. AI 팀플 뭐 그런 느낌.. 연사는 Inference-time scaling도 장점으로 들었네요. "can systematically search for better outputs"라는데 비슷한 결의 장점인 것 같음

 

DSPy

https://github.com/stanfordnlp/dspy 

공식 깃허브 사이트입니다. 여기의 설명에 따르면…

DSPy is a framework for algorithmically optimizing LM prompts and weights, especially when LMs are used one or more times within a pipeline. To use LMs to build a complex system without DSPy, you generally have to: (1) break the problem down into steps, (2) prompt your LM well until each step works well in isolation, (3) tweak the steps to work well together, (4) generate synthetic examples to tune each step, and (5) use these examples to finetune smaller LMs to cut costs. Currently, this is hard and messy: every time you change your pipeline, your LM, or your data, all prompts (or finetuning steps) may need to change.

To make this more systematic and much more powerful, DSPy does two things. First, it separates the flow of your program (modules) from the parameters (LM prompts and weights) of each step. Second, DSPy introduces new 
optimizers, which are LM-driven algorithms that can tune the prompts and/or the weights of your LM calls, given a 
metric you want to maximize.

프롬프트 엔지니어링 자체도 굉장히 번거로운, 어떻게 보면 일종의 하이퍼파라미터 튜닝이라고 볼 수 있는데요ㅜㅜ 이걸 우리가 해주지 않고, LLM이 무엇을 해야하는지 선언을 해주면(declarative), 튜닝이 알아서(?) 된다고 해요. 

자세한 설명은 이 블로그 참고: https://devocean.sk.com/blog/techBoardDetail.do?ID=166043&boardType=techBlog 

설명 너무 잘해두심,,

 

그럼에도 여전히 한계가 있어요.

• No access to log-probs or model weights; API-only 모델(o1 preview 같은..)을 최적화시키기엔 무리가 있어요. 사실 개발자들은 그냥저냥한 성능을 보여주는 모델보다 o1 preview처럼 꽤 좋은 성능을 보여주는 모델을 쓰고 싶겠죠.
• No intermediate metrics / labels: 태스크를 세분화할수록 각 태스크를 적절히 학습시킬 수 있는 groundtruth label을 구하기 어려워져요.
• Budget-Conscious: task를 쪼개면 쪼갤수록 api call이 많아질 것이고, 그러면 당연히 돈이 더 많이 들어가겠죠.

이런 것도 있겠고ㅇㅇ

 

Solution

소제목 상당히 마음에 안 들지만 아무튼,,,

연사가 위 문제점들을 해결하기 위한 방법들로 제시한 건 총 세 가지입니다:

• Bootstrap few-shot: 사실 뭔지 잘 모르겠는데.. 아래 슬라이드 참고ㅜㅜ 
• Extending OPro: Optimization through Prompting의 준말이 OPRO라고? 참나 컨벡스 최적화 방식 중 coordinate-ascent를 적용한 OPro는 비용이 많이 들어서, 프롬프트 엔지니어링을 모듈 단위로 하자는 취지인 것 같음.  
• MIPrO: Multi-prompt Instruction Proposal Optimizer ㅋㅋ 진짜 이름 하나는 왜 이렇게 열심히 짓는지ㅜㅜ 이것도 아래 슬라이드 참고! 베이지안 러닝으로 최적화를 하는군요.. 요즘 고전 머신러닝기법을 적용하는 연구들이 많이 나오는 것 같다고 하던데 진짜네

뭐 그런 내용이었습니다

성의없는 포스트 죄송,,