docs: 감정 Phase 3-2 완료 처리, 4-5 장기 분리, 완료 아이디어 삭제, 315 테스트원칙
Co-authored-by: Cursor <cursoragent@cursor.com>
This commit is contained in:
Claude-51124
parent
3ec28464f4
commit
640eacdf55
@ -13,7 +13,7 @@ Part 2에서 우리는 게임 메커니즘을 활용한 설계를 소개했습
|
|||||||
- 311_FastAPI_구조_원칙.md
|
- 311_FastAPI_구조_원칙.md
|
||||||
- 312_문서_작성_원칙.md
|
- 312_문서_작성_원칙.md
|
||||||
- 313_React_구조_원칙.md
|
- 313_React_구조_원칙.md
|
||||||
- 315_테스트_작성_원칙.md
|
- 315_테스트_원칙.md
|
||||||
- 320_Slack_기반_인터페이스_설계.md
|
- 320_Slack_기반_인터페이스_설계.md
|
||||||
- 330_백엔드_PostgreSQL_ChromaDB_Vector_Memory.md
|
- 330_백엔드_PostgreSQL_ChromaDB_Vector_Memory.md
|
||||||
- 340_GUI_공유_아키텍처_레벨기반_권한.md
|
- 340_GUI_공유_아키텍처_레벨기반_권한.md
|
||||||
|
|||||||
@ -374,6 +374,7 @@ utils
|
|||||||
|
|
||||||
## 18. 테스트 원칙
|
## 18. 테스트 원칙
|
||||||
|
|
||||||
|
- **TDD 진행**: 테스트는 TDD로 진행. 상세: `315_테스트_원칙.md`
|
||||||
- **실제 테스트 필수**: 코드 수정 후 추측하지 말고 실제로 테스트 (curl, Slack 직접 사용, DB 조회)
|
- **실제 테스트 필수**: 코드 수정 후 추측하지 말고 실제로 테스트 (curl, Slack 직접 사용, DB 조회)
|
||||||
- **컨테이너 테스트 파일 반영**: tests 디렉토리는 볼륨 마운트 아님 (빌드 시 COPY). 새 테스트 파일 추가 시 `docker cp [파일경로] [컨테이너명]:/code/tests/` 사용 또는 컨테이너 재빌드
|
- **컨테이너 테스트 파일 반영**: tests 디렉토리는 볼륨 마운트 아님 (빌드 시 COPY). 새 테스트 파일 추가 시 `docker cp [파일경로] [컨테이너명]:/code/tests/` 사용 또는 컨테이너 재빌드
|
||||||
|
|
||||||
|
|||||||
@ -1,12 +1,23 @@
|
|||||||
# 테스트 작성 원칙
|
# 테스트 원칙
|
||||||
|
|
||||||
**작성일**: 2025-01-03
|
**작성일**: 2025-01-03
|
||||||
**참고**: 311_FastAPI_구조_원칙.md, 312_문서_작성_원칙.md
|
**수정일**: 2026-02-05 (테스트 원칙으로 변경, TDD 원칙 추가)
|
||||||
|
**참고**: 311_백엔드_구조_원칙.md, 312_문서_작성_원칙.md
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 1. 핵심 원칙
|
## 1. 핵심 원칙
|
||||||
|
|
||||||
|
### TDD 원칙
|
||||||
|
|
||||||
|
**테스트는 TDD로 진행한다.**
|
||||||
|
|
||||||
|
- **Red**: 테스트 먼저 작성 (기대 행동을 테스트에 명시)
|
||||||
|
- **Green**: 최소 구현으로 테스트 통과
|
||||||
|
- **Refactor**: 리팩터링 후 테스트 재실행
|
||||||
|
|
||||||
|
DecisionEngine, intent, 캘린더 로직 등은 항상 테스트에서 기대 행동을 확정한 뒤 수정한다.
|
||||||
|
|
||||||
### 테스트 코드 재작성 비효율 방지
|
### 테스트 코드 재작성 비효율 방지
|
||||||
|
|
||||||
**목표**: 테스트 코드를 매번 재작성하지 않고 재사용 가능하게 관리
|
**목표**: 테스트 코드를 매번 재작성하지 않고 재사용 가능하게 관리
|
||||||
@ -171,6 +182,7 @@ docker compose down && docker compose up -d --build
|
|||||||
|
|
||||||
### 테스트 작성 전
|
### 테스트 작성 전
|
||||||
|
|
||||||
|
- [ ] TDD 순서 준수 (Red → Green → Refactor)
|
||||||
- [ ] 동일한 테스트 로직이 이미 존재하는가? (섹션 3 재사용성 확인)
|
- [ ] 동일한 테스트 로직이 이미 존재하는가? (섹션 3 재사용성 확인)
|
||||||
- [ ] 공통 모킹/데이터가 있다면 `conftest.py`에 추가할 수 있는가? (섹션 3)
|
- [ ] 공통 모킹/데이터가 있다면 `conftest.py`에 추가할 수 있는가? (섹션 3)
|
||||||
- [ ] pytest 자동 테스트인가? (섹션 6 기준 확인)
|
- [ ] pytest 자동 테스트인가? (섹션 6 기준 확인)
|
||||||
@ -206,7 +218,6 @@ docker compose down && docker compose up -d --build
|
|||||||
|
|
||||||
## 10. 참고
|
## 10. 참고
|
||||||
|
|
||||||
- FastAPI 구조 원칙: `311_FastAPI_구조_원칙.md` 섹션 18 (테스트 원칙)
|
- FastAPI 구조 원칙: `311_백엔드_구조_원칙.md` 섹션 18 (테스트 원칙)
|
||||||
- 문서 작성 원칙: `312_문서_작성_원칙.md` (troubleshooting 기록 방법)
|
- 문서 작성 원칙: `312_문서_작성_원칙.md` (troubleshooting 기록 방법)
|
||||||
- 트러블슈팅: `journey/troubleshooting/251110_레거시_테스트_폴더_정리.md`
|
- 트러블슈팅: `journey/troubleshooting/251110_레거시_테스트_폴더_정리.md`
|
||||||
|
|
||||||
@ -1,106 +0,0 @@
|
|||||||
# rb10508 → rb8001 이식 가이드
|
|
||||||
|
|
||||||
## 작성일: 2025-08-28
|
|
||||||
## 작성자: 서버 관리자
|
|
||||||
## 목적: rb10508의 검증된 기능을 rb8001에 선택적 이식
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 현재 상태 비교
|
|
||||||
|
|
||||||
### 메모리 사용량
|
|
||||||
- **rb8001**: 145MB (이미 경량화, skill-embedding 사용)
|
|
||||||
- **rb10508**: 136MB (동일하게 skill-embedding 사용)
|
|
||||||
- **결론**: 둘 다 이미 최적화됨, 메모리는 이식 대상 아님
|
|
||||||
|
|
||||||
### ChromaDB 버전
|
|
||||||
- **rb8001**: v0.5.20 (구버전, 984KB)
|
|
||||||
- **rb10508**: v1.0.16 (최신)
|
|
||||||
- **이식 필요**: ✅ 업그레이드 권장
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 핵심 이식 대상 (우선순위)
|
|
||||||
|
|
||||||
### 1. 🔥 메모리 알고리즘 개선 (즉시 가능)
|
|
||||||
```python
|
|
||||||
# rb10508의 고급 알고리즘
|
|
||||||
- add_composite_scores(): 복합 점수 계산
|
|
||||||
- maximal_marginal_relevance(): 다양성 확보 + 중복 제거
|
|
||||||
|
|
||||||
# rb8001 현재
|
|
||||||
- 단순 유사도 검색만 사용
|
|
||||||
```
|
|
||||||
**이식 방법**: `/app/memory/scoring.py` 함수만 복사
|
|
||||||
|
|
||||||
### 2. 📁 다중 컬렉션 구조 (중요)
|
|
||||||
```python
|
|
||||||
# rb10508: 메모리 타입별 분류
|
|
||||||
- episodic_memory # 대화 이벤트
|
|
||||||
- semantic_memory # 개념/지식
|
|
||||||
- procedural_memory # 작업 방법
|
|
||||||
|
|
||||||
# rb8001: 단일 컬렉션만 사용
|
|
||||||
```
|
|
||||||
**이식 방법**: ChromaDB 마이그레이션 필요
|
|
||||||
|
|
||||||
### 3. 🎮 Gmail 아이템 권한 체크 (높음)
|
|
||||||
```python
|
|
||||||
# rb10508: growth.py 시스템
|
|
||||||
async def check_item_equipped(user_id, "gmail"):
|
|
||||||
# 스킬 호출 전 권한 확인
|
|
||||||
if not is_equipped:
|
|
||||||
return "Gmail을 먼저 연결해주세요!"
|
|
||||||
|
|
||||||
# rb8001: 체크 없이 바로 호출 → 에러 발생
|
|
||||||
```
|
|
||||||
**이식 방법**: `/app/core/growth.py` 추가
|
|
||||||
|
|
||||||
### 4. 👤 사용자별 메모리 격리 (필수)
|
|
||||||
```python
|
|
||||||
# rb10508: 사용자별 독립 컬렉션
|
|
||||||
f"{robeing_id}_{user_id}_episodic"
|
|
||||||
|
|
||||||
# rb8001: 기본 컬렉션 공유 문제
|
|
||||||
```
|
|
||||||
**이식 방법**: 컬렉션 명명 규칙 변경
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 구현 상태 vs 설계
|
|
||||||
|
|
||||||
| 모듈 | rb8001 | rb10508 | 실제 구현 여부 | 이식 가치 |
|
|
||||||
|------|--------|---------|--------------|-----------|
|
|
||||||
| **MMR 알고리즘** | ❌ | ✅ | 구현 완료 | ⭐⭐⭐⭐⭐ |
|
|
||||||
| **다중 컬렉션** | ❌ | ✅ | 구현 완료 | ⭐⭐⭐⭐ |
|
|
||||||
| **아이템 체크** | ❌ | ✅ | 구현 완료 | ⭐⭐⭐⭐ |
|
|
||||||
| **베이지안 메모리** | ❌ | 부분 | 부분 구현 | ⭐⭐⭐ |
|
|
||||||
| **Langchain** | ❌ | ✅ | 구현 완료 | ⭐⭐⭐ |
|
|
||||||
| **감정 시스템** | ❌ | 임시 | 미구현 | ⭐ |
|
|
||||||
| **윤리 필터** | ❌ | 빈 파일 | 미구현 | ⭐ |
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 단계별 이식 계획
|
|
||||||
|
|
||||||
### Phase 1 (즉시)
|
|
||||||
1. MMR 알고리즘 함수 복사
|
|
||||||
2. composite_scores 추가
|
|
||||||
3. 테스트 및 검증
|
|
||||||
|
|
||||||
### Phase 2 (1주)
|
|
||||||
1. ChromaDB 1.0 업그레이드
|
|
||||||
2. 다중 컬렉션 마이그레이션
|
|
||||||
3. 사용자별 격리 구현
|
|
||||||
|
|
||||||
### Phase 3 (2주)
|
|
||||||
1. growth.py 아이템 시스템
|
|
||||||
2. Gmail 권한 체크 미들웨어
|
|
||||||
3. 스킬 호출 전 검증 로직
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 주의사항
|
|
||||||
- 감정/윤리 모듈은 설계만 존재, 실제 구현 없음
|
|
||||||
- Stats 시스템은 rb8001이 더 완성도 높음 (유지)
|
|
||||||
- 이미 둘 다 skill-embedding 사용 중 (메모리 최적화 완료)
|
|
||||||
@ -1,253 +0,0 @@
|
|||||||
# NAVER WORKS 연동 시나리오
|
|
||||||
|
|
||||||
**작성일**: 2025-09-17
|
|
||||||
**작성자**: happybell80
|
|
||||||
**상태**: 시나리오 설계 중
|
|
||||||
|
|
||||||
## 1. Slack에서 NAVER WORKS 메일 요약 받기
|
|
||||||
|
|
||||||
### 시나리오
|
|
||||||
사용자가 Slack에서 "@로빙 네이버웍스 메일 확인해줘"라고 요청하면, 로빙이 NAVER WORKS 메일을 조회하고 요약해서 Slack으로 전달
|
|
||||||
|
|
||||||
### 전제 조건
|
|
||||||
- auth-server에 NAVER WORKS OAuth 구현 완료
|
|
||||||
- skill-naverworks 서비스 구현 완료 (포트 8511)
|
|
||||||
- Service Account 인증 설정 완료
|
|
||||||
- Slack workspace 연동 완료
|
|
||||||
|
|
||||||
### 상세 플로우
|
|
||||||
```
|
|
||||||
1. Slack 메시지 수신
|
|
||||||
Slack → /slack/events/router → rb8001
|
|
||||||
메시지: "@로빙 네이버웍스 메일 확인해줘"
|
|
||||||
|
|
||||||
2. 의도 파악 및 라우팅
|
|
||||||
rb8001 → 키워드 분석 ("네이버웍스", "메일")
|
|
||||||
→ skill-naverworks 호출 결정
|
|
||||||
|
|
||||||
3. NAVER WORKS API 호출
|
|
||||||
rb8001 → POST skill-naverworks:8511/mail/summary
|
|
||||||
→ Service Account Token 사용
|
|
||||||
→ GET https://www.worksapis.com/v1.0/users/{userId}/mail/mailfolders/0/children
|
|
||||||
|
|
||||||
4. 메일 내용 처리
|
|
||||||
skill-naverworks → 메일 목록 조회
|
|
||||||
→ 최근 메일 5개 추출
|
|
||||||
→ Gemini API로 요약 생성
|
|
||||||
|
|
||||||
5. Slack 응답
|
|
||||||
skill-naverworks → rb8001 → skill-slack
|
|
||||||
→ POST /slack/send_message
|
|
||||||
→ 채널에 요약 포스팅
|
|
||||||
```
|
|
||||||
|
|
||||||
### 구현 필요 사항
|
|
||||||
- [ ] skill-naverworks 서비스 생성
|
|
||||||
- [ ] NAVER WORKS Mail API 래퍼 구현
|
|
||||||
- [ ] rb8001 스킬 라우팅 로직 추가
|
|
||||||
- [ ] 사용자 매핑 (Slack user_id ↔ NAVER WORKS userId)
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 2. 콜드메일을 Slack 캔버스에 자동 포스팅
|
|
||||||
|
|
||||||
### 시나리오
|
|
||||||
NAVER WORKS에 도착한 신규 영업 메일(콜드메일)을 자동으로 감지하고, Slack 캔버스에 정리된 형태로 포스팅
|
|
||||||
|
|
||||||
### 상세 플로우
|
|
||||||
```
|
|
||||||
1. 메일 모니터링 (30분 주기)
|
|
||||||
skill-naverworks → Cron job/스케줄러
|
|
||||||
→ GET /users/{userId}/mail/mailfolders/0/children?limit=10
|
|
||||||
|
|
||||||
2. 콜드메일 필터링
|
|
||||||
- 발신자가 주소록에 없음
|
|
||||||
- 제목에 특정 키워드 포함 ("제안", "협력", "서비스")
|
|
||||||
- 첨부파일 있음 (회사소개서 등)
|
|
||||||
|
|
||||||
3. 콜드메일 분석
|
|
||||||
skill-naverworks → Gemini API
|
|
||||||
- 회사명 추출
|
|
||||||
- 제안 내용 요약
|
|
||||||
- 연락처 정보 추출
|
|
||||||
- 중요도 판단
|
|
||||||
|
|
||||||
4. Slack Canvas 생성/업데이트
|
|
||||||
skill-slack → POST /canvases.create 또는 /canvases.edit
|
|
||||||
템플릿:
|
|
||||||
```
|
|
||||||
## 신규 영업 제안 - {날짜}
|
|
||||||
|
|
||||||
### {회사명}
|
|
||||||
- 담당자: {이름}
|
|
||||||
- 연락처: {이메일/전화}
|
|
||||||
- 제안 요약: {요약}
|
|
||||||
- 첨부파일: {파일명}
|
|
||||||
- 우선순위: {높음/중간/낮음}
|
|
||||||
```
|
|
||||||
|
|
||||||
5. 알림 전송
|
|
||||||
skill-slack → 영업팀 채널에 캔버스 링크 공유
|
|
||||||
```
|
|
||||||
|
|
||||||
### 구현 필요 사항
|
|
||||||
- [ ] 메일 모니터링 스케줄러
|
|
||||||
- [ ] 콜드메일 판별 로직
|
|
||||||
- [ ] Slack Canvas API 통합
|
|
||||||
- [ ] 템플릿 관리 시스템
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 3. 아침 메일 브리핑
|
|
||||||
|
|
||||||
### 시나리오
|
|
||||||
매일 오전 9시에 전날 받은 중요 메일을 요약해서 Slack DM으로 전송
|
|
||||||
|
|
||||||
### 상세 플로우
|
|
||||||
```
|
|
||||||
1. 스케줄 트리거 (매일 09:00)
|
|
||||||
robeing-gateway → scheduled_tasks 테이블
|
|
||||||
→ trigger skill-naverworks
|
|
||||||
|
|
||||||
2. 메일 수집
|
|
||||||
skill-naverworks → NAVER WORKS API
|
|
||||||
- 지난 24시간 메일 조회
|
|
||||||
- 중요도 표시된 메일 우선
|
|
||||||
- 미읽은 메일 포함
|
|
||||||
|
|
||||||
3. 카테고리별 분류
|
|
||||||
- 내부 메일 (company-x.partners 도메인)
|
|
||||||
- 고객사 메일
|
|
||||||
- 외부 제안
|
|
||||||
- 시스템 알림
|
|
||||||
|
|
||||||
4. 요약 생성
|
|
||||||
Gemini API → 카테고리별 요약
|
|
||||||
```
|
|
||||||
📧 오늘의 메일 브리핑 (11월 17일)
|
|
||||||
|
|
||||||
✅ 긴급 대응 필요 (2건)
|
|
||||||
- [고객A] 프로젝트 일정 문의
|
|
||||||
- [내부] 오늘 오후 2시 회의 참석 요청
|
|
||||||
|
|
||||||
📌 확인 필요 (5건)
|
|
||||||
- [영업] 신규 제안서 3건
|
|
||||||
- [지원팀] 시스템 점검 공지
|
|
||||||
- [고객B] 추가 기능 요청
|
|
||||||
```
|
|
||||||
|
|
||||||
5. 개인별 DM 전송
|
|
||||||
skill-slack → 각 사용자 DM
|
|
||||||
→ 읽음 확인 버튼 포함
|
|
||||||
```
|
|
||||||
|
|
||||||
### 구현 필요 사항
|
|
||||||
- [ ] 스케줄러 시스템 구현
|
|
||||||
- [ ] 사용자별 설정 관리 (시간, 카테고리)
|
|
||||||
- [ ] 메일 중요도 판별 AI
|
|
||||||
- [ ] DM 템플릿 시스템
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 4. 캘린더 일정 → Slack 리마인더
|
|
||||||
|
|
||||||
### 시나리오
|
|
||||||
NAVER WORKS 캘린더의 일정을 Slack 리마인더로 자동 동기화
|
|
||||||
|
|
||||||
### 상세 플로우
|
|
||||||
```
|
|
||||||
1. 캘린더 이벤트 감지
|
|
||||||
skill-naverworks → GET /users/{userId}/calendar/events
|
|
||||||
→ 향후 24시간 내 일정 조회
|
|
||||||
|
|
||||||
2. Slack 리마인더 생성
|
|
||||||
skill-slack → /reminders.add
|
|
||||||
- 회의 15분 전 알림
|
|
||||||
- 참석자 멘션 포함
|
|
||||||
- 회의 링크 포함
|
|
||||||
|
|
||||||
3. 일정 변경 감지
|
|
||||||
- 30분마다 캘린더 동기화
|
|
||||||
- 변경된 일정 업데이트
|
|
||||||
- 취소된 일정 리마인더 삭제
|
|
||||||
```
|
|
||||||
|
|
||||||
### 구현 필요 사항
|
|
||||||
- [ ] Calendar API 통합
|
|
||||||
- [ ] Slack Reminders API 통합
|
|
||||||
- [ ] 동기화 충돌 해결 로직
|
|
||||||
- [ ] 사용자별 동기화 설정
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 5. 메일 자동 분류 및 태깅
|
|
||||||
|
|
||||||
### 시나리오
|
|
||||||
받은 메일을 AI로 분석해서 자동으로 태그를 붙이고 Slack 채널에 분류해서 전달
|
|
||||||
|
|
||||||
### 카테고리 및 채널 매핑
|
|
||||||
```
|
|
||||||
- 계약/법무 → #legal 채널
|
|
||||||
- 인보이스/청구 → #finance 채널
|
|
||||||
- 고객 문의 → #customer-support 채널
|
|
||||||
- 제품 피드백 → #product 채널
|
|
||||||
- 채용 관련 → #recruiting 채널
|
|
||||||
```
|
|
||||||
|
|
||||||
### 구현 필요 사항
|
|
||||||
- [ ] 메일 분류 ML 모델
|
|
||||||
- [ ] 태그 시스템 구현
|
|
||||||
- [ ] 채널별 포스팅 규칙
|
|
||||||
- [ ] 오분류 피드백 시스템
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 6. 구현 우선순위
|
|
||||||
|
|
||||||
1. **Phase 1** (기본 인프라)
|
|
||||||
- auth-server NAVER WORKS OAuth
|
|
||||||
- skill-naverworks 기본 구조
|
|
||||||
- Service Account 인증
|
|
||||||
|
|
||||||
2. **Phase 2** (핵심 기능)
|
|
||||||
- 메일 조회 API
|
|
||||||
- Slack 메시지 응답
|
|
||||||
- 기본 요약 기능
|
|
||||||
|
|
||||||
3. **Phase 3** (자동화)
|
|
||||||
- 스케줄러 시스템
|
|
||||||
- 아침 브리핑
|
|
||||||
- 콜드메일 감지
|
|
||||||
|
|
||||||
4. **Phase 4** (고급 기능)
|
|
||||||
- Canvas 통합
|
|
||||||
- 캘린더 동기화
|
|
||||||
- AI 분류 시스템
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 7. 기술적 고려사항
|
|
||||||
|
|
||||||
### API Rate Limit
|
|
||||||
- NAVER WORKS API 호출 제한 확인 필요
|
|
||||||
- 캐싱 전략 수립
|
|
||||||
- 배치 처리 구현
|
|
||||||
|
|
||||||
### 사용자 매핑
|
|
||||||
- Slack user_id ↔ NAVER WORKS userId 매핑 테이블
|
|
||||||
- 이메일 기반 자동 매핑
|
|
||||||
- 수동 연결 UI 제공
|
|
||||||
|
|
||||||
### 보안
|
|
||||||
- Service Account 권한 최소화
|
|
||||||
- 메일 내용 암호화 저장
|
|
||||||
- 접근 로그 기록
|
|
||||||
|
|
||||||
### 성능
|
|
||||||
- 비동기 처리 필수
|
|
||||||
- Redis 캐싱 활용
|
|
||||||
- 큐 시스템 도입 검토
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
*지속적으로 시나리오 추가 예정*
|
|
||||||
@ -1,87 +0,0 @@
|
|||||||
---
|
|
||||||
date: 2025-09-29
|
|
||||||
author: happybell80
|
|
||||||
tags: [ai, cli, integration, automation, wsl, tmux, broadcast]
|
|
||||||
status: completed
|
|
||||||
---
|
|
||||||
|
|
||||||
# Multi-AI CLI 통합 시스템 (WSL/tmux 완성)
|
|
||||||
|
|
||||||
## 개요
|
|
||||||
- WSL tmux 기반 6개 AI 동시 브로드캐스트 시스템
|
|
||||||
- Windows pywinauto 방식 포기, WSL tmux로 전환
|
|
||||||
- 2025-09-29 구현 완료
|
|
||||||
|
|
||||||
## 최종 구조
|
|
||||||
```
|
|
||||||
/home/happybell/projects/ivada/multi-ai-cli-wsl/
|
|
||||||
├── run.py # 메인 진입점
|
|
||||||
├── src/
|
|
||||||
│ └── controller.py # SimpleController 클래스
|
|
||||||
├── bin/
|
|
||||||
│ ├── tmux_setup.sh # tmux 세션 생성 (2×3 그리드)
|
|
||||||
│ └── restart_tmux.sh # 세션 재시작
|
|
||||||
├── config/
|
|
||||||
│ └── config.yaml # AI 설정
|
|
||||||
└── logs/ # pipe-pane 로그 저장
|
|
||||||
```
|
|
||||||
|
|
||||||
## 구현 내용
|
|
||||||
|
|
||||||
### tmux 세션 (bin/tmux_setup.sh)
|
|
||||||
- 2×3 그리드 6개 pane 생성
|
|
||||||
- 마우스 지원 활성화 (mouse on)
|
|
||||||
- 스크롤백 10000줄
|
|
||||||
- pane 경계선 강조 (colour51 for active)
|
|
||||||
- pipe-pane으로 각 pane 로그 자동 저장
|
|
||||||
|
|
||||||
### 컨트롤러 (src/controller.py)
|
|
||||||
- tmux send-keys로 브로드캐스트
|
|
||||||
- 메시지와 'C-m' 분리 전송 (Enter 키 이슈 해결)
|
|
||||||
- 6개 AI 기본 활성화
|
|
||||||
- 직접 입력 질문, /명령어 구분
|
|
||||||
|
|
||||||
### 설정 (config/config.yaml)
|
|
||||||
```yaml
|
|
||||||
session: ai-panel
|
|
||||||
panes:
|
|
||||||
claude_51123: "ai-panel:0.0"
|
|
||||||
gemini_local: "ai-panel:0.1"
|
|
||||||
claude_51124: "ai-panel:0.2"
|
|
||||||
codex_local: "ai-panel:0.3"
|
|
||||||
claude_local: "ai-panel:0.4"
|
|
||||||
openai_local: "ai-panel:0.5"
|
|
||||||
commands: # 모두 비움 (대화형 모드)
|
|
||||||
claude_51123: ""
|
|
||||||
gemini_local: ""
|
|
||||||
```
|
|
||||||
|
|
||||||
## 실행 방법
|
|
||||||
```bash
|
|
||||||
# tmux 세션 시작
|
|
||||||
restart_tmux.sh
|
|
||||||
|
|
||||||
# 각 pane에서 AI 수동 실행
|
|
||||||
# Pane 0: ssh -p 51123 admin@ro-being.com → claude
|
|
||||||
# Pane 1: gemini
|
|
||||||
# Pane 2: ssh -p 51124 admin@ro-being.com → claude
|
|
||||||
# Pane 3: codex
|
|
||||||
# Pane 4: claude
|
|
||||||
# Pane 5: 예비
|
|
||||||
|
|
||||||
# 별도 터미널에서 컨트롤러
|
|
||||||
cd ~/projects/ivada/multi-ai-cli-wsl
|
|
||||||
uv run python run.py
|
|
||||||
```
|
|
||||||
|
|
||||||
## 해결한 이슈
|
|
||||||
1. tmux send-keys 'Enter' 안됨 → 'C-m' 분리 전송
|
|
||||||
2. 창 분할 오류 → tiled 레이아웃 사용
|
|
||||||
3. Windows line ending → sed 제거
|
|
||||||
4. 명령 템플릿 오류 → 비움 (raw text)
|
|
||||||
5. 스크롤/복사 충돌 → Shift+드래그
|
|
||||||
|
|
||||||
## 제한사항
|
|
||||||
- AI 로그인은 수동
|
|
||||||
- 응답 파싱/비교 미구현
|
|
||||||
- Gemini C-u 처리 미구현
|
|
||||||
@ -1,9 +0,0 @@
|
|||||||
# 동남아 스타트업 뉴스 제공 (아이디어 → 계획 이동)
|
|
||||||
|
|
||||||
**작성일**: 2026-01-25
|
|
||||||
**작성자**: happybell80
|
|
||||||
|
|
||||||
→ **계획 문서 (완료·아카이브)**: [plans/archive/260129_동남아_스타트업_뉴스_아침브리핑.md](../plans/archive/260129_동남아_스타트업_뉴스_아침브리핑.md)
|
|
||||||
|
|
||||||
- UX: 매일 아침 뉴스에 「동남아 소식」 3개 꼭지, 컴퍼니엑스 기회 탐색용.
|
|
||||||
- UI: 깡프로 뉴스처럼 `01. <url|제목>` 형식, daily_headlines 메시지 내 섹션 추가.
|
|
||||||
@ -1,48 +0,0 @@
|
|||||||
# 로빙 감정 시스템 5단계 로드맵
|
|
||||||
|
|
||||||
**작성일**: 2025-08-08
|
|
||||||
**목적**: 7개 감정 모델 → 32개 감정 + 온톨로지 점진 확장
|
|
||||||
**상태**: Phase 1-2 완료, Phase 3 부분 완료, Phase 4-5 미구현
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Phase 1: 7개 기본 감정 (✅ 완료)
|
|
||||||
|
|
||||||
→ 상세: `troubleshooting/250815_emotion_model_training.md`
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Phase 2: 엔트로피 기반 복잡도 (✅ 완료)
|
|
||||||
|
|
||||||
→ 상세: `troubleshooting/251016_emotion_entropy_integration.md`
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 남은 작업
|
|
||||||
|
|
||||||
### Phase 3: 감정 온톨로지 (부분 완료)
|
|
||||||
- **완료**: `troubleshooting/251016_emotion_ontology_basic.md` 참조
|
|
||||||
- **미구현**:
|
|
||||||
- 감정 기반 응답 톤 조정 (현재 LLM에만 의존)
|
|
||||||
- 감정 기록 및 패턴 분석 DB
|
|
||||||
|
|
||||||
### Phase 4: 32개 세밀 감정 (미구현)
|
|
||||||
- **목표**: Plutchik 감정 휠 기반 32개 감정
|
|
||||||
- **필요 작업**:
|
|
||||||
1. AI Hub 데이터 재라벨링 (7 → 32개)
|
|
||||||
2. 모델 재학습 (다중 레이블 분류)
|
|
||||||
3. skill-embedding API 확장
|
|
||||||
- **예상 기간**: 2-3개월
|
|
||||||
|
|
||||||
### Phase 5: 감정 기억 시스템 (미구현)
|
|
||||||
- **설계**: Neo4j에 감정 노드 저장, 시간별 감정 변화 추적, 패턴 분석
|
|
||||||
- **예상 기간**: 1개월
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 참고
|
|
||||||
|
|
||||||
- `book/200_core_design/225_온톨로지_기반_지식_표현.md`
|
|
||||||
- `troubleshooting/250815_emotion_model_training.md`
|
|
||||||
- `troubleshooting/251016_emotion_ontology_basic.md`
|
|
||||||
- `troubleshooting/251016_emotion_entropy_integration.md`
|
|
||||||
@ -4,6 +4,11 @@
|
|||||||
**목표**: 임베딩 한계(파인티처 메일 누락)를 온톨로지 추론으로 해결
|
**목표**: 임베딩 한계(파인티처 메일 누락)를 온톨로지 추론으로 해결
|
||||||
**상태**: Phase 1-1.5 완료, Phase 2-3 미구현
|
**상태**: Phase 1-1.5 완료, Phase 2-3 미구현
|
||||||
|
|
||||||
|
**원칙 참조** (구현 전 필수 확인):
|
||||||
|
- `311_백엔드_구조_원칙.md`: 계층 분리, DB는 state 경유
|
||||||
|
- `312_문서_작성_원칙.md`: 핵심만 간결, 파일명:줄번호
|
||||||
|
- `315_테스트_원칙.md`: 테스트는 TDD로 진행 (Red → Green → Refactor)
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## Phase 1: Coldmail 온톨로지 (✅ 완료)
|
## Phase 1: Coldmail 온톨로지 (✅ 완료)
|
||||||
@ -20,14 +25,16 @@
|
|||||||
|
|
||||||
## 남은 작업
|
## 남은 작업
|
||||||
|
|
||||||
### Phase 2-3: Neo4j 기억 시스템 및 감정-기억-윤리
|
### Phase 2-3: Neo4j 기억 시스템 및 감정-기억-윤리 (TDD 진행)
|
||||||
- **참고**: `ideas/251016_coldmail_ontology_phase2_3_neo4j_emotion.md`
|
- **참고**: `../ideas/251016_coldmail_ontology_phase2_3_neo4j_emotion.md`
|
||||||
- **필요 작업**: Neo4j 기억 시스템, 감정-기억-윤리 삼각형 구현
|
- **필요 작업**: Neo4j 기억 시스템, 감정-기억-윤리 삼각형 구현
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 참고
|
## 참고
|
||||||
|
|
||||||
|
- `book/300_architecture/311_백엔드_구조_원칙.md`
|
||||||
|
- `book/300_architecture/315_테스트_원칙.md`
|
||||||
- `troubleshooting/251014_claude_coldmail_filter_tokenization_issue.md`
|
- `troubleshooting/251014_claude_coldmail_filter_tokenization_issue.md`
|
||||||
- `troubleshooting/251016_ontology_filter_validation.md`
|
- `troubleshooting/251016_ontology_filter_validation.md`
|
||||||
- `troubleshooting/260113_coldmail_ontology_phase1_5_implementation.md`
|
- `troubleshooting/260113_coldmail_ontology_phase1_5_implementation.md`
|
||||||
|
|||||||
@ -4,6 +4,11 @@
|
|||||||
**작성자**: happybell80
|
**작성자**: happybell80
|
||||||
**상태**: 미구현
|
**상태**: 미구현
|
||||||
|
|
||||||
|
**원칙 참조** (구현 전 필수 확인):
|
||||||
|
- `311_백엔드_구조_원칙.md`: 계층 분리, DB는 state 경유, 섹션 6-1 스키마 확인
|
||||||
|
- `312_문서_작성_원칙.md`: 핵심만 간결, 파일명:줄번호
|
||||||
|
- `315_테스트_원칙.md`: 테스트는 TDD로 진행 (Red → Green → Refactor)
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 목표
|
## 목표
|
||||||
@ -39,7 +44,7 @@
|
|||||||
|
|
||||||
## 구현 Phase
|
## 구현 Phase
|
||||||
|
|
||||||
### Phase 1: DB 스키마 및 기본 인프라
|
### Phase 1: DB 스키마 및 기본 인프라 (TDD 진행)
|
||||||
- `rb8001/app/state/repositories/prompt_repository.py` (신규): prompt_templates 테이블 생성, PromptService 클래스 (조회, 병합, 캐싱)
|
- `rb8001/app/state/repositories/prompt_repository.py` (신규): prompt_templates 테이블 생성, PromptService 클래스 (조회, 병합, 캐싱)
|
||||||
- 기본 프롬프트 마이그레이션 (하드코딩 → DB)
|
- 기본 프롬프트 마이그레이션 (하드코딩 → DB)
|
||||||
|
|
||||||
@ -58,7 +63,10 @@
|
|||||||
|
|
||||||
## 참고 문서
|
## 참고 문서
|
||||||
|
|
||||||
- `book/300_architecture/313_Gemini_프롬프트_설계_원칙.md` - Gemini 프롬프트 설계 원칙 (필수 참고)
|
- `book/300_architecture/311_백엔드_구조_원칙.md`
|
||||||
- `ideas/250828_dynamic_system_prompt_memory.md` - 동적 시스템 프롬프트 메모리 시스템
|
- `book/300_architecture/312_문서_작성_원칙.md`
|
||||||
|
- `book/300_architecture/315_테스트_원칙.md`
|
||||||
|
- `book/300_architecture/313_Gemini_프롬프트_설계_원칙.md`
|
||||||
|
- `../ideas/250828_dynamic_system_prompt_memory.md`
|
||||||
- `troubleshooting/250806_happybell80_동적프롬프트구현.md` - 동적 프롬프트 구현 기록
|
- `troubleshooting/250806_happybell80_동적프롬프트구현.md` - 동적 프롬프트 구현 기록
|
||||||
- `book/300_architecture/311_백엔드_구조_원칙.md` - 계층 분리 원칙
|
- `book/300_architecture/311_백엔드_구조_원칙.md` - 계층 분리 원칙
|
||||||
|
|||||||
@ -3,7 +3,10 @@
|
|||||||
**날짜**: 2026-02-02
|
**날짜**: 2026-02-02
|
||||||
**작성자**: Claude
|
**작성자**: Claude
|
||||||
**관련 파일**: `rb8001/app/services/skills/startup_news_skill.py`, `skill_news/app/services/sea_news_collector.py`
|
**관련 파일**: `rb8001/app/services/skills/startup_news_skill.py`, `skill_news/app/services/sea_news_collector.py`
|
||||||
**원칙 참조**: `311_백엔드_구조_원칙.md` (섹션 5: LangGraph 워크플로우)
|
**원칙 참조** (구현 전 필수 확인):
|
||||||
|
- `311_백엔드_구조_원칙.md`: LangGraph 워크플로우 (섹션 5), 계층 분리
|
||||||
|
- `312_문서_작성_원칙.md`: 핵심만 간결, 파일명:줄번호
|
||||||
|
- `315_테스트_원칙.md`: 테스트는 TDD로 진행 (Red → Green → Refactor)
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
@ -19,16 +22,15 @@
|
|||||||
|
|
||||||
### 2.1 상태 모델 (HeadlinesState)
|
### 2.1 상태 모델 (HeadlinesState)
|
||||||
|
|
||||||
```python
|
| 필드 | 타입 | 설명 |
|
||||||
class HeadlinesState(TypedDict):
|
|------|------|------|
|
||||||
channel_id: str
|
| channel_id | str | Slack 채널 ID |
|
||||||
naver_items: List[Dict] # 깡프로 헤드라인
|
| naver_items | List[Dict] | 깡프로 헤드라인 |
|
||||||
sea_items: List[Dict] # 동남아 뉴스
|
| sea_items | List[Dict] | 동남아 뉴스 |
|
||||||
terms: Optional[List[str]] # 추출된 용어
|
| terms | Optional[List[str]] | 추출된 용어 |
|
||||||
formatted_text: str # 최종 Slack 텍스트
|
| formatted_text | str | 최종 Slack 텍스트 |
|
||||||
message_ts: Optional[str] # 전송된 메시지 ts
|
| message_ts | Optional[str] | 전송된 메시지 ts |
|
||||||
errors: List[str] # 각 단계 에러
|
| errors | List[str] | 각 단계 에러 |
|
||||||
```
|
|
||||||
|
|
||||||
### 2.2 노드 구성
|
### 2.2 노드 구성
|
||||||
|
|
||||||
@ -66,7 +68,7 @@ START → fetch_naver → fetch_sea → extract_terms → format → send → EN
|
|||||||
- **기존**: `run_headlines_job()` 함수 → **변경**: LangGraph 워크플로우 호출
|
- **기존**: `run_headlines_job()` 함수 → **변경**: LangGraph 워크플로우 호출
|
||||||
- **로그**: 각 노드별 실행 로그 + 최종 message_ts 로그
|
- **로그**: 각 노드별 실행 로그 + 최종 message_ts 로그
|
||||||
|
|
||||||
### Phase 3: TDD 테스트
|
### Phase 3: 테스트 (TDD 진행, 315_테스트_원칙.md)
|
||||||
- **파일**: `rb8001/tests/test_headlines_workflow.py` (신규)
|
- **파일**: `rb8001/tests/test_headlines_workflow.py` (신규)
|
||||||
- **시나리오**:
|
- **시나리오**:
|
||||||
- 정상 플로우 (깡프로 + 동남아 + 용어)
|
- 정상 플로우 (깡프로 + 동남아 + 용어)
|
||||||
@ -84,5 +86,13 @@ START → fetch_naver → fetch_sea → extract_terms → format → send → EN
|
|||||||
|
|
||||||
- [ ] `headlines_workflow.py` 생성 (LangGraph StateGraph)
|
- [ ] `headlines_workflow.py` 생성 (LangGraph StateGraph)
|
||||||
- [ ] `startup_news_skill.py` 리팩토링 (워크플로우 호출)
|
- [ ] `startup_news_skill.py` 리팩토링 (워크플로우 호출)
|
||||||
- [ ] `test_headlines_workflow.py` 작성 (TDD)
|
- [ ] `test_headlines_workflow.py` 작성 (TDD 진행)
|
||||||
- [ ] 배포 및 스케줄 실행 검증
|
- [ ] 배포 및 스케줄 실행 검증
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 참고
|
||||||
|
|
||||||
|
- `book/300_architecture/311_백엔드_구조_원칙.md`
|
||||||
|
- `book/300_architecture/312_문서_작성_원칙.md`
|
||||||
|
- `book/300_architecture/315_테스트_원칙.md`
|
||||||
|
|||||||
31
journey/plans/260204_감정시스템_장기로드맵_Phase4_5.md
Normal file
31
journey/plans/260204_감정시스템_장기로드맵_Phase4_5.md
Normal file
@ -0,0 +1,31 @@
|
|||||||
|
# 감정 시스템 장기 로드맵 (Phase 4–5)
|
||||||
|
|
||||||
|
**작성일**: 2026-02-04
|
||||||
|
**목적**: 32개 세밀 감정 + Neo4j 감정 기억
|
||||||
|
**상태**: 미구현
|
||||||
|
**기간**: 약 3–4개월
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Phase 4: 32개 세밀 감정 (미구현)
|
||||||
|
|
||||||
|
- **목표**: Plutchik 감정 휠 기반 32개 감정
|
||||||
|
- **필요 작업**:
|
||||||
|
1. AI Hub 데이터 재라벨링 (7 → 32개)
|
||||||
|
2. 모델 재학습 (다중 레이블 분류)
|
||||||
|
3. skill-embedding API 확장
|
||||||
|
- **기간**: 2–3개월
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Phase 5: 감정 기억 시스템 (미구현)
|
||||||
|
|
||||||
|
- **설계**: Neo4j에 감정 노드 저장, 시간별 감정 변화 추적, 패턴 분석
|
||||||
|
- **기간**: 1개월
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 참고
|
||||||
|
|
||||||
|
- `plans/archive/250808_감정시스템_현실적용_5단계_로드맵.md` (Phase 1–3 완료)
|
||||||
|
- `book/200_core_design/225_온톨로지_기반_지식_표현.md`
|
||||||
@ -13,6 +13,7 @@
|
|||||||
4. **뉴스 시스템 (250906)** - 완료 → archive 이동 (E2E 테스트 완료)
|
4. **뉴스 시스템 (250906)** - 완료 → archive 이동 (E2E 테스트 완료)
|
||||||
5. **동남아 스타트업 뉴스 아침브리핑 (260129)** - 완료 → `plans/archive/260129_동남아_스타트업_뉴스_아침브리핑.md`
|
5. **동남아 스타트업 뉴스 아침브리핑 (260129)** - 완료 → `plans/archive/260129_동남아_스타트업_뉴스_아침브리핑.md`
|
||||||
6. **의도 런타임 하이브리드 (251023)** - 전체 완료 (260203) → `plans/archive/251023_happybell80_의도_런타임_하이브리드_임베딩_베이지안_동적학습.md`
|
6. **의도 런타임 하이브리드 (251023)** - 전체 완료 (260203) → `plans/archive/251023_happybell80_의도_런타임_하이브리드_임베딩_베이지안_동적학습.md`
|
||||||
|
7. **감정 시스템 Phase 1–3 (250808)** - 전체 완료 (260204) → `plans/archive/250808_감정시스템_현실적용_5단계_로드맵.md`
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
@ -40,23 +41,15 @@
|
|||||||
- Phase 4: A/B 테스트 및 모니터링
|
- Phase 4: A/B 테스트 및 모니터링
|
||||||
**참고**: `plans/251225_프롬프트_동적관리_계획.md`
|
**참고**: `plans/251225_프롬프트_동적관리_계획.md`
|
||||||
|
|
||||||
### 4. 감정 기록 및 패턴 분석 시스템 (250808 Phase 3)
|
### 4. 감정 기록 및 패턴 분석 시스템 (250808 Phase 1–3)
|
||||||
**상태**: 부분 완료 (Phase 1 완료, Phase 2/3 미구현)
|
**상태**: Phase 1–3 완료, Phase 4–5 장기 계획 분리
|
||||||
**목표**: 감정 패턴 분석 시스템 구축 및 리서치 기반 감정 시스템 확장
|
**완료**:
|
||||||
**필요 작업**:
|
- Phase 1–3: → 상세: `troubleshooting/260204_emotion_phase3_2_implementation.md`
|
||||||
- ✅ Phase 1: 감정 DB 저장 정상화 (완료 - llm_service.py:269에서 save_emotion_to_db 호출 중, emotion_readings 테이블 521건 저장 확인)
|
|
||||||
- Phase 2: 감정 패턴 분석 시스템 (TimescaleDB 2.19.3 기반 시간별 집계, 사용자별 entropy 패턴 분석, 우울증 조기 감지 등) - TDD 방식으로 구현
|
**장기 계획** (Phase 4–5, 약 3–4개월):
|
||||||
- Phase 3: 리서치 기반 감정 시스템 확장
|
- → 상세: `plans/260204_감정시스템_장기로드맵_Phase4_5.md`
|
||||||
- 공감 대화 시스템 강화 (기본 구현 존재, `generate_empathetic_response()` 확장)
|
|
||||||
- Appraisal Theory 적용 (목표/신념 기반 자율적 감정 생성 모듈 신규 개발)
|
**참고**: `plans/archive/250808_감정시스템_현실적용_5단계_로드맵.md`
|
||||||
**예상 기간**: 1-2개월
|
|
||||||
**구현 방식**: TDD (각 Phase를 테스트 가능한 단위로 분리하여 테스트 먼저 작성 후 구현)
|
|
||||||
**참고**:
|
|
||||||
- `troubleshooting/251002_emotion_db_storage_fix.md` (DB 저장 문제 해결)
|
|
||||||
- `plans/archive/250808_감정시스템_현실적용_5단계_로드맵.md` (전체 로드맵)
|
|
||||||
- `research/emotion/README.md` (감정 연구 이론 및 적용 방안)
|
|
||||||
- `research/emotion/gratch_marsella_2005_computational_models_of_emotion.md` (Appraisal Theory)
|
|
||||||
- `research/emotion/rashkin_et_al_2019_empathetic_dialogues.md` (공감 대화 시스템)
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
@ -76,7 +69,10 @@
|
|||||||
|
|
||||||
## 참고 문서
|
## 참고 문서
|
||||||
|
|
||||||
|
- `plans/archive/250808_감정시스템_현실적용_5단계_로드맵.md` (Phase 1–3 완료)
|
||||||
- `plans/archive/260102_9월이전_미해결_항목_통합.md` (감정 시스템, 기술 부채)
|
- `plans/archive/260102_9월이전_미해결_항목_통합.md` (감정 시스템, 기술 부채)
|
||||||
|
- `book/300_architecture/311_백엔드_구조_원칙.md`
|
||||||
|
- `book/300_architecture/315_테스트_원칙.md`
|
||||||
- `troubleshooting/251204_admin_dashboard_business_integration.md` (완료)
|
- `troubleshooting/251204_admin_dashboard_business_integration.md` (완료)
|
||||||
- `troubleshooting/251110_claude_gemini_file_search_coldmail_integration.md` (완료)
|
- `troubleshooting/251110_claude_gemini_file_search_coldmail_integration.md` (완료)
|
||||||
|
|
||||||
|
|||||||
@ -1,73 +1,45 @@
|
|||||||
# 로빙 감정 시스템 5단계 로드맵
|
# 로빙 감정 시스템 로드맵 (Phase 1–3 완료)
|
||||||
|
|
||||||
**작성일**: 2025-08-08
|
**작성일**: 2025-08-08
|
||||||
**목적**: 7개 감정 모델 → 32개 감정 + 온톨로지 점진 확장
|
**수정일**: 2026-02-04 (Phase 3-2 완료, Phase 4–5 장기 문서 분리)
|
||||||
|
**목적**: 7개 감정 모델 → 패턴 분석·공감 연동까지 단계별 확장
|
||||||
|
**상태**: Phase 1–3 완료, Phase 4–5 장기 계획 분리
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## Phase 1: 7개 기본 감정 (완료)
|
## Phase 1: 7개 기본 감정 (✅ 완료)
|
||||||
|
|
||||||
**구현**: `troubleshooting/250815_emotion_model_training.md` 참조
|
→ 상세: `troubleshooting/250815_emotion_model_training.md`
|
||||||
- 모델: klue/bert-base → ONNX (442MB, F1 56.3%)
|
|
||||||
- 감정: fear, surprise, anger, sadness, neutral, happiness, disgust
|
|
||||||
- 서비스: skill-embedding 통합 완료
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## Phase 2: 엔트로피 기반 복잡도 (완료)
|
## Phase 2: 엔트로피 기반 복잡도 (✅ 완료)
|
||||||
|
|
||||||
**구현**: `troubleshooting/251016_emotion_entropy_integration.md` 참조
|
→ 상세: `troubleshooting/251016_emotion_entropy_integration.md`
|
||||||
- 엔트로피로 응답 복잡도 결정
|
|
||||||
- 설정: confidence=0.35, entropy=2.0
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## Phase 3: 감정 온톨로지 (부분 완료)
|
## Phase 3: 감정 온톨로지 (✅ 완료)
|
||||||
|
|
||||||
**구현 완료**: `troubleshooting/251016_emotion_ontology_basic.md` 참조
|
### 3-1. 완료
|
||||||
- emotion_likelihood_ontology.py (11개 규칙)
|
- → 상세: `troubleshooting/251016_emotion_ontology_basic.md`
|
||||||
- OntologyReasoner.reason_with_emotion()
|
- → 상세: `troubleshooting/260104_emotion_pattern_analysis_phase2_implementation.md` (패턴 로직)
|
||||||
|
|
||||||
**미구현**:
|
### 3-2. 완료
|
||||||
- 감정 기반 응답 톤 조정 (현재 LLM에만 의존)
|
- → 상세: `troubleshooting/260204_emotion_phase3_2_implementation.md`
|
||||||
- 감정 기록 및 패턴 분석 DB
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## Phase 4: 32개 세밀 감정 (미구현)
|
## 장기 계획 (Phase 4–5)
|
||||||
|
|
||||||
### 목표
|
→ 상세: `plans/260204_감정시스템_장기로드맵_Phase4_5.md`
|
||||||
- Plutchik 감정 휠 기반 32개 감정
|
|
||||||
- Primary(8) → Secondary(8) → Tertiary(16)
|
|
||||||
|
|
||||||
### 필요 작업
|
|
||||||
1. AI Hub 데이터 재라벨링 (7 → 32개)
|
|
||||||
2. 모델 재학습 (다중 레이블 분류)
|
|
||||||
3. skill-embedding API 확장
|
|
||||||
|
|
||||||
**예상 기간**: 2-3개월
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Phase 5: 감정 기억 시스템 (미구현)
|
|
||||||
|
|
||||||
### 설계
|
|
||||||
- Neo4j에 감정 노드 저장
|
|
||||||
- 시간별 감정 변화 추적
|
|
||||||
- 패턴 분석 (우울증 조기 감지 등)
|
|
||||||
|
|
||||||
### 구조
|
|
||||||
```
|
|
||||||
User -feels→ Emotion -at→ Time
|
|
||||||
-talks_about→ Topic
|
|
||||||
```
|
|
||||||
|
|
||||||
**예상 기간**: 1개월
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 참고
|
## 참고
|
||||||
|
|
||||||
- `book/200_core_design/225_온톨로지_기반_지식_표현.md`
|
- `book/200_core_design/225_온톨로지_기반_지식_표현.md`
|
||||||
- `troubleshooting/250815_emotion_model_training.md`
|
- `book/300_architecture/311_백엔드_구조_원칙.md`
|
||||||
- `troubleshooting/251016_emotion_ontology_basic.md`
|
- `book/300_architecture/312_문서_작성_원칙.md`
|
||||||
|
- `book/300_architecture/315_테스트_원칙.md`
|
||||||
|
- `troubleshooting/251002_emotion_top-p_improvement.md` (감정 직접 노출 금지)
|
||||||
|
|||||||
@ -0,0 +1,20 @@
|
|||||||
|
# 감정 Phase 3-2 구현 완료
|
||||||
|
|
||||||
|
**날짜**: 2026-02-04
|
||||||
|
**관련 파일**: `rb8001/app/router/emotion_endpoint.py`, `rb8001/app/state/database.py`, `rb8001/app/services/diary/aggregator.py`, `rb8001/app/services/llm/llm_service.py`
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 구현 완료
|
||||||
|
|
||||||
|
- **Phase 3-2a**: emotion_endpoint.py entropy-pattern, hourly-trends, depression-risk 엔드포인트
|
||||||
|
- **Phase 3-2b**: database.py query_emotion_timeseries, query_team_emotion_insights → top_emotions 사용 (top_label 제거)
|
||||||
|
- **Phase 3-2c**: diary/aggregator entropy_pattern_summary, llm_service detect_depression_risk → 프롬프트 톤 조절 (라벨 직접 노출 금지)
|
||||||
|
- **검증**: test_emotion_pattern_analysis, test_emotion_prompt_no_direct_label 통과
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 교훈
|
||||||
|
|
||||||
|
- 프롬프트 금지어 테스트 시 "예시 문맥"(예: "감정 라벨(우울)...직접 언급 금지")은 허용. 사용자 응답에 직접 노출되는 문구만 금지어 검증 대상
|
||||||
|
- Phase 4·5는 장기 계획 문서로 분리 (`plans/260204_감정시스템_장기로드맵_Phase4_5.md`)
|
||||||
Loading…
x
Reference in New Issue
Block a user