TechAssistant — AI 기술문의 자동 답변 시스템

Problem

LLM이 실제로 존재하지 않는 API · 이벤트 · 속성명을 그럴듯하게 지어내 답변에 넣었습니다.

Cause

생성 모델은 문법적으로 자연스러운 이름을 만들어내기 때문에, 사람이 읽어서는 실존 API와 구분이 되지 않았습니다. 기술지원 답변에서는 이런 오답이 그대로 고객에게 나갑니다.

Solution

답변에 등장한 모든 API · 이벤트 · 속성명을 추출해 로컬 가이드 문서와 RAG DB에서 $contains로 실존 여부를 검증하는 루프를 넣었습니다. 미확인 항목이 있으면 해당 API를 제외하고 최대 3회까지 재생성합니다.

Problem

정상적인 기술 문의가 자꾸 human_review · blocked로 격상돼 자동 답변률이 떨어졌습니다.

Cause

위험도를 산정할 때 RAG로 검색된 이웃 사례(cases)의 텍스트까지 포함하고 있었습니다. 과거 위험 사례가 유사 문서로 딸려오면, 정작 지금 질문은 멀쩡한데도 그 키워드 때문에 등급이 올라갔습니다.

Solution

판정 기준을 질문 본문과 첨부파일로만 한정하고, 검색 결과(cases)는 제외했습니다. 판정 입력과 참고 자료를 분리하니 오격상이 사라졌습니다.

Problem

라이선스 발급 · 데모 요청 · 엔진 파일 제공 같은 문의에도 RAG 검색과 LLM 호출이 그대로 돌았습니다.

Cause

이런 문의는 애초에 기술 답변 대상이 아니라 담당자 안내가 필요한 서비스 요청인데, 파이프라인이 모든 문의를 동일하게 취급했습니다.

Solution

분류 직후 서비스 요청을 걸러내는 short-circuit을 넣어, RAG·LLM을 거치지 않고 담당자 안내 템플릿만 반환하도록 했습니다. 불필요한 LLM 호출과 대기 시간이 사라졌습니다.

Problem

외부 LLM을 호출해야 하는데, 문의 본문에는 고객사명·담당자 이름·프로젝트명이 그대로 들어 있었습니다.

Cause

기술문의는 대부분 실제 프로젝트 맥락과 함께 오기 때문에, 원문을 그대로 보내면 고객사 정보가 외부로 나갑니다.

Solution

이름 · 이메일 · 회사명 · 프로젝트명을 제거하는 마스킹 모듈을 파이프라인 앞단에 두고, 마스킹된 텍스트만 LLM에 전달하도록 했습니다. 실행은 종량 과금 API 대신 CLI(codex exec) 방식을 채택해 별도 API 비용 없이 운영하고 있습니다.

Problem

운영 중 서버가 죽거나 LLM 호출이 rate limit에 걸려도, 다음 날 아침에야 알게 됐습니다.

Cause

단독으로 개발·운영하다 보니 상시 감시할 사람이 없었고, 장애를 알려주는 경로 자체가 없었습니다.

Solution

cron 5분 주기 워치독을 붙여 /api/health 실패 시 자동 재기동하고, 에러 로그에서 codex exec 실패 · rate limit · quota · 401/429 신호를 스캔해 Discord로 알립니다. 첫 실행 시에는 과거 로그 전체가 쏟아지지 않도록 오프셋만 기록하고 넘어가게 처리했습니다.