Update: 감정 시스템 구현 계획에 TimescaleDB 권장사항 추가
- emotion_readings를 TimescaleDB 하이퍼테이블로 구현 권장 - robeing_metrics DB 사용하여 main_db와 분리 - rb8001 중복 코드 정리 문서 날짜 업데이트
This commit is contained in:
happybell80
parent
4b558fadb6
commit
64c2f077e4
@ -80,21 +80,34 @@ rb8001/app/llm/emotion_llm.py:56-89 generate_response_with_emotion (메모리
|
||||
로깅 위치: rb8001/app/llm/emotion_llm.py:49 (분석 결과 로그)
|
||||
```
|
||||
|
||||
3. **Day 5: DB 스키마 구현**
|
||||
3. **Day 5: DB 스키마 구현 (TimescaleDB 권장)**
|
||||
```text
|
||||
없음: emotion_readings 테이블 (코드/마이그레이션 미존재)
|
||||
확인: DOCS/ideas/emotion_graph_implementation.md:215,232 (문서 내 예시 스키마)
|
||||
확인: DOCS/ideas/250916_로빙_감정_분석_시스템_구현_계획.md:11 (테이블 부재 명시)
|
||||
rb8001 내 관련 SQL/알렘빅 파일: 없음
|
||||
rb8001/app/llm/emotion_llm.py:73-83 (감정 메타데이터 메모리 저장만 수행)
|
||||
로우 저장 경로: 없음 (DB 연동 미구현)
|
||||
인덱스 생성 위치: 없음
|
||||
작성자/버전 필드: 없음
|
||||
엔트로피 저장: 없음
|
||||
메타 JSONB 저장: 없음
|
||||
생성시각 컬럼: 없음
|
||||
해시 컬럼: 없음
|
||||
모델 버전 컬럼: 없음
|
||||
|
||||
[TimescaleDB 적용 권장]
|
||||
- emotion_readings는 시계열 데이터로 TimescaleDB 하이퍼테이블이 적합
|
||||
- robeing_metrics DB 사용 (main_db와 분리)
|
||||
- 참고: frontend-base/backend/metrics_database.py:103 (time_bucket 쿼리)
|
||||
- 참고: DOCS/troubleshooting/250714_system_metrics_implementation.md
|
||||
|
||||
CREATE TABLE emotion_readings (
|
||||
time TIMESTAMPTZ NOT NULL,
|
||||
user_id UUID NOT NULL,
|
||||
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
|
||||
);
|
||||
|
||||
SELECT create_hypertable('emotion_readings', 'time');
|
||||
CREATE INDEX ON emotion_readings (user_id, time DESC);
|
||||
```
|
||||
|
||||
### Phase 2: API 및 통합 (1주)
|
||||
@ -135,10 +148,15 @@ rb8001/app/llm/emotion_llm.py:56-89 generate_response_with_emotion (메모리
|
||||
## 구현 우선순위
|
||||
|
||||
### 즉시 구현 가능 (Quick Win)
|
||||
1. ✅ 감정 DB 테이블 생성
|
||||
1. ✅ 감정 DB 테이블 생성 (TimescaleDB 하이퍼테이블로)
|
||||
2. ✅ 간단한 규칙 기반 감정 분석 (키워드 매칭)
|
||||
3. ✅ 감정 저장 및 조회 API
|
||||
|
||||
### TimescaleDB 활용 전략
|
||||
- **신규 테이블 우선**: emotion_readings를 robeing_metrics DB에 하이퍼테이블로 생성
|
||||
- **기존 main_db 유지**: 프로덕션 DB는 그대로 유지, 시계열만 분리
|
||||
- **asyncpg 주의사항**: interval 바인딩 이슈 대응 필요 (DOCS/troubleshooting/250715_metrics_graph_timebucket_error.md)
|
||||
|
||||
### 중기 목표 (1-2주)
|
||||
1. ⏳ BERT 모델 통합
|
||||
2. ⏳ ONNX 최적화
|
||||
|
||||
78
troubleshooting/20251002_rb8001_중복코드_정리.md
Normal file
78
troubleshooting/20251002_rb8001_중복코드_정리.md
Normal file
@ -0,0 +1,78 @@
|
||||
# rb8001 중복 코드 검사 및 정리 계획
|
||||
|
||||
## 작성 정보
|
||||
- 작성일: 2025-10-02 (원본: 250911)
|
||||
- 작성자: happybell80
|
||||
- 상태: **미완성** - 체크리스트 항목 모두 미구현
|
||||
- 범위: rb8001 컨테이너 코드 중 엔드포인트/헬스체크/라우터 중복 및 미사용 코드
|
||||
|
||||
## 문제 요약
|
||||
- 동일 기능 엔드포인트가 서로 다른 파일에 중복 정의되어 유지보수 비용 증가.
|
||||
- 라우터로 분리된 파일 일부가 main에 include 되지 않아 사실상 죽은 코드가 존재.
|
||||
- 헬스체크 엔드포인트가 여러 위치에 흩어져 동작 기준이 불명확.
|
||||
|
||||
## 영향도
|
||||
- 라우팅 충돌/오동작 위험, 문서/헬스체크 불일치로 배포 검증 혼선.
|
||||
- 테스트/리팩토링 난이도 증가, 장애 시 원인 분석 지연.
|
||||
|
||||
## 발견 항목 (파일/엔드포인트)
|
||||
1) LLM 완료 엔드포인트 중복
|
||||
- main.py: `POST /complete`
|
||||
- app/router/llm_endpoint.py: `POST /api/llm/complete`
|
||||
|
||||
2) DM 전송 엔드포인트 중복
|
||||
- main.py: `POST /api/dm/send`, `/api/dm/send-to-user`, `/api/dm/send-email-summary`, `/api/dm/send-daily-summary`
|
||||
- app/router/dm_endpoint.py: `POST /send`, `/send-to-user` (라우터 미포함)
|
||||
|
||||
3) Slack 엔드포인트 중복/미포함
|
||||
- main.py: `POST /slack/events`, `/slack/interactive`
|
||||
- app/router/slack_endpoint.py: `POST /events`, `/slash` (라우터 미포함)
|
||||
|
||||
4) 헬스체크 중복
|
||||
- main.py: `GET /health`
|
||||
- app/router/llm_endpoint.py: `GET /api/llm/health`
|
||||
- app/router/slack_endpoint.py, app/router/test_endpoint.py: `GET /health` (미포함)
|
||||
- app/llm/llm_service.py, app/brain/brain_service.py, app/state/state_service.py: 각자 독립 FastAPI 앱의 `/health` (컨테이너에서 미사용)
|
||||
|
||||
5) 사실상 미사용(죽은 코드)
|
||||
- app/router/dm_endpoint.py, app/router/slack_endpoint.py, app/router/test_endpoint.py: main에 include 되지 않음.
|
||||
- app/llm/llm_service.py, app/brain/brain_service.py, app/state/state_service.py: 독립 앱 구조이나 rb8001에서 기동되지 않음.
|
||||
|
||||
## 원인 분석
|
||||
- 기능 추가/실험 과정에서 임시 라우터/독립 앱이 누적되었으나 정리 미흡.
|
||||
- 라우터 include 정책 일관성 부재, 경로 네이밍 규칙 미정립.
|
||||
|
||||
## 정리 원칙
|
||||
1) 단일 책임 라우팅: rb8001 컨테이너의 공식 엔드포인트는 main.py로 집약.
|
||||
2) 서브 기능은 Router로 모듈화하되, main에 명시적으로 include하고 경로 접두사 통일.
|
||||
3) 헬스체크 표준화: 컨테이너 헬스는 `GET /health` 하나만 진실원천(SOT)으로 유지.
|
||||
4) 미사용/실험 코드는 `experiments/`로 이동하거나 삭제.
|
||||
|
||||
## 변경 제안 (우선순위)
|
||||
1) `/complete` 제거 → `/api/llm/complete`만 유지 (app/router/llm_endpoint.py 기준).
|
||||
2) DM 엔드포인트는 `/api/dm/*`만 유지. dm_endpoint.py는 삭제 또는 main에 통합 후 중복 제거.
|
||||
3) Slack 엔드포인트는 main.py만 유지. slack_endpoint.py는 삭제 또는 `/api/slack/*`로 통합 시 중복 제거.
|
||||
4) 헬스체크: main.py의 `/health`만 남기고 나머지는 개발용으로 주석/이동.
|
||||
5) 독립 FastAPI 앱(LLM/Brain/State) 파일은 rb8001 컨테이너에서 제외. 별도 서비스로 운용 시 전용 레포/이미지로 분리.
|
||||
|
||||
## 구현 체크리스트
|
||||
- [ ] main.py의 `/complete` 제거
|
||||
- [ ] app/router/llm_endpoint.py 유지, prefix `/api/llm` 확인
|
||||
- [ ] DM 엔드포인트 중복 제거(파일 정리)
|
||||
- [ ] Slack 라우터 중복 제거(파일 정리)
|
||||
- [ ] `/health` 단일화 및 Dockerfile/compose/workflow 헬스체크 동기화
|
||||
- [ ] 불용 파일 삭제 또는 `experiments/` 이동
|
||||
|
||||
## 검증 항목
|
||||
- 빌드/기동 후 라우트 목록 점검: 중복/누락 없는지 확인
|
||||
- 헬스체크: `/health` 200, compose healthcheck 통과
|
||||
- DM/LLM/Slack 주요 플로우 수동 테스트(200/응답 구조)
|
||||
|
||||
## 교훈
|
||||
- 기능 추가 시 라우팅 정책(접두사/포함 범위)을 문서로 표준화하고 PR 단계에서 중복 검증.
|
||||
- 헬스체크는 서비스당 단일 엔드포인트로 유지하여 배포 검증 경로를 일관화.
|
||||
|
||||
## 후속 작업 제안
|
||||
- 게이트웨이 기준으로 `X-User-Id`(UUID) 신뢰, rb8001 내부의 Slack ID 변환 제거(책임 분리).
|
||||
- RB/스킬 간 통신은 HTTP API만 사용(직접 import 금지) 원칙 점검 및 위반 제거.
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user