docs: APScheduler Monday=0 체계 주의사항 추가

This commit is contained in:
Claude-51124 2025-09-22 22:03:28 +09:00
parent 4229f916a2
commit b50a2fb761
4 changed files with 458 additions and 1 deletions

View File

@ -29,7 +29,7 @@
### 2.1 트리거 방식 ### 2.1 트리거 방식
- **스케줄러**: 매일 09:00 KST 자동 실행 - **스케줄러**: 매일 09:00 KST 자동 실행
- **위치(현행)**: rb8001/main.py 내 APScheduler 초기화 및 잡 등록 - **위치(현행)**: rb8001/main.py 내 APScheduler 초기화 및 잡 등록
- **도구**: APScheduler (환경변수 기반 자동 등록 패턴 사용) - **도구**: APScheduler (환경변수 기반 자동 등록 패턴 사용, **주의: Monday=0 체계 사용, 평일은 'mon-fri' 권장**)
### 2.2 처리 흐름 (현행 코드 기준 + 계획) ### 2.2 처리 흐름 (현행 코드 기준 + 계획)
1. 스케줄러가 09:00에 rb8001 트리거 (main.py) 1. 스케줄러가 09:00에 rb8001 트리거 (main.py)

View File

@ -0,0 +1,127 @@
# ChromaDB Collection 명명 규칙 통일
**작성일**: 2025-09-20
**작성자**: Claude
**관련 서비스**: rb8001, skill-rag-file
**이슈**: ChromaDB 컬렉션 명명 규칙 불일치
## 문제 상황
- rb8001과 skill-rag-file이 서로 다른 명명 규칙 사용
- 기존: `rb8001_{user_id}`, `rb8001_{team_id}_documents`
- 일관성 없는 명명으로 관리 어려움
## 해결 방안
### 표준 명명 규칙 정의
```
{service}_{identifier}_{type}
```
- **service**: 서비스명 (rb8001, skill_rag_file 등)
- **identifier**: UUID (user_uuid 또는 team_uuid)
- **type**: 데이터 타입 (memory, documents 등)
### 구현 변경사항
#### 1. rb8001 수정
**파일**: `/home/admin/ivada_project/rb8001/app/memory/manager.py`
변경 전:
```python
self.collection_name = f"{robeing_id}_{user_id}"
```
변경 후:
```python
self.collection_name = f"{robeing_id}_{user_id}_memory"
collection_metadata = {"service": robeing_id, "user_id": user_id, "type": "memory"}
```
#### 2. skill-rag-file 수정
**파일**: `/home/admin/ivada_project/skill-rag-file/app/api/upload.py`
**파일**: `/home/admin/ivada_project/skill-rag-file/app/api/search.py`
변경 전:
```python
collection_name = f"rb8001_{team_id}_documents"
```
변경 후:
```python
collection_name = f"skill_rag_file_{team_id}_documents"
```
#### 3. 마이그레이션 스크립트
**파일**: `/home/admin/ivada_project/rb8001/scripts/migrate_chromadb_collections.py`
주요 기능:
- 기존 컬렉션 백업
- 새 명명 규칙으로 복원
- 메타데이터 추가 (service, type)
- 자동 실행 모드 지원 (`--auto`)
### 테스트 결과
#### rb8001 테스트
```python
# 생성된 컬렉션명
rb8001_test_user_12345_memory
# 메타데이터
{
"service": "rb8001",
"user_id": "test_user_12345",
"type": "memory"
}
```
#### skill-rag-file 테스트
```python
# 생성된 컬렉션명
skill_rag_file_test_team_123_documents
# 메타데이터
{
"service": "skill_rag_file",
"type": "documents",
"team_id": "test_team_123"
}
```
## 배포 절차
1. 코드 수정 및 푸시
2. 서비스 재시작
```bash
# rb8001
docker compose down && docker compose up -d --build
# skill-rag-file
cd /home/admin/ivada_project/skill-rag-file
docker compose down && docker compose up -d --build
```
3. 권한 수정 (필요시)
```bash
sudo chown -R admin:xusers /home/admin/ivada_project/rb8001/chroma_db/
sudo chmod -R 775 /home/admin/ivada_project/rb8001/chroma_db/
```
4. 마이그레이션 실행 (기존 데이터가 있는 경우)
```bash
python3 scripts/migrate_chromadb_collections.py --auto
```
## 주의사항
- ChromaDB 버전에 따른 호환성 문제 가능
- 권한 문제 발생 시 chown/chmod 필요
- 텔레메트리 관련 경고는 무시 가능
## 교훈
1. **명명 규칙 표준화의 중요성**: 초기 설계 단계에서 전체 시스템의 명명 규칙을 통일
2. **메타데이터 활용**: 컬렉션 메타데이터로 서비스, 타입 등 추가 정보 저장
3. **마이그레이션 준비**: 스키마 변경 시 항상 마이그레이션 스크립트 준비
4. **권한 관리**: Docker 컨테이너와 호스트 간 파일 권한 일치 필요
## 관련 문서
- [000000_unresolved_items_matrix.md](../plans/000000_unresolved_items_matrix.md)
- [250915_skill-rag-file_초기_구축.md](250915_skill-rag-file_초기_구축.md)

View File

@ -0,0 +1,177 @@
# 감정 시스템 구현 계획 (rb8001)
**작성일**: 2025-09-20
**작성자**: Claude
**관련 서비스**: rb8001
**이슈**: 감정 분석 시스템 미구현
## 현재 상황
### rb8001 감정 시스템 현황
- **구조만 존재**: base.py, emotion_llm.py 등 파일은 있으나 임시 구현
- **실제 분석 없음**: 모든 감정에 균등 분포 (1/9) 반환
- **rb10508 부재**: 이식하려던 rb10508 디렉토리 자체가 없음
### 구현된 부분
```python
# /app/core/emotion/base.py
- EmotionState 클래스 정의
- 9개 감정: joy, sadness, anger, fear, disgust + anxiety, envy, embarrassment, ennui
- calculate_entropy() 함수
- Thompson Sampling 구조
```
### 미구현 부분
1. **모델 통합**: klue/bert-base 기반 7클래스 분류기
2. **ONNX 추론**: 모델 변환 및 최적화
3. **Temperature Scaling**: 확률 보정
4. **데이터베이스**: emotion_readings 테이블
5. **API 엔드포인트**: /v1/emotion/infer 등
## 구현 로드맵
### Phase 1: 기본 감정 분석 (1주)
1. **Day 1-2: 모델 준비**
- klue/bert-base 기반 감정 분류 모델 준비
- 7개 클래스: fear, surprise, anger, sadness, neutral, happiness, disgust
- ONNX 변환 및 최적화
2. **Day 3-4: 추론 엔진 구현**
```python
# /app/core/emotion/inference.py
class EmotionInference:
def __init__(self, model_path: str):
self.session = onnxruntime.InferenceSession(model_path)
self.tokenizer = AutoTokenizer.from_pretrained("klue/bert-base")
self.temperature = 1.0
def predict(self, text: str) -> Dict[str, float]:
# 토크나이징
inputs = self.tokenizer(text, max_length=128, truncation=True)
# ONNX 추론
logits = self.session.run(None, inputs)[0]
# Temperature Scaling
probs = softmax(logits / self.temperature)
return dict(zip(EMOTION_LABELS, probs))
```
3. **Day 5: DB 스키마 구현**
```sql
CREATE TABLE emotion_readings (
id UUID PRIMARY KEY,
user_id UUID REFERENCES "user"(id),
text_hash VARCHAR(64),
model_version VARCHAR(20),
temperature FLOAT,
logits JSONB,
probs JSONB,
top_label VARCHAR(20),
top_p FLOAT,
entropy FLOAT,
meta JSONB,
created_at TIMESTAMP DEFAULT NOW()
);
CREATE INDEX idx_emotion_user_time ON emotion_readings(user_id, created_at);
```
### Phase 2: API 및 통합 (1주)
1. **Day 6-7: API 엔드포인트**
```python
# /app/api/emotion.py
@router.post("/v1/emotion/infer")
async def infer_emotion(text: str, user_id: str):
# 감정 분석
result = emotion_inference.predict(text)
# DB 저장
await save_emotion_reading(user_id, text, result)
return result
@router.get("/v1/emotion/timeseries")
async def get_emotion_timeseries(user_id: str, start: datetime, end: datetime):
# 시계열 데이터 조회
readings = await get_readings(user_id, start, end)
return aggregate_emotions(readings)
```
2. **Day 8-9: 기존 시스템 통합**
- Router에서 감정 분석 호출
- 메모리 저장 시 감정 메타데이터 추가
- Slack 응답에 감정 정보 포함
3. **Day 10: 시각화**
- 감정 그래프 생성 (matplotlib/plotly)
- Slack 이미지 업로드
### Phase 3: 고도화 (선택적)
1. **Temperature Calibration**
- 검증 데이터셋으로 최적 T 값 찾기
- ECE (Expected Calibration Error) 최소화
2. **배치 처리 최적화**
- 마이크로배칭
- 비동기 처리 큐
3. **감정 공명 시스템**
- 과거 감정과 현재 감정 결합
- 사용자별 감정 패턴 학습
## 구현 우선순위
### 즉시 구현 가능 (Quick Win)
1. ✅ 감정 DB 테이블 생성
2. ✅ 간단한 규칙 기반 감정 분석 (키워드 매칭)
3. ✅ 감정 저장 및 조회 API
### 중기 목표 (1-2주)
1. ⏳ BERT 모델 통합
2. ⏳ ONNX 최적화
3. ⏳ Temperature Scaling
### 장기 목표 (1개월+)
1. 📅 사용자별 감정 패턴 학습
2. 📅 실시간 감정 모니터링 대시보드
3. 📅 감정 기반 응답 생성
## 리소스 요구사항
### 모델
- klue/bert-base (400MB)
- ONNX 변환 모델 (100MB)
- 추론 시간: CPU 40-80ms, GPU 10-20ms
### 인프라
- 추가 메모리: 500MB-1GB
- DB 스토리지: 사용자당 일 100KB
- 계산 리소스: CPU 2 cores 권장
## 주의사항
1. **프라이버시**
- 원문 텍스트는 해시만 저장
- 사용자 동의 필요
- 삭제 권한 보장
2. **성능**
- 캐싱 적극 활용
- 배치 처리로 효율화
- 비동기 처리 필수
3. **정확도**
- 한국어 특화 모델 필요
- 지속적인 모니터링
- 사용자 피드백 수집
## 결론
"감정시스템 이식"이라는 작업은 실제로는 **새로운 구현**이 필요합니다:
- rb10508에 구현된 감정 시스템이 없음
- rb8001에 기본 구조만 있고 실제 기능 없음
- 처음부터 구현 필요
**권장 사항**:
1. 단계적 구현 (간단한 키워드 기반 → BERT 모델)
2. 우선순위: DB 스키마 → API → 모델 통합
3. 예상 소요 시간: 2-3주 (전체 구현)

View File

@ -0,0 +1,153 @@
# 사용자 식별 체계 UUID 통합 구현
**작성일**: 2025-09-20
**작성자**: Claude
**관련 서비스**: rb8001, skill-email, skill-rag-file
**이슈**: 서비스 간 사용자 식별자 불일치 (UUID vs Slack ID)
## 문제 상황
- 서비스마다 다른 사용자 식별자 사용 (UUID, Slack ID, Google ID 등)
- skill-email이 Slack ID만 지원하여 UUID 기반 시스템과 호환 불가
- ChromaDB 컬렉션 명명 규칙 불일치
## 현재 시스템 구조 분석
### 데이터베이스 구조
```sql
-- user 테이블 (이미 UUID 사용 중)
- id: UUID (Primary Key)
- oauth_id: VARCHAR (Slack ID, Google ID 등)
- oauth_provider: VARCHAR (slack, google 등)
- email: VARCHAR
-- gmail_token, naverworks_token 테이블
- user_id: UUID (user 테이블 참조)
- token_data: JSONB
- is_equipped: BOOLEAN
```
### 서비스별 현황
1. **rb8001**: UUID 받아서 필요시 Slack ID로 변환
2. **skill-email**: Slack ID만 지원 → UUID 지원 추가 필요
3. **skill-rag-file**: UUID 지원
4. **ChromaDB**: 서비스별 다른 명명 규칙
## 구현 내용
### 1. skill-email UUID 지원 추가
#### DBCredentialsProvider 수정
**파일**: `/home/admin/ivada_project/skill_email/services/db_credentials_provider.py`
```python
def get_credentials(self, user_id: str) -> Optional[Credentials]:
# UUID 형식 검증
import re
is_uuid = bool(re.match(r'^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$', user_id.lower()))
if is_uuid:
# UUID로 직접 조회
query = """
SELECT gt.token_data, gt.oauth_config, gt.scopes, gt.expiry
FROM gmail_token gt
WHERE gt.user_id = %s AND gt.is_equipped = true
"""
else:
# Slack ID로 조회 (하위 호환성)
query = """
SELECT gt.token_data, gt.oauth_config, gt.scopes, gt.expiry
FROM gmail_token gt
JOIN "user" u ON gt.user_id = u.id
WHERE u.oauth_id = %s AND gt.is_equipped = true
"""
```
#### NaverWorksProvider (이미 UUID 지원)
**파일**: `/home/admin/ivada_project/skill_email/services/naverworks_provider.py`
- 이미 UUID와 username 모두 지원하도록 구현되어 있음
### 2. ChromaDB Collection 명명 규칙 통일
표준 명명 규칙: `{service}_{identifier}_{type}`
#### rb8001 변경
**파일**: `/home/admin/ivada_project/rb8001/app/memory/manager.py`
- 변경 전: `rb8001_{user_id}`
- 변경 후: `rb8001_{user_id}_memory`
#### skill-rag-file 변경
**파일**: `/home/admin/ivada_project/skill-rag-file/app/api/upload.py`, `search.py`
- 변경 전: `rb8001_{team_id}_documents`
- 변경 후: `skill_rag_file_{team_id}_documents`
### 3. 환경 변수 설정
#### skill-email 설정
**파일**: `/home/admin/ivada_project/skill_email/.env`
```env
TOKEN_PROVIDER=database # api에서 database로 변경
POSTGRES_CONNECTION_STRING=postgresql://robeings:robeings@192.168.219.45:5432/main_db
```
## 테스트 결과
### UUID 조회 테스트
```bash
# UUID로 이메일 조회
curl "http://localhost:8501/messages?user_id=53529291-5050-4daa-89fb-008b546feb63&limit=1&provider=gmail"
# 결과: 성공 (토큰 만료 시 적절한 에러 메시지)
# Slack ID로 이메일 조회 (하위 호환성)
curl "http://localhost:8501/messages?user_id=100176844464607664427&limit=1&provider=gmail"
# 결과: 성공 (동일하게 작동)
```
### ChromaDB Collection 테스트
```python
# rb8001 컬렉션
collection_name = "rb8001_test_user_12345_memory" # ✅
# skill-rag-file 컬렉션
collection_name = "skill_rag_file_test_team_123_documents" # ✅
```
## 주의사항
1. **TOKEN_PROVIDER 설정**: skill-email에서 `database` 사용 필수
- `api`: robeing-monitor 경유 (UUID 미지원)
- `database`: 직접 DB 조회 (UUID 지원)
2. **토큰 만료 처리**: Gmail 토큰이 자주 만료되므로 refresh 로직 필요
3. **하위 호환성**: Slack ID 조회는 계속 지원하여 기존 시스템 영향 최소화
## 남은 작업
### 우선순위 높음
1. ✅ ChromaDB 명명 규칙 통일 완료
2. ✅ skill-email UUID 지원 완료
3. ⏳ robeing-monitor UUID 지원 추가 (TOKEN_PROVIDER=api 사용 시)
### 우선순위 중간
1. 전체 시스템 통합 테스트
2. 토큰 자동 갱신 메커니즘 구현
3. 성능 최적화 (UUID 변환 캐싱)
## 교훈
1. **설계 단계에서 일관된 식별자 체계 정의 필수**
- 처음부터 UUID를 primary identifier로 설계
- 외부 ID는 매핑 테이블로 관리
2. **하위 호환성 유지 전략**
- UUID/Slack ID 자동 감지 로직 구현
- 점진적 마이그레이션 지원
3. **환경 변수 활용**
- Provider 선택을 환경 변수로 제어
- 배포 환경별 유연한 설정 가능
## 관련 문서
- [250831_unified_id_system_implementation_roadmap.md](../plans/250831_unified_id_system_implementation_roadmap.md)
- [250920_chromadb_collection_naming_unification.md](250920_chromadb_collection_naming_unification.md)
- [000000_unresolved_items_matrix.md](../plans/000000_unresolved_items_matrix.md)