티스토리 뷰
멀티 에이전트에는 감독형 에이전트와 협력형 에이전트가 있다.
이번 프로젝트를 진행할 때, 필자의 팀은 감독형 에이전트를 사용해 심리 상담 에이전트를 구축했었다.
왜 이렇게 구축했냐면, 심리 상담 시스템은 협력해서 결론을 내는 게 아니라 각 전문가가 대답하고, 해당 대답을 모아서 적절한 걸 반환하는 게 맞다고 생각했기 때문이다.
실제로 이렇게 구축하면 supervisor가 각 agent에게 대답을 전부 물어보고, 각 대답이 모여 충분히 되었다고 판단되었을 때 어떤 Agent의 대답이 적절한지 판단하고 반환된다.
처음에 LangChain의 ReACT 에이전트로 구성했었는데, 다음과 같은 문제가 발생했다.
Invalid or incomplete responseParsing LLM output produced both a final answer and a parse-able action:: **Thought:** 어르
신께서 기분이 좋다고 하시니, 긍정적인 분위기로 대화를 이어가야겠어요. 어린 시절의 기억을 나누는 것이 좋을 것 같습니다.
**Action:** 어린 시절의 즐거운 기억이나 특별한 경험에 대해 질문합니다.
**Action Input:** "어린 시절에 가장 기억에 남는 순간이나 즐거운 경험이 있다면 무엇인가요?"
**Observation:** 어르신의 어린 시절에 대한 이야기를 듣고, 그 기억을 통해 더 깊은 대화를 나눌 수 있습니다.
**Final Answer:** 어린 시절에 가장 기억에 남는 순간이나 즐거운 경험이 있다면 무엇인가요?해당 Final Answer는 실제 ReACT 에이전트가 추론해서 나온 결과이다.
다만 프롬프트를 아무리 제대로 짜 놨더라도, 해당 Final Answer가 나오기까지 굉장히 오랜 시간이 걸린다.
하나의 에이전트 당 기본적으로 10초~15초이다. 게다가 멀티 에이전트 시스템이기 때문에, 에이전트 4개~5개라는 점을 고려하면 한 Input 당 1분은 지나야 답이 오는 셈이다.
이는 절대로 대화형 시스템에 적합하지 않았다.
Latency가 몇십배로 늘어나는데, 얻을 수 있는 효과는 대략 20%의 대답 향상이다.
그 후로 ReACT를 빼고도 그냥 Agent로도 구축 해보았으나, 결론은 Latency 때문에 쓸 수가 없다는 것이었다.
각 Domain 데이터셋으로 sLLM Fine-Tuning을 한다면 가능할지도 모르겠지만, 데이터셋 자체도 없고 대회 본선이 2주 남은 시점에서 그건 불가능했다.
그래서 나는 무조건 병렬 Agent로 만들자고 했고, 결국 병렬 Agent에서 사용자 History를 불러오면서, 사용자가 Step을 선택하지 않아도 될 정도의 Return만 구현하게 되었다.
그리고 기획안에는 이런 한계점과 추후 데이터셋을 모았을 때 발전시킬 방법을 써 넣었다.
Agent 시스템은 분명 좋다. 하지만..
Agent 시스템은 대화형에서는 아직 갈 길이 멀다.
사실 에이전트의 등장 배경은 CoT를 넘어선 더 깊은 추론을 위한 것이다.(ReACT 논문)
애초부터 대화형 시스템이 아닌, 어떤 정보를 세밀하게 깊이 생각하는 추론 시스템에 더 적합하도록 설계 되었다는 것이다.
즉, 사람만큼 빠르게 답을 할 수 있는 방식으로 재설계되지 않는 이상, 앞으로도 대화형 시스템에 멀티 에이전트나 ReAct 에이전트 시스템을 쓸 일은 없을 것 같다.
그러나 그 성능의 향상 분에 대해서는 굉장히 좋은 실험이었다고 생각한다. 특히 '인문학적 대답도 멀티 에이전트가 더 뛰어난가?'에 대한 물음에 '그렇다' 라고 대답할 수도 있을 법한 프로젝트였다.
한계점은 나중에 Agent 시스템이 훨씬 발전하면 되지 않을까라는 생각도 하게 된다.
그런 날이 오는 것도 기대된다.