25년 4월 4주차 그래프 오마카세
- 안녕하세요, 독자 여러분들. 날씨가 많이 풀려서 이제야 봄이 온 것 같은 기분이 듭니다. 날씨가 풀릴 때에 맞추어 어느덧 4월 마지막 주차 오마카세를 발행하게 되었는데요.
- 이번주는 3곳의 유명한 기업 사이트에서 공개한 그래프 관련한 블로그를 공유드리고, 내용을 가볍게 정리해서 전달해드릴까 합니다. 관심 있으신 독자 여러분들께서 직접 사이트에 방문하셔서 읽어보시고 많은 인사이트 얻어가셨으면 좋겠습니다.
Tracing the thoughts of a large language model
Blog link : https://www.anthropic.com/research/tracing-thoughts-language-model
Youtube : https://www.youtube.com/watch?v=Bj9BD2D3DzA
- 그래프 학습 관점에서 LLM의 핵심을 살펴보는 것에 대한 관심이 늘고 있는 것 다들 잘 아실 겁니다. GraphRAG 기술이 그 중 하나의 훌륭한 기술이라고 생각이 되는데요.
- 유명한 앤트로픽 AI에서 그래프가 강세를 보이는 LLM에 대한 내용을 담은 글을 오피셜 블로그에 실어 공개하고 있습니다. 최근 앤트로픽에서 생물학 관련한 LLM(Claude, 클로드) 기반 두 편의 논문과 더불어 방대한 연구 과정을 공개하고, 풍부한 시각 자료를 바탕으로 많은 연구자들의 관심을 받고 있는데, 해당 글이 많은 참고가 될 것 같습니다.
- 해당 블로그에서 공유하는 앤트로픽 연구자들의 'LLM 모델의 해석 가능성, Interpretability of LLM'의 인사이트 및 관찰한 내용들을 이해하는 방식에 발맞추어 투명성 보장에 관련한 기저 툴을 제공할 잠재성을 갖춘 연구 방향성을 시사합니다. 자세한 내용은 위 블로그 링크를 통해 확인해보시기 바랍니다.
Graph Transformers in Kumo.ai
Blog link :https://kumo.ai/research/graph-transformers-in-kumo/
- 워낙 유명해서 모두들 잘 알고 계실 것이라 생각되는 쿠모 ai에서 관계형 딥러닝 작업에 대규모 그래프 트랜스포머 모델을 사용하는 것에 대한 훌륭한 블로그 게시글을 게시하여 위 링크를 통해 공개하고 있습니다.
- 가장 인사이트가 높은 부분은 위치 인코딩(PE)에 대한 부분이라고 생각이 드는데요. 대규모 그래프 사이즈는 워낙 크기 때문에 (e.g. RelBench에서 1,000만개 이상의 노드가 존재) Global PE 보다는 Hop-encoding 또는 Rel PE 등과 같은 로컬한 위치 인코딩 방식을 사용하는 것이 선호됩니다. Temporal PE가 필요한 경우 (e.g. 전자상거래, 전력 신호 예측 등)도 물론 존재하기 때문에 Task에 맞는 적절한 PE 선택이 상당히 중요할 것입니다.
- 다음 Kumo에서 공개한 그래프 트랜스포머는 다음 사실을 기반으로 적응 가능한 위치 인코딩을 바탕으로 여러 PE 방식을 통합하여 관계적 구조를 효과적으로 포착할 수 있으며, GNN의 Inductive bias를 보존하는 훌륭한 성능을 보장할 수 있다고 언급합니다. 정말 그러한지는 위의 블로그를 자세히 읽어보시고 해당 모델을 무료로 제공하는 것으로 보이니 활용해보시면 좋을 것 같습니다.
The evolution of graph learning
Blog link : https://research.google/blog/the-evolution-of-graph-learning/
- 이름 그대로 입니다. 초기 그래프 학습부터 최신 기법까지 훌륭하게, 그리고 깔끔하게 정리한 '그래프 학습의 이정표 : 2013 이전 ~ 현재' 내용을 리뷰 게시글로서 가볍게 제공하고 있습니다.
- GNN 초기 공부할 때 반드시 짚고 넘어가야 할 Deepwalk부터 GCN, MPNN 등의 내용들을 쉽고 자세하게 기록해주고 있습니다. 기본이 탄탄해야 그래프 표현 방법 및 기술의 흐름을 정확하게 파악하고 응용 사례에 적절하게 적용할 수 있다고 생각하기 때문에, 리와인드 식으로 위 블로그 글을 정독해보시면 좋을 것 같습니다.
[Contact Info]
Gmail: jhbae1184@akane.waseda.jp
Twitter (X): @jhbae1184
안녕하세요 정이태입니다. 작년엔 에반젤리스트와 유사하게 그래프 개념을 전파하는 활동을 했다면, 올해엔 직접 다양한 분들에게 그래프를 적용하고 체험할 수 있는 활동을 하게 되었어요. 6주간 내용들을 오마카세를 통해 한 번 전달해보려고 합니다. 오늘은 멘토링을 시작한 이유, 아키텍쳐 빌딩 그리고 이번 주차에 진행한 내역 3가지를 공유드려볼까해요.
1.멘토링 시작한 이유
다양한 세미나를 돌아다니며, 현업에서 GraphRAG를 활용하고자 하는데 몇몇 제한 사항 혹은 낯설기 때문에 어렵다 라고 생각하시는 분들의 의견들을 많이 듣고 있습니다. 이 어려움과 낯설음을 멘토링으로 단번에 해소하긴 어렵겠지만 진입장벽을 낮춰줄 수 있는 좋은 기회가 될 거 같다라고 생각이 되었어요.
또한, 취업 준비생분들 그리고 학생 분들에게 이 경험에서 얻은 GraphRAG가 취업 시장에서 자신만의 강력한 무기가 되었으면 하는 바램 이 두 가지 바램을 위해 멘토링을 시작하게 되었습니다.
2.아키텍쳐 빌딩
세 가지 원칙을 두고 다음 아키텍쳐를 설계했어요.
1.최대한 간단하게
2. 코딩에 대한 두려움 없이 쉽게 실행할 수 있게
3. 간편함과 코딩 최소함이 되었음에도 불구하고 성능이 보장될 수 있게
위 세가지 원칙이 어떻게 아키텍쳐에 내재되어있는지 이야기를 해볼게요.
Stage1 는 지식그래프를 만드는데 어려움을 겪는 분들을 위한 스테이지입니다.
청킹된 데이터로부터 Entity를 도출하고, 이를 연결하는 단계에 치중합니다. 특히, GraphRAG를 고민하시는 분들이 많이 겪고들 계실 고민인데요. Entity 를 도출하기 위해 NER 모델 파인튜닝을 하면서까지 해야할지 고민들이 많아요. 저는 이 단계에서 굳이 그럴 필요는 없다 라고 생각합니다.
그 이유로는 Prompt 와 light-weight NER 모델들이 많이 있기 때문이에요. trial and error 가 중요한 스테이지다보니, 빠르게 실패하고 개선하는데 초점을 두려고합니다. 즉, 적극적으로 활용할 수 있게 진입장벽이 낮고 , 가벼운 모델들이 필요하다는거죠. 때문에 GLiNER과 Prompt engineering 으로 이를 활용해보려고 합니다.
Stage2 는 Stage1의 결과와 Stage3의 결과를 종합적으로 가져와 동작하는 스테이지입니다.
즉, 만들어진 지식그래프와 설계한 유저 시나리오 검증을 위한 엔진 역할을 하고 있습니다. 엔진 역할이라면, 성능이 중요하겠죠? 성능 보장을 위해 GDBMS 와 LightRAG를 활용합니다. 우선, GraphRAG의 성능은 시작인 Retreival 과 연관성이 큽니다. 여러 GDBMS들이 있지만, Neo4j를 선택한 이유는 다음 두가지입니다.
1.OLTP 에 특화된 데이터 자료구조 (index-free adjacecny) , 포인터 기반으로 조회를 하기에 변동성이 클거라 생각되는 Stage3의 데이터셋인 Supply chain 그리고 외부 변인(뉴스 등) 데이터셋들의 CRUD 동작에 강건성이 보장됩니다.
2.GenAI 생태계와 조화, 압도적으로 Neo4j usecase가 많고, langchain&llamaindex 와 integration 또한 많이 보장되어 있어서, 새로운 트렌드가 발생한다고 하면 Neo4j 솔루션 엔지니어들이 신속하게 구현합니다. 때문에, 저희가 해당 모델이 마음에 든다면, 보다 쉽게 이해하고 잘 가져다 쓸 수 있는거죠. LightRAG를 택한 이유는 다음 그림 하나로 설명이 가능할 거 같네요.
저렴하며, 성능이 보장된다. M사의 GraphRAG 대비 Token 량과 API call이 압도적으로 적습니다. Retrieval Phase 부터, 병목이 걸릴 확률이 낮으며 가격 또한 상대적으로 저렴하다는 거죠. 그러면서 성능도 보장되니 멘토링 이후에, 기업에 이 프레임워크를 가져가서 Enterprise 향으로 구현하기에 고려할 요소들을 줄일 수 있다는게 매력적으로 다가왔습니다. 저희는 '진짜' 사용할 수 있는 GraphRAG를 만들어야 하니깐요.
Retrieval Phase 를 유독 강조하는 이유는 다음과 같습니다. Pilot 에서는 동작하는것만 본다하면, Production 에서는 다음과 같은 요소들을 고려해야합니다. Pilot <-> Production 중 1.10K document, 2.1,000s of users, 3.Multiple use cases 를 이야기 해볼게요.
우선 1.10K document 입니다. 문서당 100페이지이고, 이를 parser 해서 Json으로 변환된 결과를 예상해볼게요. 100개 문서 , 10,000 페이지 2GB , 10,000개 문서 1,000,000 페이지 200GB 로 각각의 용량의 결과를 저희는 얻게 될 것이고, 이에 따라 비용이 얼마나 들지 한 번 확인해볼까요?
임베딩 비용은 100배 선형적으로 증가했지만, Vector Database cost 는 10배 증가했습니다. 여기에서 엿볼수 있는 것은 확장성 과 소요비용이 중요하다 입니다. 성능과 비용 트레이드오프를 고민해봐야합니다.
아무리 성능이 좋다한들, 비용이 많이 발생한다고 하면 기업입장에서는 이 비용대비 마진을 고려하는게 당연한데, 이 마진이 나오지 않은 경우가 문제가 됩니다. 그럼 이어지는 내용인 3-Multiple use-case 와 연계되는거죠. 이 RAG pipeline 이 최대한 많은 고객에게 전달되어 가치를 창출해야 비용에 대한 당위성이 생기고 실제 Pipeline 접목까지 이어지는거죠.
2.1,000S of users 입니다.
Pilot 구현은 최대 10명 안팎의 사람들이 이를 입력하고 결과를 받아오는 형태로 성능이 측정됩니다. 하지만, 실제 프로덕션 레벨에서는 매초당 1,000 명의 이상 유저들이 이 파이프라인을 적용할 것이기때문에, 자연스레 QPS문제로 이어지게 됩니다.
그럼 결국 어느 Vector indexing 를 선택할 건지 그리고 해당 Vector indexing 을 활용할 수 있는 하드웨어 자원 그리고 구현할 수 있는 내부 인원이 기업에 존재하는가 라는 고민으로 넘어가게 되는거죠. 위의 Table1 결과물을 보고 한 번 예상해보겠습니다. 'C' 는 Document 사이즈를 의미합니다.
즉, 위쪽의 데이터 사이즈는 Pilot 에서 볼 수 있는 사이즈, 가장 아래쪽의 데이터 사이즈는 Production에서 볼 수 있는 사이즈를 의미합니다. 이 가정하에, QPS column으로 넘어가서, 대표적인 vector indexing Flat , INV 그리고 HNSW 결과물을 확인해보면, 처참해진 결과를 확인할 수 있습니다.
평균 QPS가 200이였던 pilot 데이터사이즈에서 40,23 등 평균 50 안팎의 성능을 보입니다. Hardware 를 통해 개선할 수 있겠지만, 범주에선 벗어나는 내용이라 생각되어 다음에 기회될 때 따로 다뤄보겠습니다.
무튼 이러한 이유 때문에, 기업에선 RAG 도입을 쉽사리 하기가 꺼려지는겁니다. 뿐만아니라, parser API활용하기 위해 Document들을 splitting 하는 비용과 parser 비용까지 고려하면, 관리 포인트가 더해지는거죠.
Stage3는 Graph 기획 그리고 Evaluation Dataset 생성으로 고민이신 분들을 위해 설계한 스테이지입니다.
기획은 문제 정의가 8할을 잡는다 라는 생각을 가지고 있어요. 문제를 어디에서 가져오느냐 가 그럼 핵심일텐데, 저는 기존 Vector RAG PIPELINE으로부터 시작합니다. 즉, vector search로 찾기 어려운 부분들을 Graph search 가 보완해줌으로써 더욱 정밀한 시스템을 구축할 수 있는거죠.
그럼 VectorRAG로 찾기 어려운 부분인 연결성기반 데이터 조회를 Graph가 어떻게 하느냐? 라는 고민으로 넘어가게 됩니다. 모든 데이터를 다 연결해야하는지? 라는 근본적인 고민을요. 저는 '모든' 데이터를 연결하는게 아닌, 특정 Business 에 도움이 될 '특정' 연결부터 시작하는걸 추천드립니다.
더나아가, '특정' 연결에 특화된 평가 데이터셋이 필요할텐데, 당초 기획한 내역들과 이 평가 데이터셋의 상관성이 중요할텐데, 이를 어떻게 매칭할지에 대해 다뤄보려고합니다.
팀들간 협업이 중요할텐데, 이 협업 도구를 Opik Cloud - GraphRAG CI/CD , Google sheet - Ontology & evaluation dataset , FastAPI - Model query 3가지를 활용합니다. 보시다시피, 최대한 코딩을 자제하고 GUI 를 지향하게끔 구성했습니다. 일단 실행하는게 중요하니깐요.
3.이번 주차에 진행한 내역
3.1. pipeline 설명
지난 KCC2024 튜토리얼에서 진행한 내용을 바탕으로 이야기 했습니다. RAG 의 통상적인 파이프라인에 속해있는 5가지 요소들인 Query construction , Query Translation , Routing , Indexing , Retrieval 그리고 Generation 들을 설명했습니다.
그 중 Retrieval 에 속해있는 스테이지에서 어떤 문제가 현실적으로 발생할지를 한 번 살펴보았구요.
이 문제들은 결국 단일 (Vector) RAG 파이프라인에서 발생한다라는 가정하에, GraphRAG가 어떤 식으로 보완할 수 있을지에 대한 내용을 이야기했네요.
이번 정보과학회에도 Tutorial을 신청하긴 했는데, 선정이 될지는 모르겠네요. 만약 선정이 된다면 GUG 분들에게 지금 진행하고 있는 내용들을 튜토리얼 세션으로 전달드릴 수 있을거 같네요. 그때 다시 말씀드려볼게요.
3.2. 멘티분들이 진행할 워크플로우
Team 1
- Entity 추출하고, 적재를 위해 팀이 보기 편리하게 데이터 저장하고 공유하기.
지식그래프를 만드는 역할에 초점을 둘 예정입니다. ML 관점으로는 data-centric 이라고 할 수 있겠네요. 특히, 많이들 고민하시는 Entity extraction & linking 그리고 resolution 을 어떻게 할지 그리고 어떤 domain & schema를 활용해야할지 schema.org 등 여러 레퍼런스를 활용하며 best practice 를 만들 예정입니다.
미리 사전처리해둔 Chunk들을 S3에 올려두고, 이를 GLiNER이나 Entity 관련 Prompt 를 활용해서 arrow (neo4j load tool)을 활용해서 Cypher를 만들어서 직접 적재해봅니다. 적재 이후에는 이를 google sheet에 작성해서 타 팀과 함께 공유하게 됩니다.
구글 시트의 column을 다음 10가지로 구성해서 만들어 뒀습니다.
1.Entity Method , 2.Prompt , 3.EntityLabel , 4.Entity1 , 5.Entity2 , 6.Relation , 7.Source , 8.Date , 9.Load , 10.Load Date
1과 2는 엔티티 추출 결과 보장 즉, reproduce 와 팀원들간 관리를 위한 용도, 3부터 8은 온톨로지 관리를 위한 용도 9와 10은 Team 2분들과 Team 1분들과 데이터 적재 여부를 확인하기 위한 용도 이렇게 크게 3가지 용도를 위한 column으로 구성했습니다.
Team 2
- Neo4j에 적재하고, lightRAG 활용하기
GraphRAG의 강점은 각기 다른 데이터들을 통합해서 연관성을 Retrieval 하고 LLM에게 제시하여, 복잡성이 반영된 결과물을 도출하는 것인데요. 이를 적용하기 위해 supply chain graph와 외부 변인 데이터셋(News..)를 Lexical Graph로 변환하여 Date 라는 시간을 기점으로 통합하게 됩니다.
여기에서 Lexical graph 스키마는 Document-chunk-entity 3가지 간단한 스키마로 구성되고 이때, entity 들은 Stage1 에서 완료된 결과물들에 기초하여 적재된 결과물입니다. 이렇게 만들어진, 그래프를 LightRAG 엔진의 재료로 활용하는거죠. ML의 Model-centric에 해당하는 내용이라고 할 수 있습니다.
Team3
- 기획하고, Evaluation dataset 만들기
어떤 데이터들을 통합할지 기획하고, 해당 데이터가 완성된다면 어떻게 Evaluation 할지를 주로 다뤄볼 예정입니다. 더하여, 이 내용들이 Business value까지 어떻게 연계되는지를 함께 고민하는 Stage를 가져볼까 합니다.
위의 초록색이 Stage2의 Lexcial graph에 해당하는 내용이고, 아래 빨간색이 Domain graph에 해당하는 내용입니다. 특정 외부 변인에 의해 어떤 이벤트가 펼쳐지는지를 연계했다라고 보시면 되겠습니다.
데이터셋 찾기 그리고 통합을 위한 내용.
이렇게 통합된 데이터 즉, 온톨로지를 활용해 만들어진 지식그래프를 이제 평가해야합니다. 이 평가 기준은 기존 파이프라인인 Vector RAG가 되겠구요. 평가를 위해 '연결성' 에 특화된 multi-hop 쿼리를 만들어야하는데요. 이 multi-hop 쿼리를 만들기 전, 이 쿼리를 활용할 대상이 누구인지를 생각해봐야합니다.
결국 이 활용할 대상이 Business Value 에 해당하기 때문이죠. 이 내용이 사전에 기획되어 있지 않다면, Vector RAG 보다 Graph RAG가 성능이 좋다고한들 결국 활용할 대상이 없기때문에 만들어두었지만 활용하지 못하는 안타까운 현상이 발생합니다. 이 현상들을 많이 보았기에 최대한 산업의 니즈를 반영한 Business Value customer를 가정해보려고 노력했습니다.
위 그림은 Bloomberg 에서 발표한 RAG 내용입니다. DAILY volume 부터 product 그리고 Client까지가 설명되어 있습니다. 이 그림에 착안해 SELL-SIDE 의 Research analyst를 타겟 고객으로 가정하고 GraphRAG 의 business value 를 report generation 로 선정했습니다.
앞선 내용은 위 그림에서 아이디어를 얻어 기획하게 되었습니다. 실제 Enterprise 맥락은 단순 편의를 넘어 효율 그리고 Business transformation까지 가야만 구매 의사결정까지 확률이 높아진다라는 내용에 매우 공감했기 때문이에요.
주차별 진행 커리큘럼이 궁금하실 거 같아서 가져왔습니다. 1,2 주차에는 위의 인프라를 어떻게 활용할지 핸즈온 세션으로 진행될 예정이고, 3~6주차는 멘티분들이 팀별로 해당 인프라를 활용하며 trial&error 할 예정이에요. 이때, 어떤식으로 문제를 해결하면 좋을지 옆에서 서포트하는 역할을 할 거 같습니다.
6주간 멘티분들에게 꽉꽉 채워서 전달드리려는 욕심때문인지, 일정이 다소 타이트할 수 있어서 걱정이 되긴하네요. 중간에, 진행하고 있는 내용을 피드백해주실 온톨로지 전문가도 어렵게 모시게 되었는데 좋은 결과물을 만들어 멘티분들에게 많은 도움이 되었으면 하는 바램이네요.
다음주엔 인프라를 설계하는 내용과 prototyping 결과를 한 번 살펴보겠습니다.
맛있는 그래프 인사이트가 되었을까요?
다음주에 뵙겠습니다. 감사합니다. 정₩이태 드림.
GUG 디스코드로 오시면 위 내용들에 대한 질문들을 실시간으로는 어렵겠지만, 준실시간으로 회신드릴 수 있을거 같아요. 많은 참여 부탁드립니다.
디스코드 링크 :
https://discord.gg/RcR5e5VSJW