프로젝트 리뷰 1-2
초기 챗봇 설계
허깅페이스, 체인을 활용해 챗봇을 제작
- 에이전트로 만들 필요가 없다고 생각했기 때문
- 설계 당시엔 대규모의 챗봇이라곤 생각하진 않았음.
- 또한 당시엔 금융 분야에선 망 분리 정책을 이유로 gpt보단 허깅페이스에서 모델을 가져와 개발을 하려고 계획함
에이전트란?
- 에이전트
- LLM이 어떤 행동을 취하고, 어떤 요소가 필요한 지 추론하게 해주는 시스템
- 행동을 취하고 나면 그 결과를 LLM에 보낸다
- LLM은 결과를 바탕으로 더 행동을 계속해야 하는지, 이정도면 충분한지 결정
- 주로 대규모의 여러 기능이 탑재되는 챗봇 제작에 쓰임
설계 변경
- 허깅페이스 기반 LLM 사용에서 open ai api 사용으로 바꿈
- 허깅페이스 기반으로 만들 시 gpt 기반보다 성능이 안나옴
- 개발 인력이 필자 혼자라 6주안에 gpt와 비슷한 성능을 내는 모델 개발이 힘들것이라 예상함
- 이는 사용자의 UX에 있어 큰 악재라 여김
- 또한 금융감독원에서 생성형 AI에 한해 조건부로(익명화) 망분리 규제를 완화해준다는 소식을 들은 후 허깅페이스 기반 모델을 고집할 필요가 없어짐
- 에이전트를 활용해 개발
- 특정한 상황에서만 어떠한 함수를 호출하기 위해선 툴 바인딩보단, 에이전트를 활용하는 것이 낫다고 판단
- 이렇게 해야 더 안정적인 성능을 낼 수 있어 사용자 편의를 해치지 않을 것이라 생각했기 때문
- 벡터스토어 분리
- 초기엔 하나의 벡터스토어로 해결하려 했다
- 하지만 새로운 정보가 계속 업데이트 되면 검색시간이 늘어날 것이라 생각했다
- 또한 전혀 관련이 없는 정보를 한곳에 쌓아두고 찾게 하면 잘못된 정보가 LLM에 전달될 가능성도 생김.
- 이는 사용자의 불편을 유발할 수 있는 문제
- 이를 해결하기 위해 금융 용어 사전과 사용자 메뉴얼을 분리하여 관리
- agentic rag 기법을 활용해 이를 구현
agentic rag
- 어떻게 사용자의 질문과 가장 관련있는 질문을 찾을 건지 알아내기 위해 에이전트를 쓰는 것
- 쉽게 말해 검색기를 에이전트 툴로 사용하는 것
다행히도 이런 설계 변경을 통해 개발을 성공적으로 끝낼 수 있었다.