52g GenAI conference
52g, GenAI conference GraphRAG product level 을 위해 고려해야할 요소들. 그리고 GenAI 트렌드
Sep 28, 2024
얼마 전 작성했던 컬리 세미나 포스팅 기억하실까요? 열심히 지식을 전달하며, 에너지 또한 전달을 했었는데요. 덕분에 탈진? 비스무리하게 왔습니다. 세미나를 끝내고나서, 그 다음 일정인 GenAI 행사에 '잘 참여하고 배울 수 있을지' 걱정이 많았어요.
하지만, 휴대폰에 저장해놓은 행사 구성을 보고 다시금 힘을내 잘 도착해서, 행사 네트워킹 파티인 22시까지 즐기고 왔네요! (힘이 많이들고, 어려운 것일수록 더더욱 가치있다.라는 저의 철학이 빛을 발하는 순간 😂 )
전체적으로 정말 아름다웠다라고 표현해도 좋을 정도의 행사 구성이였어요!
52g 의 리드 개발자인 Youngsu Heo GenAI intro를 시작으로 Byeongjin Jason Kang님의 GS 계열사분들의 업무 생산성 향상을 위해 플랫폼을 구성하며 얻은 lesson learned 공유! Jeffrey Kim 님의 RAG 구성시 필연적으로 마주치게될 Evaluation 문제들 그리고 해결 팁까지 (AutoRAG ,https://github.com/Marker-Inc-Korea/AutoRAG 최고 🍊 ) llamaindex 엔지니어 분의 발표 그리고 허훈님의 발표까지 하나하나 각기 다른 구성이라 생각할 수 있지만, 결국 목적은 동일 했습니다.
"어떻게하면 고객에게 GenAI의 가치를 제공할 수 있을까?" 라는 목적요.
모든 콘텐츠들 하나하나 모두 주옥같지만, 특히나 저에게 와닿았던 사진 한 장과 Key Takeaways 를 정리해보자면 다음과 같아요.
🍓 인상 깊었던 GraphRAG
허영수님께서 공유해주신 자료입니다. 최근 샌프란시스코에서 열린 AI conference 2024 에 참여하셔서 트렌드 2가지를 전달해주셨는데요. 1. GraphRAG , 2.Multi-agent 였습니다.
사실 트렌드에 GraphRAG가 있을줄은 몰랐어요. 국내에서도 타 RAG 계열 대비 그렇게 언급량도 많지않고, 주변에서 실험적으로 PoC는 진행하고 있으나 실제 적용하고 있는 분들을 찾기 어려웠기 때문이죠.
아마 근본적인 원인은 컬리 자료에서 작성해놓은 것 혹은 제가 누누이 이야기했던 그래프 데이터를 활용한 기존 데이터 통합 즉, 그래프 모델링 및 기획의 어려움 때문이지 않을까 생각은 하고 있어요.
첨부한 사진 1시방향에서 볼 수 있듯이 kuzudb , Neo4j 에서 참여해 GraphRAG의 속성인 Vector + Structure(Graph schema) search 에 대해 설명했나보아요. 이때, Vector search 는 Vector DB 뿐만아니라, 기존 DB에서 Vector indexing & searching 기능을 추가해놓았기 때문에 접근성이 쉬워졌어요.
하지만, Structure 는 쉽지않아요. 위에 언급한 바와 같이 그래프 기획과 모델링이 필요하기 때문이죠. 관계가 타 산업대비 더욱 중요한 링크드인에서는 이를 위해, Datahub 를 적극적으로 활용해 조직 내 데이터들을 체계화해서 관리하고 데이터들간 관계를 그래프화해서 활용하고 있기에 지금 Graph를 잘 활용하는 기업 중 하나로 꼽히지 않을까 싶어요.
모든 기업들이 링크드인 처럼 아름다운 정보 체계가 있으면 좋으려만, 현실은 쉽지 않죠. 그래프를 위한 정보 체계 구성 및 성숙도가 높지않은 회사들이 대다수에요. 때문에, 기획 그리고 모델링 문제와 당면하게 되는거죠. 이 문제에 대해 52g 분들은 심도있는 고민을 하고계시는게 발표에서도 느껴졌고, 네트워킹 시간에 영수님과 이야기하며 은연중에 느끼게 되었어요. 결국 '그래프'를 잘 구축한다면 이 구축의 품질이 고객에게 잘 전달될거라는 믿음 즉, 고객에게 어떻게하면 가치를 '잘' 제공할 수 있을까 라는 프로의식을요.
다시 기술로 돌아와서 이야기 해볼게요. 만일 그래프 스키마를 잘 구축했다 하더라도, 이걸 어떻게 저장하고 관리할지에 대한 고민이 필요해요. GraphRAG 의 Retrieval 를 어떻게? 라는 고민을 하게 되는거죠. 언급한 Neo4j , Kuzudb 는 동일하게 그래프를 잘 저장한다 라는 철학이 있는 데이터베이스이긴하나, 저장하고 가져오는 방식이 달라요.
예를들면, Neo4j 는 그래프 데이터 저장 구조를 Double linked list로 하고 있고, 엔진 작동을 java 언어로 구성된 함수 및 프로시저로 이루어져 있기때문에 앞서 이야기한 효율적인 엔진 구동을 위한 환경 및 쿼리 설계를 java 관점에서 적용해야하기 때문이죠.
반면에, kuzudb 는 embedded database 철학을 가지고 있기에 만약 Python 을 활용한다면, 주로 table 형태로 그래프를 저장하고 관리해요. 때문에, 그래프 조회시 Join 연산이 필연적으로 발생하게되고, 이 join 연산을 효율적으로 작동되어 있긴하나 table 구성을 어떻게하고 Python 의 GIL 을 어떻게 관리하며 조회해서 가져올지가 핵심이라 할 수 있어요.
이처럼 그래프 저장 관리 철학 , 데이터량 그리고 GraphRAG 목적에 따라 어떤 Retrieval Knowledge base 를 선택할 지가 GraphRAG를 도입할 때 고민해야할 문제라고 할 수 있어요.
🍞 Key Takeaways
- Multi-agent 를 구성하는게 핵심이다. 이 Agent 설계를 위해, 위계를 어떻게 할 것이며 무슨 근거를 기준으로 판단할 지 그 근거는 데이터 기반으로 할지 혹은 프롬프트에 도메인 전문가의 expert design thinking 을 줄지를 기존 RAG 고민보다 확장해서 생각해보아야 함.
- 예전에 비해, Finetuning 비즈니스 ROI 구성이 어려워졌다. 점점 좋아진 function call , foundation model 비용을 과연 조직내에서 finetuning 만으로 더 효율적으로 줄일 수 있을까? 차라리, Multi-agent , Routing 메커니즘을 잘 설계하는게 효율적일 수 있다.
- 리더보드에서 1등한 임베딩 모델이 늘 어느 Task 에서나 1등은 아니다. 적절한 Task 에 적절한 임베딩 모델을 사용하는게 핵심이며, 이 ‘적절하다’라는 기준을 정하기 위해선 ‘평가’가 필수적이다. 이 필수적인 시스템을 잘 활용하기 위해 구현되어 있는 오픈소스 ‘AutoRAG’를 적극적으로 활용하자.
- 라우팅 개념이 중요해졌다. 답하기 쉬운 쿼리와 답하기 어려운 쿼리를 정의하여 쉬운 문제를 해결하는 LLM, 어려운 문제도 잘 해결하는 LLM을 구분해서 비용 효율화를 고려하자.
Share article
%26logoUrl%3Dhttps%253A%252F%252Finblog.ai%252Finblog_logo.png%26blogTitle%3D%2508Graphwoody&w=750&q=75){kind=logo}
%26logoUrl%3Dhttps%253A%252F%252Finblog.ai%252Finblog_logo.png%26blogTitle%3D%2508Graphwoody&w=256&q=75){kind=logo}
