테디노트님 네트워킹 파티 참여 후기

GraphRAG 부터 finetuning Evaluation framework 그리고 Agentic-RAG 까지 전문가들이 함께한 자리에서 얻은 인사이트

Dec 13, 2024

Contents

안녕하세요, 정이태입니다.

어제 테디노트님 네트워킹 행사에 영광스럽게도 LLM/RAG 전문가분들과 함께 연사로 초청받아 다녀왔습니다. 지식을 전달하러 가는 자리라 생각하고 갔는데, 오히려 너무 많은 지식들을 습득하고 와서 너무 기뻤네요. 아쉽게 참석하지 못한 분들 그리고 제가 얻은 인사이트들을 여러분에게 공유드리면 좋을 것 같아 포스팅을 작성해봅니다.

공통질문 - 사전질문 - 네트워킹 순으로 행사가 이루어졌습니다. 다른 연사분들의 공통질문 그리고 사전질문들을 들으며 생각이 많았는데요. 그 내용들을 작성해보려고 해요. 또한 네트워킹하면서 다양한 분들을 만났는데, 이 내용은 커피챗하면서 차차 또 다른 포스팅으로 전달드려볼게요.

공통질문 사전질문 배운점 끝으로

공통질문

공통 질문은 내년 이맘때쯤 어떤 게 트렌드일까 예측해보는 질문이었어요. 저는 답변으로 Many Agent Management를 위한 관리시스템(Graph Processing)을 이야기했습니다. 그 이유로는 Agentic RAG를 실제 비즈니스에 적용하려는 시도들이 곳곳에서 보이기 때문이었어요. 특히, 여행산업에서 여행지 추천부터 예약까지 올인원으로 가능한 솔루션들이 자주 보이더라고요.

이 솔루션들은 결국 agent 기술 덕분에 구현이 가능하고요. 이를 가능케 해준 것은 LangGraph, CrewAI, Swarms, Swarm, TaskFlowAI, AutoGen 등과 같은 agent orchestration 툴들이 핵심이며, 앞으로는 창의력 그리고 Agent 디자인 능력에 따라 이런 비즈니스들이 많이 발생할 테고, 기업의 규모에 구애받지 않을 것이기에 진입 장벽이 산업마다 낮춰질 것이기 때문에 자연스레 Agent들이 선형적으로 증가할 것이란 직감이 들었기 때문입니다.(https://aihustle.tools/)

AI Agent Framework Final: CrewAI vs AutoGen vs LangGraph vs AgentZero Final Results Shock [5/5] , Florenz erstling

그렇다면 이제 이를 어떻게 다룰 것인가에 대한 이야기들이 나올 텐데, 벌써부터 외국에서는 AI Agent Frameworks Benchmark(https://youtu.be/d5l-oUWuZk0?si=001Oz7YvmJr92uYm) 실험들이 많이 이루어지고 있습니다. 위 영상에서는 Cost, Development Effort, Performance(Execution Time), Usability 4가지를 기준으로 Agent framework를 평가해요. 쉽게 구현 가능하며 성능도 좋다. 참 좋은 말이지만 이 뒤에는 결국 Processing power가 필요합니다. 쉽다는 건 추상성이 높을 것이고, 유저가 최소한의 개입으로 엔지니어링을 고려한다는 것이라고 간접적으로 볼 수 있거든요.

https://github.com/langchain-ai/langgraph

그럼 결국 내부 Agent들끼리 효율적인 정보교환을 위한 소프트웨어 및 하드웨어 관점이 필요합니다. 예를 들어보자면, Agentic-RAG를 위해 LangGraph를 많이들 사용하실 텐데요. LangGraph GitHub에 들어가서 살펴보시면

LangGraph is inspired by Pregel and Apache Beam. The public interface draws inspiration from NetworkX. LangGraph is built by LangChain Inc, the creators of LangChain, but can be used without LangChain.

라는 이야기가 나옵니다. Pregel은 Google에서 개발한 Graph Processing Model이고요. 간단하게 node들끼리 어떻게 (efficient, scalable 그리고 fault-tolerant) 할지를 구현한 알고리즘입니다.

(** 참고로 제가 재직하고 있는 회사 XCENA에서는 CXL 메모리 솔루션을 활용해 이런 요소들을 어떻게 개선할지 하드웨어를 디자인하고 소프트웨어 개발하고 있는 반도체 회사입니다. 혹시나 관심 있는 분이 계시다면 저에게 따로 연락주세요!)

여기에서 node를 agent로 대입해보시면 앞으로의 Agent에서 발생할 문제들인 효율적인 정보교환, 대량의 정보교환 그리고 에러 발생 시 어떻게 해결할 것인가를 다루고 있다라고 봐도 될 것 같아요. 결국 LangGraph 진영에서는 이 graph processing 관점에 영감을 받아 agent orchestration을 개발하고 있기 때문에, 그래프를 통한 관리 시스템이 내년에는 나오지 않을까 하는 생각에서 답변을 했던 겁니다.

사전질문

개인 질문의 요지는 GraphRAG를 활용함으로써 정교한 추론이 가능하다. 하지만, 추론을 위해 Graph를 구축 및 유지하는 비용이 많이 소요된다. 이 장단점에 어떻게 생각하는지와 향후 GraphRAG에 대한 생각을 나눠보았습니다. (테디노트님 라이브에서 디테일하게 이야기드릴 예정이라, 여기에서는 조금만 다뤄볼게요.)

계층 구조 설계 문서를 RAG에 활용한다라는 기준으로 이야기보자면, 아쉽게도 Graph를 문서 RAG에 활용한다라고 하신다면 Document Parser에 종속적이기 때문에 parser 결과에서 어떻게 연관성을 추출하려는지 온톨로지 관점이 적용되어야만 비로소 GraphRAG의 장점을 얻으실 수가 있습니다.

Feng, Shangbin, et al. "Modular pluralism: Pluralistic alignment via multi-llm collaboration." arXiv preprint arXiv:2406.15951 (2024). — Feng, Shangbin, et al. "Modular pluralism: Pluralistic alignment via multi-llm collaboration." *arXiv preprint arXiv:2406.15951* (2024).

그럼 여기에서 연관성을 어떻게 추출하는지가 고민이실 텐데요. 여러 방법이 있습니다. human-in-the-loop라 이야기하고 순수 라벨링하는 방식, 알고리즘을 활용하는 방식, LLM을 활용하는 방식입니다. LLM을 활용하는 방식만 이야기해보자면, 개체명 인식기 관점을 prompt에 입력해주고 추출하는 방식과 open, closed model들을 모두 활용하며 각기 다른 관점들을 내놓은 연관성(온톨로지)을 alignment하면서 기초 온톨로지를 만드는 방식을 추천합니다.

참고하면 좋을 논문 : https://aclanthology.org/2024.emnlp-main.240.pdf

Graph Retrieval 지연시간 지연시간은 DB engineering과 text2cypher의 prompt engineering 아름다운 조화가 이루어져야만 기대하는 결과를 얻을 수 있습니다. 많이들 사용하시는 Neo4j를 예시로 들어서 간단히 이야기해볼게요. DB engineering은 Hardware memory를 잘 활용할 수 있게 CLI 상에서 neo4j-admin server memory-recommendation 커맨드를 입력하고 설정된 값들을 configuration에 입력하는 것부터 시작해서 software 관점에선 어떻게 쿼리가 실행되고 routing되는지를 이해한 상태에서 이를 프롬프트에 입력해줌으로써 지연시간 개선을 하는 데 한 발자국 다가설 수 있습니다.

https://neo4j.com/docs/operations-manual/current/tools/neo4j-admin/neo4j-admin-memrec/#_example

https://neo4j.com/docs/operations-manual/current/database-administration/routing-decisions/

향후에는 Graph Path Finding 그리고 정보량 측정이 중요해질 것이다. 지연시간과 정보량의 트레이드오프일 텐데, 데이터량이 많아지고 5-hop만 넘어가도 지연시간이 기하급수적으로 늘어날 텐데, 과연 hop 하나를 더 늘려가며 얻은 정보와 그렇지 않은 정보가 유저에게 좋은 답변을 내놓는 데 유의미한지를 판단하는 metric 설계가 중요함. 결국 이 둘을 개선할 수 있는 역량을 가진 인력들이 각광을 받지 않을까 하는 생각입니다.

이외에도 단점에 대한 이야기로는 GraphRAG 효용성을 확인하기 위한 평가시스템 구축, 평가 시스템 구축을 위해선 기존 retrieval과 graph retrieval을 비교하기 위한 query, ground truth와 같은 golden dataset이 필요할 텐데, 대다수 기업에서 이런 인프라 및 환경을 구축하고 있을 확률이 적다. 때문에, LLM prompt engineering으로 이를 해결하는 게 가장 현실적이다.

배운점

요새 자주 사용하고 있는 PEFT(Parameter-efficient Fine-tuning)가 만능은 아니다. Parameter efficient를 위해 주로 활용하는 LoRA는 미세조정 시 모델 매개변수를 Low Rank Structure로 유지한 채로 진행하기에 여기에서 Low Rank라 함은 High Rank 대비 적은 정보량임을 간접적으로 확인할 수 있는데 이에 따라 Fine-tuning 시 손실되는 정보가 어떻게 될지도 고려해야 함.

Diffusion model이 또다시 주목받는 이유. LLM의 Auto-regressive 방식에서 적합한 토큰을 내놓기 위한 행렬 관리를 위해 diffusion model의 rejection sampling을 차용할 부분이 많아 보이기 때문.

uncertainty handling, least significant weight 식별을 위한 Hessian Matrix(역행렬) 관점 이야기

하계 튜토리얼 준비하면서 LLM control theory 관련 공부를 했었어서 위 내용들에 대해 많은 공감이 되었네요. 그리고 석사시절에 공부했던 딥러닝 기초가 공감을 하는 데 빛을 발휘하지 않았을까 싶습니다. 어제 집으로 가면서 생각하길 역시 기초가 너무나도 중요하구나 라는 것을 새삼 다시 깨닫게 되었네요.

에이전트 수가 대폭 증가됨에 따라 Query flow도 많아질 테고 자연스레 latency가 증가한다. 이 latency가 결국 유저의 기대감과 비례할 텐데(시간이 오래 걸릴수록 기대감도 높아짐), 원하는 결과가 나오지 않을 경우 실망이 커질 확률이 높음. 이를 UI/UX 관점에서 고려해야 한다.

끝으로

Graph 그리고 GraphRAG를 하고 있는 관점에서 이 fine-tuning, RAG evaluation, Agentic RAG, Modular RAG까지 전문가들 입장에서 이야기를 듣다 보니, 정말 많은 배움이 있던 자리였네요. 이런 자리를 마련해주신 패스트캠퍼스 관계자분들, 테디노트분들 그리고 참석해주신 모든 분들에게 감사드립니다.

끝으로, 위에 미처 다 작성하지 못한 내용들이 있는데, 이 내용들은 테디노트님 라이브에서 여러분들에게 공유드리겠습니다. 무려 3~4시간 정도 진행된다고 하니, 아마 원 없이 전달드릴 수 있지 않을까 하는 생각입니다. 그럼 오늘 하루도 좋은 일만 가득하시길 기원드립니다!