Notion 에서 AI 프로덕트를 개발하는 방법

Notion 의 Lead AI Engineer인 Linus Lee 의 웨비나 세션을 듣고 정리한 글입니다.

---

Notion 에서 LLM 을 Evaluation 하는 방법들:

• Research 쪽에 가까운 Evaluation 방법과, Production 제품 쪽에 가까운 Evaluation 방법이 있음. Production 쪽으로 갈수록 모델이 실제 환경에서 정말 잘 수행될 것인지를 평가할 수 있다.
• 최적의 벤치마크는 실제 사용자가 평가한 피드백이겠지만, 이건 사용할 수 없겠다. 그래서 여러 중간 단계들의 벤치마크들을 이용하는 것.
• Academic benchmarks:
  • 이 지표는 실제 제품 개발과는 그렇게 큰 관련은 없다고 함. 실제 사용자가 사용하는 데이터가 아니므로.
  • MMLU (Massive Multitask Language Understanding):
    • 다양한 학문 분야와 전문 지식을 테스트하는 종합적인 벤치마크임.
    • 57개 주제에 걸쳐 15,908개의 다지선다형 문제로 구성되어 있음.
    • 인문학, STEM, 사회과학 등 광범위한 영역을 다룸.
  • GSM8K (Grade School Math 8K):
    • 초등학교 수준의 수학 문제 해결 능력을 평가한다.
    • 8,500개의 고품질 수학 단계별 문제로 구성되어 있음.
    • LLM의 논리적 추론과 기초 수학 능력을 테스트.
  • HumanEval:
    • 프로그래밍 능력을 평가하는 벤치마크임.
    • 164개의 프로그래밍 문제로 구성되어 있음.
    • 함수 완성, 버그 수정 등 실제 코딩 작업을 테스트
• Programmatic:
  • LLM의 출력을 자동화된 방식으로 평가하는 방법임.
  • 이 방법은 인간의 주관적 판단에 의존하지 않고, 정량적이고 객관적인 평가를 하기 위한 것. 사전에 정의된 기준이나 알고리즘을 사용해서 모델의 출력을 평가함.
  • 특정 단어, 특정 구문, 특정 키워드등을 포함하는지, 출력이 올바른 언어인지 등을 확인하는 것.
• LLM-as-a-judge:
  • Programmatic 이후에 평가하는 단계.
  • 출력이 정확하고, 간결하고, 유용하고, 핵심 정보를 포함하고 있는지 등을 LLM 을 통해서 평가하는 것.
  • 이 방법은 고성능 LLM을 '판사'로 활용하여 다른 AI 모델의 응답 품질을 평가한다.
  • 인간 평가자를 대체하거나 보완하는 역할을 함.
• Human eval:
  • 노션에서는 인간 평가자들도 평가를 많이 함.
  • 인간 평가자들이 테스트 데이터 셋에 대해서 출력을 검토함.
• Continuous monitoring:
  • 제품을 출시하면서 지속적인 모니터링을 수행하는 것.

 

 

Notion 이 AI Product 를 만들 때 얻었던 가장 큰 교훈:

• Evaluation 에서 사용할 수 있는 고품질 데이터가 정말 AI 제품을 만드는데 중요하다는 것.
  • Evaluation 은 우리의 목표와 요구사항을 충족하는지에 대한 테스트임.
  • 고품질의 데이터는 사용자가 실제로 입력할 데이터들과 가까운 데이터들을 말함.
  • 그래서 초기에는 수동으로 데이터를 판단하고 수집하는 일이 필요할 수 있다. 모든 걸 LLM 에게 맡기는 자동화된 과정을 선호하는 경향이 있는데 초기에는 권장하지 않음.
  • 수동으로 입력과 출력을 엔지니어가 살펴보면 작업을 이해하고, LLM 이 왜 실패하는지, 어떻게 실패하는지에 대한 이해를 쌓을 수 있다.
• 데이터의 양보다는 품질이 중요.
• 이런 데이터들을 바탕으로 Evaluation 평가 방법을 구축하는 것도 정말 중요. 이건 AI 제품의 좋은 출력의 기준을 정의하는 것과도 많은 관련이 있음.
• 제품을 빨리 만들어보고, 이해해보고, 개선해보는 것이 정말 중요. 이 과정에서 모델이 왜 실수하는지 이해하려고 노력하는 것이 중요.
• 실제 제품을 내보내고 난 이후에는 Evaluation 에서 사용하는 평가가 중요한게 아니라 실제 사용자의 Input 으로 평가를 하는게 중요.

 

 

요약 기능을 AI 로 만들어 본다고 가정해보자: 

• 요약 기능을 AI 로 만든다고 했을 때 개발자들은 GPT-4 를 쓰거나, 파인튜닝 하거나 하면 되겠지라고 생각하는 반면에 기획자들은 이거 중요한 정보를 놓치고 있는데? 라고 생각할 수 있음. 그렇기 때문에 기능의 원하는 방향에 대해 수립해야함.
• AI 요약 기능을 평가하기 위해서 학술적으로는 여러 데이터 셋이 있음:
• 아래에 있는 것들은 모두 대규모 데이터 셋과 이들을 평가하는 지표임.
  • CNN/Daily Mail:
  • SAMSum:
  • arXiv/PubMed
• 하지만 이 모든 것들은 실제 Notion 사용자가 사용하는 데이터들이 아님. 그래서 이 평가 데이터 셋으로 성능을 좋게 만들어봤자, 노션 사용자들은 만족하지 않을 수 있다.

• 예로 연구자들은 연구 논문과 긴 문서, 그리고 대화의 요약에 관심이 있을 수 있지만 실제 노션 사용자들이 원하는 요약 기능은 회의와 보고서 그리고 팀에서 일하는 사람들의 업데이트 진행 상황에 대한 알림등이 있을 것.
• 따라서 좋은 AI 기능을 만들기 위해서는 해당 사용자들이 사용할만한 기능을 평가할 수 있는 데이터 셋과 평가 방법을 따로 만들어야한다.
• 이 점을 고려하게 된다면 누군가 Notion 페이지를 요약해달라고 할 때 개발로 바로 뛰어들지 않고 "좋은 요약이 뭔가요?" 또는 "어떤 종류의 문서를 요약해야하나요?" 라고 물어볼 수 있을 것.
• 그리고 데이터 세트를 구축해볼 수 있을 것임. 이런 데이터 세트가 엔지니어와 기획자간의 합의가 이뤄질 수 있다.

 

Notion 의 현재 AI 개발 프로세스:

• Define UseCase:
  • 사용사례를 정의하는 것으로 시작함.
  • 에시로 Q&A Application 을 기준으로 설명하자면, Notion 내부 문서에 대한 질문을 하는데 이 질문에 답변할 수 있는 내용이 Notion 내의 문서에 있다면 좋은 답변을 얻고 싶어함. 반면 문서가 없다면 모델이 할루시네이션으로 답변을 하기 보다는 답변이 존재하지 않는다고 신뢰성 있게 알려주는 걸 원함.
• Gather Inputs:
  • 다양한 Input 데이터를 수집하는 과정임.
  • Q&A Application 기준으로 사용자가 묻는 질문을 수집하는 것. 물론 이 과정에서 모든 사용자가 하는 질문을 수집하기는 어려울 수 있음.
  • 그리고 사용자는 항상 다양한 질문을 하기 떄문에 예상치 못한 질문들에 대해서도 수집해야함.
  • 이 부분이 어렵다면 먼저 프로토타입부터 만들고 나서 팀원들이 이를 사용해보면서 초기 Input 데이터를 수집해볼 수도 있음.
• Iterate in dev:
  • 이런 입력 질문들을 바탕으로 Prototype 시스템을 구축함.
  • 여기서는 일단 가장 능력있는 모델을 사용한다.
• Deploy internally:
  • 프로토타입 시스템을 내부 직원들이 사용해봄.
  • 모델이 실패하는 모든 방식을 수집하는 것.
• Collect Failure:
  • 많은 실패 사례와 좋지 않은 출력을 수집하면 이를 활용해서 개발할 수 있음.
  • 개선 방향은 프롬포트 조정, 파인튜닝, 언어 모델 파이프라인에 단계를 추가하는 것 등이 있음.
• Rollout & Monitor:
  • 출력의 품질이 괜찮다면 Rollout 하면 된다.
  • 현실 세계의 데이터 셋을 수집해서 나중에 Evaluation 프로세스로 구축하는 것도 중요함.

 

 

Collect Failure 과정을 더 자세하게 - 수집하는 방법은 다양할 수 있음:

• Conttinuous evals & logs:
  • 지속적으로 평가한 결과와 로그들을 통해서 실패 과정을 수집할 수 있음.
  • 여기에는 AI 없이 평가할 수 있는 메트릭들도 이용할 수 있음. 키워드나 출력의 구조에 기반한 평가들.
• User interviews & internal feedback:
  • 사용자 인터뷰, 외부 뿐 아니라 내부 뿐 인터뷰 피드백도 이용함.
• feedback with explanations:
  • 많은 AI 제품들은 좋아요, 싫어요와 같은 피드백 기능이 있기 때문에 이걸 바탕으로 수집할 수 있음.
  • 이 기능을 이용하는 사람들은 그렇게 많지는 않아서 크게 유용하지는 않지만 때떄로 오류 케이스를 찾아내는데 도움을 준다고 함.
• Adversarial testing:
  • Adversarial testing 은 AI 시스템의 취약점을찾고 보안을 강화하기 위한 테스트 기법임.
  • 데이터 전문가들이 제품을 사용해보고 모델을 의도적으로 실패하게끔 상황을 만들어서 테스트 하는 것.
  • 모델이 잘 수행하는 영역과 모델이 무너지기 시작하는 지점을 파악하는데 도움을 줌.

 

 

Conttinuous evals & logs 를 구축할 때는 포괄적이고 재현 가능한 로깅 시스템을 구축하는 게 정말로 중요함:

• 디버깅을 하는데 도움을 정말 많이 줌.
• 운영 환경에서 사용자가 실패한 입력이 있다면 해당 입력을 재현해서 수정할 수 있는 것.

 

 

AI 사용자 인터페이스는 크게 두 가지 종류가 있다고 생각한다고 함:

• 단순히 작업만 완료하면 되는 경우:
  • 입력을 주었을 때 어떻게 완료했는지는 중요하지 않는 경우임.
  • 자율주행으로 치면 목적지를 찍어두기만 하면 나는 자도 되는 경우.
• 사람의 참여를 끌어들이는 경우:
  • 이 경우는 시험 준비를 하는 앱을 예시로 들 수 있음.
  • 계속해서 사용자가 중간 과정에 들어와서 AI 의 답변을 보고 연습할 수 있도록 하는 것.