AISummit Seoul 2024에서 "기업 폐쇄망에서의 Private LLM 기반 Agentic RAG 구축"이라는 내용으로 발표한 이후로 오늘 AISummit Seoul 2025 전시장에 "기업 폐쇄망에서의 보험 중개 지원 Agentic RAG" 를 선보이게 되었다. 올해 전시는 폐쇄망에서 Agentic RAG 를 실증적으로 보험 중개 상담 지원 분야에 적용해 본 전시였고 시행착오를 통해 상용화에 적용할 수 있는 기반 프레임워크를 구현할 수 있었던 소중한 경험이었다고 생각한다. 구현하면서 몸소 배웠던 몇가지 점들을 공유한다.
<그림 1. 전문보험중개지원 Agentic RAG 데모>
폐쇄망의 Agentic RAG
기업 폐쇄망에서 라는 문구에서 알 수 있는 바와 같이, 보안을 위해 On-premise 나 self-hosted 의 환경에서 기업내부 지식기반을 중심으로 Open Weight LLM 으로 챗GPT 가 제공하는 것과 같은 기능을 RAG 기술 기반으로 적용하는 것을 뜻한다.
즉 OpenAI와 같은 외부 API 를 사용하지 않고, 모델, 워크플로우 프레임워트, 벡터 데이터베이스, agent 관리, agentic 메모리 관리, 가드레일 및 평가 등을 오픈소스로 구현하는 것을 뜻한다.
기술 흐름과 방향성
2025년은 하루가 멀다하고 쏟아지는 LLM 들과 agent 관련 내용이었다. 특히 딥시크 모멘트 이후 Open Weight LLM 이 챗GPT 에 버금가는 성능으로 진화할 수 있다는 가능성을 보여줬고 논문들로부터 시작하여 매개변수가 상대적으로 작은 LLM 으로 test-time computing 같은 post-training 으로 특정 산업분야에서 챗GPT-4o 에 준하는 성능을 보여주는 가능성이 부상하였다.
아울러 우리도 그동안 50개가 넘는 모델들을 파인튜닝해 적용해 왔지만, 작금의 LLM 발전 추이를 볼 떄, 좀 더 산업 도메인에 특화된 맞춤형 agent 플랫폼이라는 방향으로 추진해야 하지 않을까 하는 생각을 하게되었다.
폐쇄망에서 오픈소스를 통해 챗GPT Agent 같은 기능을 구현할 때 직면하는 도전
오픈소스를 통해 Agentic RAG 를 기능을 구현할 때 처음 드는 생각들을 간추려보면 대략 아래과 같지 않을까 생각한다.
1. 멀티모달 문서 parsing: 즉 문자, 표, 챠트, 이미지 등이 있는 문서들을 corpus 로 도입해서 LLM 을 통해 원하는 출력을 얻으려면 어떻게 해야 하나?
2. LLM 성능: 어느 정도의 LLM 을 채택해야 tool 선택과 호출이 의도대로 될까?
3. Agent Tool 구현: 에이전트 지원을 위한 Tool 등록, 선택 및 수행등을 관리하는 기능은 어떻게 구현할 것인가?
4. 파이프라인 오케스트레이션 프레임워크: stateful workflow 로서 파이프라인을 조율하는 오픈소스 프레임워크는 무엇을 채택할 것인가? 그리고 충분한 기능이 지원되나?
5. Smarter Prompt Parser: 다양한 LLM 의 서로 다른 프롬프트 템플리트의 형식을 포용할 수 있는 smarter & robust parser 구현은 어떻게 할까?
6. Agentic Memory: Agentic 을 사용할 때 한정된 메모리상에서 대화가 거듭될 수록 증가하는 프롬트로 인한 메모리 제약을 어떻게 해결할까?
7. Agentic Memory: 메모리의 중요성이 눈에 띄게 증가하는 추세를 감안할 때, self-improving system 혹은 continuous learning system 이라는 측면에서의 agentic memory 관리는 어떻게 구현하나?
8. Tool Binding Wrapper:OpenAI 형식의 시스템 메세지나 schema 를 간편하게 tool 에 주입할 수 있도록 오픈소스로 구축하면서 OpenAI 와의 호환성을 보장할 순 없을까?
9. 성능평가: Agentic RAG 의 성능평가는 어떻게 할 것인가?
10. 가드레일: 가드레일을 어떻게 보장할 것인가?
봉착하는 현실에서의 상황
1. 멀티모달 문서를 파싱(parsing)하는 솔루션들은 해외나 국내조차도 구독형 등의 유료 모델로 바뀌었다.
2.Agent 지원 LLM 은 지금 이 순간에도 수 없이 나오고 있다. 이제는 그 시점에서 테스트해보고 가장 좋은 걸 채택하면 된다. 예전에는 질의응답 합성데이터를 만들어서 파인튜닝하고 했는데 최신모델들은 신기할 정도로 파인튜닝을 안해도 프롬프트 조정만으로도 예전 성능을 능가한다.
3,4. 처음에는 LangGraph 같은 오픈소스 프레임워크로 어디까지 해결 할 수 있을지 궁금해할 수 있다. LangGraph 도 수익모델을 생각하니 OpenAI 를 중심으로 서서히 유료화로 진행하는것을 탓할 수는 없다.
LangChain 이 toollist 를 system/context 프롬프트에 주입하고 Open Weight Model 이 " I want to use tool X" 혹은 "Call: Tool_name" 같은 문구를 보고 실행되기를 기대하지만,
전적으로 Open Weight LLM 의 instruction 처리, tool use 사용 능력에 의존해서 일관성이 부족하다는 것을 느끼는데 오랜 시간이 걸리지 않는다.
LangChain 기반에 Open Weight LLM 를 사용한 구조화된 function call 이 갖춰서 있지 않아서 tool 을 요구하면 LangChain 이 추측하는데 있어 상당한 시행착오가 수반된다.
따라서 ChatHuggingFacePipeline 이 Open Weight LLM 에 tool 을 정의하고 등록하는 것이 필요하게된다.
5. Open Weight LLM 채택의 장점은, 그 시점의 SOTA 모델을 도입할 수 있는 장점이 있다.
Univeral Parser 로서 LLM 에 정밀한 프롬프트로 주입될 수 있도록 보장하는 Smarter Parser 가 요구된다.
6,7. Agent 사용 시 메모리 관리는 점점 그 중요성이 더해지고 있는 중요한 주제이다. 임시 메모리상에 쌓이는 내용을 단기와 장기 메모리에 적절히 저장하고 대화 문맥에 맞게 실시간 회상하는 기능이 대두된다. 논문에서 인간의 뇌의 기억저장을 본 뜬 계층형 메모리 관리로 인간의 시스템 1과 시스템 2와 같은 관리를 위해 agentic memory 시스템을 통한 계층형 메모리 관리라는 부분을 고려할 계기가 되었다.
8. LangChain 의 agent RAG 예제에서 다루어지는 create_react_agent 함수는 Open Weight LLM 에서 수행되지 않았다. 여기서 다루어지는 LangChain 의 bind_tool 이나 with_structured_output 기능을 OpenAI 사용하는 것과 같이 흉내내기위해 ChatHuggingFaceToolWrapper 와 같은 tool binding wrapper 설계를 생각해보았다.
9. 일반적인 RAG 의 기본적인 평가도구는 Ragas, DeepEval, TruLens, LangSmith 등이 거론 되지만, 아직 Agent 관련 공인된 Leaderboard 를 정립하려고 모색하는 단계여서 추이를 지켜보는 것이 낳을 것 같다.
10. 가드레일을 어느 정도로 갖추어 하는지가 상용화 요건에따라 다르겠지만, 일정 수준의 가드레일을 갖추고 우리같은 여건에서 어떻게 해야하는지 추이를 보고 있는 중이다.
**Part 2 에서 이어집니다.
댓글 없음:
댓글 쓰기