Perplexity.ai CEO 인터뷰
Lex Fridman 팟캐스트
Lex Fridman 팟캐스트에 AI 검색서비스를 만들고 있는 Perplexity CEO인 Aravind Srinivas가 인터뷰한 내용이 올라왔습니다. 전체적인 내용도 인사이트가 흘러넘쳤는데요, 특히 1:56:57~2:14:57 구간에서는 기술적인 디테일을 꽤 자세히 공개했기에, 유사한 서비스를 고려하는 사람들에게 도움이 될 것 같아서 해당 내용을 옮겨봅니다.
https://youtu.be/e-gwvmhyU7A?si=EkQ_VC0_QoGT5ITS&t=6990
1. 소스에 충실할 것.
- RAG 자체는 단순한 기술일 뿐임. 오히려, RAG를 사용한다는 사실보다 더 중요한 건, "retrieve해온 정보 이외의 것들은 아무것도 말하지 않는다는 원칙"이다. 만약 retrieve해온 정보가 충분하지 않다면, 정보가 충분치 않다고 답변하면 되는 것. (* 기존 RAG는 LLM의 답변을 보충하기 위해 extra context를 추가하는 방식으로 사용되어왔으나, Perplexity에서는 retrieve해온 사람이 작성한 문서(일종의 truth)를 기반으로 최대한 충실하게 답변하도록 하고, 출처를 cite하는 방식으로 동작)
2. 그럼에도 불구하고, Hallucination이 여러가지 이유로 발생할 수 있다.
- retrieve해온 정보는 충분했으나, 그냥 LLM모델이 충분히 smart하지 않아서 쿼리를 충분히 이해하지 못한 경우라던가,
- retrieve해온 정보 품질에 이슈가 있는 경우: 인덱스가 틀렸거나, 아웃데이트되었거나, 충분히 디테일하지 않거나, 여러 소스에서 정보를 가져오다보면 내용이 상충되는 경우라던가,
- retrieve해온 정보 양이 지나치게 디테일한 경우: 모델이 어떤 정보가 가장 중요한지 명확하게 구분하지 못해서 부정확한 답변 작성 등.
3. 검색 (인덱싱, 랭킹)을 잘 하기 위한 기술 요소들
- [ raw data 확보 ] Crawler (Fetching contents from each URL through Headless rendering)
. 어떤 도메인을 어떤 뎁스까지 크롤링할 것인가 결정
. 어떤 방식으로 크롤링할 것인가 (e.g. headless rendering, javascript rendering *javascript 동작 방식에 대해서 파악하는 것이 쉽지 않지만, 퍼블리셔에 따라서 javascript동작방식에 대해서 명기함으로써 랭킹에 유리해지기를 기대하는 사례도 있음.)
. robots.txt에 대한 준수
. crawling 주기 (recrawl을 얼마나 자주할 것인가, 어떤 새로운 페이지들을 큐에 추가할 것인가)
- [ 인덱싱 ] Reprocess 및 Postprocess (crawling해온 모든 raw data를 machine이 소화할 수 있는 형식으로 가공하여 ranking에 반영하는 절차)
. pure한 vector embedding인 것은 아니다. (BERT가 모든 raw data를 거대한 vector space로 밀어넣는다던가 하는 것은 아님) <-- 왜냐하면, 웹페이지에 존재하는 모든 정보를 하나의 벡터스페이스로 꾸겨넣는 것은 매우매우 어려운 일이기 때문. (벡터임베딩은 텍스트에 대해서 마법처럼 동작하지 않는다. 쿼리에 대해서 relevant한 답변을 찾아내는 것은 매우 어렵다. 개인에 대한 쿼리인가 / 사건에 대한 쿼리인가 / 쿼리에 담긴 깊은 의미에 대한 쿼리인가와 같은 다양한 목적이 있기 때문에, 벡터임베딩이 캡처해야하는 요소를 정의하기 매우 어려움.)
- [ 랭킹 ] 위에 언급된 쿼리에 “알맞게” 인덱싱된 문서 중에 relevant document를 가져와서, (수십억 문서 중에) approximate algorithm을 통해 top-K를 선정
. (질문) 모든 페이지를 벡터DB에 넣는 것은 매우 어려워보이는데 (답변) 전체를 모두 다 벡터DB에 넣을 필요 없음. 다른 자료구조를 사용해도 되고, 전통적인 IR에서 사용되는 알고리즘을 사용할 수 있음. 예를 들면, TF-IDF보다 더 잘 동작하는 “BM25"를 사용할 수 있다. (TF-IDF는 지금도 잘 동작하지만, BM25가 대부분의 Retrieval Benchmark에서 대부분의 Embedding의 성능을 상회함. 참고로 OpenAI에서 임베딩을 발표했을 때, BM25보다 잘 동작하지 않는다는 논란이 있기도 했었음. OpenAI가 잘 못했다기보다는 BM25가 워낙 뛰어나다고 볼 수 있음.) 따라서, 벡터 임베딩이 검색의 모든 문제를 해결한다고 볼 수 없고, 전통적인 term-based retrieval 과 N-gram-based retrieval이 필요함.
. Semantic 이외에도 Hybrid 접근이 필요함 : PageRank와 유사한 시그널, Domain Authority, Recency 등. 이것들을 검색 카테고리에 따라서 다르게 적용해야하기 때문에 검색이 어려운 것.
- [ 고객 질의 단계 ] 고객이 헛소리에 가까운 질문을 할 수도 있는데, 이 단계에서 LLM이 주로 역할을 하게 됨.
. 구글 검색의 경우에는 10 blue links라고 부르지만 3~4번째 안에 정답이 없으면 고객이 짜증낼 것. 그러나, LLM의 경우에는 Needle in the haystack이 가능하기 때문에, 10번째 있는 답변이 첫번째 답변보다 더 좋은 답변인지 판단 가능. 이와 같은 llm의 유연함이 존재하기 때문에 리소스를 어디에 집중해야할지 재검토할 수 있음. (*물론, computer science에서는 모든 일은 다 trade-off임. 모델을 더 좋게 만들 것인가, retrieval을 더 좋게 만들 것인가)
4. Perplexity의 Sonar 모델, 그럼에도 Model-agnostic하게 만들기.
- Sonar모델 : Llama3 기반으로 요약, 출처표기, 맥락유지, 컨텍스트길이 확대와 같은 특정 스킬에 뛰어나도록 Perplexity에서 post-training을 시켰음. (Sonar Large 32K)
- Claude나 GPT-4o보다 inferencing속도가 더 빠름. GPT-4보다 잘 동작하지 않는 경우도 있지만, RLHF와 같은 Post-training을 통해서 더 좋게 만들고자 함.
- (질문) 장기적으로 Sonar가 주된 model이 되기를 바라는가 (답변) 상관없다. 고객은 좋은 답변이 나오는 것만을 신경쓸 뿐, 우리가 어떤 모델을 쓰는지 신경쓰지 않기 때문. 물론 지속적으로 Sonar 모델을 좋게 만드는 노력을 기울일 것이지만, Perplexity에 고객이 원하는 것이 좋은 답변이기 때문에, "Model-agnostic"하게 만들고자 함. User-centric!
5. Latency가 매우 낮고, 계속 낮아지게 하는 동력에 관해서.
- 구글 Jeff Dean의 The Tail at Scale 페이퍼에 따르면, 한두개의 쿼리의 성공으로 품질을 측정하면 안되고, P90, P99와 같이 Latency를 Percentile로 관리하는 것이 중요하다는 Tail Latency관리 사상으로부터 영감을 받음.
- LLM에서는 Throughput과 TTFT (Time To First Token)라는 지표로 관리 중. (OpenAI와 Claude를 사용할 경우에는 dependency가 있긴 하지만 그들도 고객을 위해 latency를 낮추는 노력을 하고 있고, Perplexity의 Llama 기반 모델의 경우에는 투자자인 Nvidia와 TensorRT-LLM프레임워크상에서 커널 레벨에서 최적화하는 노력을 기울이고 있음.
