챗봇 서비스 개발 과정

기존 챗봇의 한계를 넘기 위해 OpenAI ChatGPT와 Function Calling을 활용해 사용자 의도를 파악하고, 내부 데이터에서 필요한 검색 파라미터를 추출하는 구조를 만들었다.

전체 흐름은 질문을 받은 뒤 검색 서버와 Vector DB에서 관련 콘텐츠를 조회하고, 그 결과와 원본 질문, 프롬프트를 합쳐 다시 LLM에 전달해 최종 답변을 생성하는 방식으로 구성했다. 답변 생성 결과와 대화 이력은 모두 저장해 이후 개선에 활용했다.

정확도를 높이기 위해 RAG를 단계적으로 확장했다.

• 1단계에서는 사람인 도움말, FAQ, 상품 정보처럼 정제된 데이터를 VectorDB에 저장해 검색했다.
• 문서는 단순 분할 대신 제목과 내용을 한 쌍으로 다뤘고, 각각 별도 임베딩을 생성했다.
• 제목과 내용의 유사도 가중치를 5:5로 두었을 때, 약 500개 테스트 질문에서 정답 문서 탐색 정확도가 **87%**로 가장 높았다.
• 일부 도움말은 Notion API로 수집해 벡터화하는 방식까지 확장했다.

2단계에서는 기존 내부 콘텐츠 검색 API를 RAG 파이프라인에 통합했다. 별도 적재 없이 검증된 리소스를 재활용할 수 있었고, Function Calling으로 어떤 API를 호출할지와 전달 파라미터를 결정하게 했다. 응답 데이터는 Extraction Schema로 정리해 비공개 정보는 걸러내고 필요한 텍스트만 LLM에 전달했다.

답변 품질은 프롬프트 설계에 크게 좌우됐다. 사람인 콘텐츠에 기반해 답변하고, 정보가 없으면 추측하지 않으며, 서비스 범위를 벗어난 질문은 응답하지 않도록 원칙을 명확히 넣었다. 짧고 명료한 지시, 예시 포함, 구역 분리, 순서화 같은 규칙을 적용해 품질을 끌어올렸다.

검색 실패를 줄이기 위해 Multi-subject 기능도 도입했다. 하나의 콘텐츠에 대해 원래 제목, 운영자가 추가한 유사 제목, LLM이 본문을 분석해 만든 요약 제목을 함께 관리해 사용자가 다른 표현으로 물어봐도 정답 문서를 찾기 쉽게 만들었다.

복잡한 워크플로우 제어에는 LangGraph를 사용했다. 상태(State), 노드(Node), 엣지(Edge) 기반 구조로 질문 분기, 반복 처리, 오류 재시도, 스트림/일반 응답 코드 중복 문제를 해결했다. 짧은 질문이나 비속어처럼 유효하지 않은 입력은 LLM 호출 없이 고정 답변으로 처리하고, 여러 콘텐츠가 필요한 경우에는 순환 구조와 병렬 처리를 활용했다.

운영 구조는 채팅 시스템과 Bot 시스템을 분리한 멀티테넌시 아키텍처로 설계했다. Admin에서 데이터 소스, 프롬프트, LLM 모델을 동적으로 설정할 수 있고, 현재는 사람인 Bot, 노무 상담 Bot, 비긴즈 Bot, Komate Bot 등 4종을 운영 중이다. 하나의 Bot이 여러 검색 서버를 참조할 때도 Function Calling으로 적절한 데이터 소스를 선택하게 했다.

모든 질문과 답변, 참조 콘텐츠, 프롬프트, 처리 시간 등의 이력을 저장해 모니터링과 개선에 활용했다. 고객 지원팀과 함께 분석해 콘텐츠의 빈틈을 찾아 보강했고, 서비스 오픈 이후 약 20%의 콘텐츠를 개선하는 성과를 얻었다.