5.7 KiB
5.7 KiB
3단계 의도 파악 아키텍처에 DB/베이지안 방법 통합
작성일: 2025-11-26
작성자: Auto (Claude)
관련 문서:
251126_intent_3step_architecture_plan.md- 3단계 아키텍처 계획251023_happybell80_의도_런타임_하이브리드_임베딩_베이지안_동적학습.md- 기존 베이지안/임베딩 방법
1. 문제 발견
1.1 시나리오 테스트 결과 미비
5가지 TDD 시나리오 테스트 결과:
- ✅ 시나리오 1: 일정 등록 동의 처리 - 통과
- ❌ 시나리오 2: 미구현 의도 처리 - "회의실 예약"이 단순 조회로 처리, clarify 없음
- ❌ 시나리오 3: 복합 의도 처리 - "검색→분석→이메일"이 단일 SEARCH_WEB만 생성
- ❌ 시나리오 4: 맥락 기반 의도 파악 - "그 회사 투자 단계"가 UNKNOWN으로 분류
- ❌ 시나리오 5: 모호한 의도 명확화 - "이메일 보내줘"가 clarify 없이 READ_EMAIL로 처리
1.2 근본 원인
현재 구현의 한계:
- IntentAnalyzer의
_fallback_analyze가 키워드 기반이라 정확도 낮음 - ActionPlanner가 복합 의도나 모호한 의도를 단일 액션으로 단순화
- 맥락 기반 의도 파악이 미흡함
- DB 기반 학습 메커니즘 미활용
2. 기존 방법 분석
2.1 Naive Bayes (intent_bayes.py)
구현 방식:
intent_classifier테이블에 단어별 doc_count/email_count 저장- 메시지 토큰화 후 각 단어의 DB 카운트로 베이지안 사후확률 계산
P(doc|message) = P(message|doc) * P(doc) / P(message)형태
사용 위치: DecisionEngine.analyze_intent()에서 문서/이메일 사전 분류
2.2 Semantic Classifier (semantic_classifier.py)
구현 방식:
intent_prototypes테이블(pgvector)에 intent별 centroid 임베딩 저장intent_thresholds테이블에 semantic/LLM 경로별 임계값 저장- 메시지 임베딩과 prototype 임베딩의 코사인 유사도로 Top-K 후보 추출
사용 위치: DecisionEngine._semantic_fallback(), IntentGraph.detect()
2.3 베이지안 동적 학습
구현 방식:
intent_path_stats테이블에 경로별 성공률 Beta(α,β) 추적- 성공 시 α+=1, 실패 시 β+=1
- Thompson Sampling으로 FastPath/LLM/clarify 임계치 동적 최적화
사용 위치: 현재 설계 단계, 구현 예정
3. 새로운 해결책
3.1 IntentAnalyzer 통합
기존 방법 재사용:
# IntentAnalyzer.__init__()
self.semantic_classifier = SemanticIntentClassifier() # 기존 인스턴스 재사용
# IntentAnalyzer.analyze_sync()
top_candidates = self.semantic_classifier.top_k(message, k=3)
confidence = self.semantic_classifier.confidence(top_candidates)
개선 방안:
intent_prototypesDB로 임베딩 기반 후보 축소 후 LLM 재분석- 맥락 기반 의도 파악: 최근 대화 컨텍스트와 결합하여 임베딩 유사도 계산
intent_thresholds의 임계값으로 confidence 기반 clarify 판단
3.2 ActionPlanner 통합
기존 방법 재사용:
# intent_path_stats 테이블에서 경로별 성공률 조회
# Beta(α,β) 파라미터로 액션 우선순위 조정
개선 방안:
intent_path_stats의 Beta(α,β)로 경로별 성공률 기반 액션 우선순위 조정- 복합 의도 파싱: LLM으로 여러 액션 추출 (SEARCH_WEB → ANALYZE_DOCUMENT → SEND_EMAIL)
- 모호한 의도 감지: confidence 낮을 때
requires_clarification=True설정
3.3 SkillSelector 통합
기존 방법 재사용:
# 스킬별 실행 성공률을 DB에 추적
# intent_path_stats 또는 별도 skill_stats 테이블 활용
개선 방안:
- 스킬별 실행 성공률을 DB에 추적해 동적 스킬 선택 최적화
- 미구현 스킬 감지: 스킬 존재 여부 확인 후 없으면 clarify 반환
- 스킬 효율성 계산: 기존
decide_skill_sequence의 효율성 계산 로직 활용
4. 기대 효과
4.1 시나리오별 개선
- 시나리오 2: 미구현 스킬 감지 후 clarify 메시지 반환
- 시나리오 3: 복합 의도에서 여러 액션 생성 (SEARCH_WEB → ANALYZE_DOCUMENT → SEND_EMAIL)
- 시나리오 4: 맥락 기반 의도 파악 정확도 향상 (임베딩 유사도 + 컨텍스트 결합)
- 시나리오 5: 모호한 의도 감지 후 clarify 메시지 생성
4.2 전반적 개선
- 데이터 기반 학습: 시간이 지날수록 정확도 향상
- 동적 임계값 조정: 베이지안 업데이트로 자동 개선
- 비용 효율: FastPath/임베딩 우선, LLM 호출 최소화
5. 구현 계획
5.1 Phase 1: IntentAnalyzer 통합 (1일)
SemanticIntentClassifier인스턴스 생성 및 재사용intent_prototypesDB 활용한 임베딩 기반 후보 축소- 맥락 기반 의도 파악 로직 추가
5.2 Phase 2: ActionPlanner 통합 (1일)
intent_path_stats조회 로직 추가- 복합 의도 파싱 로직 추가 (LLM 활용)
- 모호한 의도 감지 및 clarify 로직 추가
5.3 Phase 3: SkillSelector 통합 (1일)
- 스킬 존재 여부 확인 로직 추가
- 스킬별 실행 성공률 추적 로직 추가
- 동적 스킬 선택 최적화 로직 추가
5.4 Phase 4: 테스트 및 검증 (1일)
- 5가지 시나리오 재테스트
- 성능 측정 (정확도, 지연시간, 비용)
- DB 데이터 모니터링
6. 리스크 및 완화
- DB 의존성: DB 연결 실패 시 폴백 로직 필수
- 성능 영향: 임베딩/DB 조회 추가로 인한 지연시간 증가 가능 → 캐싱 고려
- 데이터 품질:
intent_prototypes데이터 부족 시 성능 저하 → 시드 데이터 확보
작성 완료: 2025-11-26
다음 단계: Phase 1 구현 시작