1차 PoC: 잡음이 너무 많은 검색 데이터
에이전트 애플리케이션이 출시되기 전에, 서비스 주요 담당자들을 대상으로 에이전트 시스템의 시연 시간을 가졌다. [스트림릿 기반]
1차적으로 시연했을 때의 문제점은 너무 많은 데이터를 벡터화하면서 생긴, 검색 품질의 저하가 이슈였다.
오피스 데이터를 취급하다 보니 반복적인 데이터(교육 공지, 복지 공지, 동호회 활동, 등등...)들이 너무 많이 쌓여있는 상태였고,
휴가와 관련된 공유 글까지 벡터 검색에 잡히면서 질의의 의도와는 거리가 먼 정보들이 선택되었고, 결국엔 엉뚱한 응답으로 향하게 되었다.
에이전트 담당자와 모여서 의논했고, 정보성이 부족하거나 반복적인 템플릿을 사용하는 글들을 덜어내기로 했다.
그렇게 정제 후 500자가 되지 않은 정보성이 낮은 글들을 제외시킨 후 학습하고,
특정 게시판만 한정해서 벡터 DB에 올려두니 검색의 품질은 어느 정도 개선되었다.
어떤 글이 정보성이 있냐를 어떻게 판단할 것인가는 아직도 해결되지 않은 이슈로 남았다.
우리 회사의 데이터만 고민해야 하는게 아닌, 전체 고객사를 대상으로 고민해야 하기 때문에 단편적인 판단으로 접근할 일이 아니었다.
2차 PoC : 응답까지의 과정이 너무 길다.
시간이 지나 2차 PoC를 진행했다. 이번에는 더 많은 사람들이 참석해서 시연에 대해서 피드백을 남겨줬다.
1회 응답까지 5번의 LLM API를 사용하는 것이 발목을 잡았다.
나름 줄인다고 줄인 에이전트 구조이지만, 고객의 경험을 저해하는 수준까지 응답 속도가 느려졌다.
LLM을 중심에 두고 애플리케이션을 구현하다 보면 굵직한 로직에서 LLM의 판단을 사용할까 말까 하는 유혹에 빠지게 된다.
위협을 판단하자, 에이전트를 판단하자, 질문을 정제하자, 문서가 질의에 적합한 문서인지 판단하자 등등..
인지 측면에서 그간 무의식적으로든 의식적으로든 빠르게 판단되었던 과정들을 하나하나 LLM이 판단하게끔 만들다 보니
응답까지의 시간을 오래 잡게 되었다.
더 아쉬운 것은 그렇게 오랜 노력 끝에 나온 응답이 질의에 대한 응답으로 만족하기 어려웠다는 부분이다.
고객은 오랜 시간 기다렸고, 저품질의 응답을 받을 가능성이 높은 상황이다.
무엇을 고민해야할까?
작년에는 상태 유지가 필요없는 LLM 활용 API만을 개발했다. 요약, 번역, 스타일 변경 등등이 그러하다.
이런 기능들은 맥락 자체에서 AI의 사용성이 명확하다 보니, 기능에 지정된 프롬프트를 잘 엔지니어링 하고,
클라이언트로부터 풍부한 정보를 받을 수 있다면 만족스러운 품질의 결과를 만들수 있었다.
1회성 API 개발 이후 고도화된 에이전트 시스템 구축을 시작했다.
자연어 질의 기반으로 chat GPT와 유사한 방식으로 사용자 경험을 전달하는 것이 목표이다.
인지 아키텍처의 첫 시작은 사용자 질의에 대한 분석이다.
검색을 원하는 것인지, 검색도 하고 응답을 원하는 것인지, 요청한 작업이 단계적인 수행을 거쳐야 하는 것인지 등등을 판단해야 한다.
이후 적합한 에이전트를 선택하고, 검색을 진행한다.
검색이 끝난 후 상위 K개의 문서를 대상으로 질의에 가장 적합한 문서를 선택한다.
그렇게 최종적으로 선택된 문서를 대상으로 응답을 생성!
대화가 끝난 시점에는 마지막으로 대화의 요약본을 남겨 메모리에 보관한다.
이 로직은 질의 판단까지 3초, 검색 후 응답까지 5~20초, 메모리 관리까지 3~5초가 소요된다.
2차 PoC를 끝내고 우리는 무엇을 고민해야 하는가라는 질문을 하게 되었다.
상무님은 "개발의 관점이 아니라 사용자의 관점"에서 판단해 달라고 요청했다.
고객이 PoC에서 보여준 질의를 할 확률이 얼마나 될까? 사용자는 수십초의 시간을 그냥 기다려줄까?...
1차 PoC의 피드백에서 응답의 품질에 초점을 두었다면 2차 피드백은 사용자 경험이었다.
2차 PoC가 끝난 후, 몇가지 부분을 덜어내거나 개선하기로 결정했다.
1. 응답 스트리밍
응답이 오랜 시간 걸릴지 아무것도 모르는 상황에 더 사용자를 마냥 기다리게 할 수는 없었다.
가장 좋은 방법은 구글 제미나이처럼 과정을 밟아가는 과정을 보여주는 것이다.
EX. 질의 판단 과정, 어떤 에이전트 선택, 문서 검색 중..., 응답 생성 중... 등등 응답 결과에 대한 과정 상태 정보를 보여주는 것
2. 자율성 줄이기.
판단 로직을 최대한 가볍게 가져가는 것, 일반 검색 (외부 자료 검색)은 빼는 게 좋아 보였다.
이런 기능들은 부가적이지 본질적인 것은 아니다.
1차적으로 고객은 자신이 가진 혹은 회사가 가진 데이터에서의 검색을 원할 것이라는 가정하고 진행하기로 했다.
3. 검색된 데이터를 다시 랭킹 하는 작업 덜어내기
검색 데이터의 품질을 개선하기 위한 작업은 어느새 코어 한 영역으로 자리를 잡았고, 계속해서 엔지니어링을 시도해야 하는 영역이다.
데이터 자체의 품질을 높이는 것에 집중해야지,
가져온 문서를 대상으로 리랭킹을 하는 작업에 집중하는 것은 중요하지 않다고 판단하게 되었다.
특히 원하는 데이터를 검색하지 못해서 질의를 새롭게 변경하고 다시 검색 로직을 수행하는 그래프형 구조는
사용자의 응답 경험을 매우 좋지 않게 만들었다.
신뢰성과 자율성의 트레이드오프
러닝 랭체인 도서의 8장에서 "LLM의 성능"에 대한 고민에 대해서 2가지 축을 설명해 준다.
하나는 자율성이고, 다른 하나는 신뢰성이다.
자율성을 추구할수록 에이전트 아키텍처는 그래프 구조를 가지고, 신뢰성을 추구할수록 단일 플로우인 체인형 구조를 가지게 된다.
AI 애플리케이션은 그래프와 체인형 구조 어느 사이에서 적절한 균형점을 찾아내야 한다.
현시점 우리 팀은 그래프형 구조와 체인형 구조 사이의 어딘가를 고민하고 있다.
느린 응답으로 실패하기 보다는, 빠르게 실패한 응답이 더 괜찮은 상황.
"장고 끝에 악수 둔다"라는 말이 있는데, 에이전트 아키텍처도 비슷하다고 생각한다.
에이전트가 오랜 시간에 걸쳐서 수행할 작업은 복잡한 응답을 생성하기 위한 단계를 분석하고 수행하는 작업이어야 하지,
무엇을 하고 어떤 데이터를 고를지는 고민하는 것은 아니라고 생각한다.
무엇을 하고, 어떤 데이터를 고를지에 대해서는 개발자가 더 잘해줄 수 있는 영역이라고 생각한다.
멋진 AI 서비스들을 보면서, 어떻게 내부가 돌아가고 있을지 고민하게 되는 요즘이다.
'직장 생활 > 질문 응답' 카테고리의 다른 글
| 에이전트에서 툴 결과 응답만 내려주도록 구현하기 [feat: langchain] (0) | 2025.12.08 |
|---|---|
| 랭그래프에 등록된 노드에서 호출한 에이전트의 writer 이벤트 전달하기 (tool) (0) | 2025.12.08 |
| 벡터와 임베딩의 차이점이 뭘까? (0) | 2025.05.11 |
