AI 영업 에이전트가 답변하기 전에 컨텍스트 리졸버(Context Resolver)를 추가했습니다

대부분의 AI 영업 에이전트(AI sales agents)는 모델이 단 한 단어를 쓰기도 전에 실패합니다.

실패의 원인이 항상 프롬프트(Prompt) 때문만은 아닙니다. 대개는 컨텍스트(Context, 문맥) 때문입니다.

실제 채팅 커머스(Chat-commerce) 워크플로우에서 리드(Lead)는 여러 가지 상충하는 신호와 함께 도착할 수 있습니다:

최신 고객 메시지;
CRM 단계 및 담당자;
이전 대화 기록;
캠페인 또는 유입 경로 데이터;
제품/카테고리 가정 사항;
승인된 응답 규칙;
인수인계 및 지원 정책.

이 모든 정보가 프롬프트에 한꺼번에 쏟아부어지면, 모델은 잘못된 단서를 바탕으로 유창한 답변을 생성할 수도 있습니다.

이것은 추상적인 의미에서의 AI 문제가 아닙니다. 운영 체제(Operating-system)의 문제입니다.

문제점

저는 채팅 기반의 커머스 운영을 위한 AI 접수 에이전트(AI reception agent)를 설계하고 있었습니다.

목표는 간단했습니다. 각 리드 뒤에 숨겨진 상업적 컨텍스트를 놓치지 않으면서, 비즈니스가 더 빠르고 일관되게 답변하도록 돕는 것이었습니다.

하지만 첫 번째 자동 응답에는 숨겨진 위험이 있었습니다.

고객은 "안녕하세요" 또는 "더 자세한 정보를 원합니다"와 같은 짧은 메시지를 보낼 수 있습니다. 그 메시지 자체만으로는 정보가 부족합니다. 더 강력한 신호는 캠페인, 유입 경로, CRM 단계, 제품 페이지, 이전 대화 또는 승인된 판매 규칙일 수 있습니다.

만약 AI 에이전트가 가능한 모든 컨텍스트를 한꺼번에 받는다면, 여전히 무엇이 중요한지 결정해야 하는 상황에 놓입니다.

그 결정권을 전적으로 생성(Generation) 단계에 맡겨서는 안 됩니다.

설계 선택

저는 AI 응답 전에 컨텍스트 리졸루션(Context-resolution, 문맥 해결) 단계를 추가했습니다.

모델에게 모든 단서를 조사하고 즉흥적으로 대응하라고 요청하는 대신, 워크플로우가 먼저 더 작은 객체를 해결(Resolve)하도록 했습니다:

{
  "source_priority": "campaign_or_crm_or_message_or_fallback",
  "category": "resolved_commercial_category",
...

중요한 것은 정확한 스키마(Schema)가 아닙니다. 결정의 순서입니다.

시스템은 먼저 어떤 상업적 컨텍스트가 가장 신뢰할 수 있는지 결정합니다. 그 후에야 AI 에이전트가 답변을 작성합니다.

아키텍처

워크플로우는 다음과 같습니다:

유입된 채팅 리드 (Incoming chat lead).
CRM 및 대화 내역 조회 (CRM and conversation lookup).
캠페인 또는 소스 컨텍스트 조회 (Campaign or source-context lookup).
컨텍스트 리졸버 (Context resolver).
해결된 상업적 컨텍스트 (Resolved commercial context).
AI 응답 에이전트 (AI response agent).
구조화된 응답 및 라우팅 결정 (Structured response and routing decision).
고객의 답장 또는 상담원 연결 (Customer reply or human handoff).

리졸버(Resolver)는 의도적으로 지루하게 설계되었습니다.

이것은 창의성 계층 (Creativity layer)이 아니라 제어 계층 (Control layer)입니다.

리졸버는 다음과 같은 질문에 답하기 위해 존재합니다:

리드가 아마도 무엇에 대해 묻고 있는가?
신호가 충돌할 때 어떤 소스가 우선권을 가져야 하는가?
직접 답변할 수 있을 만큼 신뢰도 (Confidence)가 충분한가?
어떤 승인된 영업 규칙 (Sales rule)을 사용해야 하는가?
시스템이 답변해야 하는가, 명확한 질문을 던져야 하는가, 아니면 사람에게 연결해야 하는가?

이것이 중요한 이유

비즈니스 워크플로우 (Business workflows)에서 "더 많은 컨텍스트"가 항상 더 좋은 것은 아닙니다.

더 많은 컨텍스트는 더 많은 모호함 (Ambiguity)을 의미할 수 있습니다:

오래된 메시지가 새로운 메시지와 충돌함;
일반적인 플레이북 (Playbooks)이 캠페인별 특화 오퍼 (Offers)와 충돌함;
제품에 대한 가정이 고객이 실제로 질문한 내용과 충돌함;
내부 규칙이 고객 지향적 언어와 충돌함.

컨텍스트 리졸버는 모델이 응답하기 전에 이러한 모호함을 줄여줍니다.

모든 답변이 선택된 컨텍스트, 신뢰도 수준 및 지침 (Directive)으로 추적될 수 있기 때문에 AI 계층 (AI layer)의 디버깅 (Debug)이 더 쉬워집니다.

가드레일 (Guardrails)

이 워크플로우는 AI 응답 주변에 여러 가드레일을 유지합니다:

낮은 신뢰도는 상담형 폴백 (Consultative fallback)을 트리거함;
민감한 상업적 사례는 사람의 검토로 라우팅될 수 있음;
생성 전 승인된 응답 규칙이 선택됨;
에이전트는 노이즈가 많은 데이터 덤프 (Noisy dump) 대신 압축된 컨텍스트 패키지를 전달받음;
시스템은 어떤 컨텍스트가 사용되었는지 로그를 남김.

이것은 AI를 더 인상적으로 들리게 만들기 위한 것이 아닙니다.

운영 결정 (Operational decision)을 더 안전하게 만들기 위한 것입니다.

다음에 측정할 항목

현재 공개 버전에서는 검증되지 않은 수치를 발표하고 싶지 않기 때문에 지표를 수집할 지표 (metrics to collect)로 유지하고 있습니다.

유용한 지표는 다음과 같습니다:

컨텍스트 리졸버 (Context Resolver)가 처리한 리드 (lead) 규모;
잘못된 컨텍스트 (wrong-context) 답변의 감소율;
리스크 카테고리별 상담원 전환율 (human handoff rate);
응답 시간 (response-time)에 미치는 영향;
절약된 수동 검토 시간.

교훈 (The Lesson)

수익 창출 워크플로 (revenue workflows) 내의 AI 에이전트에게 있어, 프롬프트 (prompt)는 시스템의 일부분일 뿐입니다.

더 어려운 설계 질문은 다음과 같습니다:

모델이 무엇을 알고, 무엇을 신뢰하며, 무엇에 따라 행동하도록 허용해야 하는가?

이것이 제가 AI 에이전트를 다음과 같은 운영 워크플로 (operating workflows)로 설계하는 것을 선호하는 이유입니다: 컨텍스트 리졸루션 (context resolution), 검색 (retrieval), 가드레일 (guardrails), 구조화된 출력 (structured outputs), 인간의 검토 (human review) 및 관찰 가능성 (observability).

공개된 케이스 스터디 (case study)는 여기에서 확인할 수 있습니다:

https://github.com/rkrisa/portfolio-ai-ops/tree/main/cases/context-aware-ai-reception-agent