docs: 3단계 아키텍처에 DB/베이지안 방법 통합 방안 추가
This commit is contained in:
parent
58f9702e39
commit
acf3efe58d
@ -353,7 +353,28 @@ SkillSelector.select(ActionPlan) → SkillSequence
|
|||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 9. 리스크 및 추가 고려사항
|
## 9. DB/베이지안 방법 통합 방안
|
||||||
|
|
||||||
|
### 9.1 문제
|
||||||
|
|
||||||
|
5가지 TDD 시나리오 테스트 결과 시나리오 2~5가 미비:
|
||||||
|
- 시나리오 2: 미구현 의도 처리 - clarify 없음
|
||||||
|
- 시나리오 3: 복합 의도 처리 - 단일 액션만 생성
|
||||||
|
- 시나리오 4: 맥락 기반 의도 파악 - UNKNOWN 분류
|
||||||
|
- 시나리오 5: 모호한 의도 명확화 - clarify 없음
|
||||||
|
|
||||||
|
### 9.2 해결 방안
|
||||||
|
|
||||||
|
기존 DB/베이지안 방법(`intent_prototypes`, `intent_thresholds`, `intent_path_stats`)을 3단계 아키텍처에 통합:
|
||||||
|
- **IntentAnalyzer**: `SemanticIntentClassifier` 재사용, 임베딩 기반 후보 축소
|
||||||
|
- **ActionPlanner**: `intent_path_stats`의 Beta(α,β)로 액션 우선순위 조정, 복합 의도 파싱
|
||||||
|
- **SkillSelector**: 스킬별 실행 성공률 추적, 미구현 스킬 감지
|
||||||
|
|
||||||
|
**상세 내용**: `251126_intent_3step_db_bayesian_integration.md` 참고
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 10. 리스크 및 추가 고려사항
|
||||||
|
|
||||||
- **회귀 및 승인/컨펌 흐름 붕괴 리스크**
|
- **회귀 및 승인/컨펌 흐름 붕괴 리스크**
|
||||||
- 기존 DecisionEngine이 암묵적으로 처리하던 승인/취소/컨펌, 예외 케이스들이 IntentGoal → ActionPlan → SkillSequence 분리 과정에서 깨질 수 있음 (예: 같은 입력인데 캘린더/이메일 오작동).
|
- 기존 DecisionEngine이 암묵적으로 처리하던 승인/취소/컨펌, 예외 케이스들이 IntentGoal → ActionPlan → SkillSequence 분리 과정에서 깨질 수 있음 (예: 같은 입력인데 캘린더/이메일 오작동).
|
||||||
|
|||||||
@ -0,0 +1,165 @@
|
|||||||
|
# 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 통합
|
||||||
|
|
||||||
|
**기존 방법 재사용**:
|
||||||
|
```python
|
||||||
|
# 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)
|
||||||
|
```
|
||||||
|
|
||||||
|
**개선 방안**:
|
||||||
|
1. `intent_prototypes` DB로 임베딩 기반 후보 축소 후 LLM 재분석
|
||||||
|
2. 맥락 기반 의도 파악: 최근 대화 컨텍스트와 결합하여 임베딩 유사도 계산
|
||||||
|
3. `intent_thresholds`의 임계값으로 confidence 기반 clarify 판단
|
||||||
|
|
||||||
|
### 3.2 ActionPlanner 통합
|
||||||
|
|
||||||
|
**기존 방법 재사용**:
|
||||||
|
```python
|
||||||
|
# intent_path_stats 테이블에서 경로별 성공률 조회
|
||||||
|
# Beta(α,β) 파라미터로 액션 우선순위 조정
|
||||||
|
```
|
||||||
|
|
||||||
|
**개선 방안**:
|
||||||
|
1. `intent_path_stats`의 Beta(α,β)로 경로별 성공률 기반 액션 우선순위 조정
|
||||||
|
2. 복합 의도 파싱: LLM으로 여러 액션 추출 (SEARCH_WEB → ANALYZE_DOCUMENT → SEND_EMAIL)
|
||||||
|
3. 모호한 의도 감지: confidence 낮을 때 `requires_clarification=True` 설정
|
||||||
|
|
||||||
|
### 3.3 SkillSelector 통합
|
||||||
|
|
||||||
|
**기존 방법 재사용**:
|
||||||
|
```python
|
||||||
|
# 스킬별 실행 성공률을 DB에 추적
|
||||||
|
# intent_path_stats 또는 별도 skill_stats 테이블 활용
|
||||||
|
```
|
||||||
|
|
||||||
|
**개선 방안**:
|
||||||
|
1. 스킬별 실행 성공률을 DB에 추적해 동적 스킬 선택 최적화
|
||||||
|
2. 미구현 스킬 감지: 스킬 존재 여부 확인 후 없으면 clarify 반환
|
||||||
|
3. 스킬 효율성 계산: 기존 `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일)
|
||||||
|
|
||||||
|
1. `SemanticIntentClassifier` 인스턴스 생성 및 재사용
|
||||||
|
2. `intent_prototypes` DB 활용한 임베딩 기반 후보 축소
|
||||||
|
3. 맥락 기반 의도 파악 로직 추가
|
||||||
|
|
||||||
|
### 5.2 Phase 2: ActionPlanner 통합 (1일)
|
||||||
|
|
||||||
|
1. `intent_path_stats` 조회 로직 추가
|
||||||
|
2. 복합 의도 파싱 로직 추가 (LLM 활용)
|
||||||
|
3. 모호한 의도 감지 및 clarify 로직 추가
|
||||||
|
|
||||||
|
### 5.3 Phase 3: SkillSelector 통합 (1일)
|
||||||
|
|
||||||
|
1. 스킬 존재 여부 확인 로직 추가
|
||||||
|
2. 스킬별 실행 성공률 추적 로직 추가
|
||||||
|
3. 동적 스킬 선택 최적화 로직 추가
|
||||||
|
|
||||||
|
### 5.4 Phase 4: 테스트 및 검증 (1일)
|
||||||
|
|
||||||
|
1. 5가지 시나리오 재테스트
|
||||||
|
2. 성능 측정 (정확도, 지연시간, 비용)
|
||||||
|
3. DB 데이터 모니터링
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 6. 리스크 및 완화
|
||||||
|
|
||||||
|
- **DB 의존성**: DB 연결 실패 시 폴백 로직 필수
|
||||||
|
- **성능 영향**: 임베딩/DB 조회 추가로 인한 지연시간 증가 가능 → 캐싱 고려
|
||||||
|
- **데이터 품질**: `intent_prototypes` 데이터 부족 시 성능 저하 → 시드 데이터 확보
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
**작성 완료**: 2025-11-26
|
||||||
|
**다음 단계**: Phase 1 구현 시작
|
||||||
|
|
||||||
Loading…
x
Reference in New Issue
Block a user