벤더 CS 에이전트

태그된 질문에만, 인계 없이 답하고, 숫자와 브랜드는 근거와 대조해 고쳐 쓰는 카톡 챗봇

직원 PC에서 대화를 모아 서버로 올리고, 답도 직원 맥에서 보냅니다. 서버 에이전트는 거래처별 기록과 LightRAG 지식 허브(개체·관계 그래프 RAG, 워크스페이스 13개)를 검색해 답을 씁니다. 2026-09-02부터 되묻기를 끄고 태그된 질문에만, 인계 없이 답합니다. 대신 금액·%·브랜드를 근거와 맞춰 보고, 어긋나면 다시 검색해 고쳐 씁니다.

비슷한 이름으로는 거래처를 정하지 않습니다. 방 이름 앞 '(1234)'를 ID로 읽습니다. 이름 부분이 다른 벤더를 자모 유사도 0.80 이상으로 더 잘 가리키면 ID 오타로 보고 막습니다. ID가 없으면 정확히 같거나 포함 관계인 이름 하나만 인정합니다. 흔한 접미어만 겹쳐도 0.81~0.88이 나와서 퍼지 매칭은 버렸습니다.
메시지 1건이 51번 들어왔습니다. kakaocli는 안 읽은 방의 최신 메시지를 2초마다 다시 보냅니다. 세어 보니 1건에 51회, 분당 170~200건이었습니다. (방, 메시지, 안읽음 수, 내가 보냄) 키로 15초 안의 재전송을 버립니다. 안읽음 수가 키에 있어서 방을 닫고 다시 연 신호는 통과합니다.
숫자와 브랜드는 코드로 대조합니다. 초안의 금액과 %를 정규화합니다('3만원'은 30000원). 검색 근거에 없는 값, 근거 브랜드와 한 글자만 다른 단어를 위반으로 잡습니다. LLM 판정이 실패하거나 애매하면 근거 없음으로 봅니다. 위반이 나오면 이유를 붙여 다시 검색하고 고쳐 씁니다.
'보냈다'는 사실일 때만 씁니다. 그 턴에 발송 API가 안 불렸으면 '제안서 보내드렸습니다' 같은 완료형 문장은 지웁니다. 같은 idempotency key로 재요청이 오면 실제 큐 상태를 봅니다. 처리 중이거나 보낸 건은 다시 넣지 않고 실패한 건만 재시도합니다. 상태를 모르면 성공 대신 에러를 냅니다.
다른 거래처 사례는 가립니다. 검색 결과에 지금 거래처가 아닌 벤더명이 나오면 [다른 벤더]로 바꾸고, 바꿨다는 사실을 모델에 알립니다. 회사 전체를 조회하는 Spark 도구 11개는 외부 방에서 모두 막습니다. 상품 추천 조회에 넣는 벤더명은 모델이 아니라 서버가 정합니다.
도착은 카톡 DB 개수로 셉니다. 보내기 전에 기준 개수를 잡아 둡니다. 보낸 뒤 로컬 DB에서 글과 사진이 몇 개 늘었는지 세고, 빠진 쪽만 다시 보냅니다. 사진은 60초를 더 기다립니다. 70명 방에 같은 사진이 두 번 가는 쪽이 한 장 빠지는 쪽보다 나빠서입니다. 서버에 완료를 알리는 것도 이 확인 뒤입니다.
체크포인트는 2xx 뒤에만 옮깁니다. 업로드기는 2xx를 받은 뒤에만 오프셋을 옮깁니다. 422·413은 건너뛰고, 5xx·429면 커밋 없이 멈췄다가 다음 회차에 다시 올립니다.
처리 경로가 스스로 생존 표시를 남깁니다. 태그 메시지를 접수할 때와 결과에 닿았을 때 한 번씩 표시를 남깁니다. 업무시간 기준 임계값을 넘도록 결과 표시가 없으면 감시가 잡아냅니다. 감시가 밖에서 '초안이 없으면 멈춘 것'으로 추정하던 방식은 리뷰에서 뺐습니다. 이 경로의 시험은 30개입니다.