DOCS/plans/250831_rb8001_postgresql_context_integration.md
happybell80 3030783ccb docs: PostgreSQL 통합 해결 방안 업데이트 - 단계적 접근
- Option 2: 즉시 적용 - _call_internal_llm()에서 조회
- Option 2.5: 장기 개선 - 엔드포인트에서 context 준비
- 책임 분리 원칙과 실용성 균형
2025-08-31 16:04:25 +09:00

76 lines
3.3 KiB
Markdown

# rb8001 PostgreSQL 대화 기록 LLM 컨텍스트 통합 계획
**작성일**: 2025-08-31
**작성자**: 51123 서버 관리자
**상태**: 🟡 계획 수립
**목표**: ChromaDB 벡터 검색과 PostgreSQL 최근 대화를 모두 LLM 프롬프트에 포함
---
## 1. 현재 문제
- **현상**: rb8001이 ChromaDB 벡터 검색만 참조하여 엉뚱한 답변
- **원인**: PostgreSQL conversation_logs의 최근 대화 미참조
- **영향**: 직전 대화 컨텍스트 손실, 일관성 없는 응답
## 2. 기술 분석
### 현재 구조 (확인 완료)
- `router.py` 라인 115-119: context에 user_id, channel, robeing_id만 포함
- `_save_conversation()`: PostgreSQL, ChromaDB 둘 다 저장 (구현됨)
- PostgreSQL 조회 함수: 없음 (ConversationLog 모델만 정의)
### 수정 필요 부분
- **파일**: `/home/heejae/rb8001/main.py`
- **엔드포인트 실제 구조**:
- `/api/message` (라인 51-103): Frontend용, `router._call_internal_llm()` 직접 호출
- `/api/slack/events` (라인 157-160): Slack용, `slack_handler()` 호출
- `/complete` (라인 106-140): skill-slack용, `router._call_internal_llm()` 직접 호출
- **핵심 문제**: router.handle_message()는 아무도 호출 안 함, 최근 대화 조회 코드가 실행 안 됨
## 3. 구현 계획
### 3.1 PostgreSQL 조회 함수 추가 (신규 구현)
- 파일: `/home/happybell80/ivada_project/rb8001/app/state/database.py`
- 함수명: `get_recent_conversations(user_id, limit=10)`
- 쿼리: `SELECT message, response, timestamp FROM conversation_logs WHERE user_id = %s ORDER BY timestamp DESC`
### 3.2 해결 방안 (단계적 접근)
- **즉시 적용 (Option 2)**: `_call_internal_llm()` 내부에서 최근 대화 조회
```python
# router.py _call_internal_llm() 내부
if not context.get("recent_conversations"):
context["recent_conversations"] = await get_recent_conversations(user_id)
```
- 장점: 한 곳 수정으로 모든 경로 해결
- 단점: 책임 분리 원칙 위반
- **장기 개선 (Option 2.5)**: main.py 엔드포인트에서 context 준비 후 전달
```python
# main.py 각 엔드포인트
recent_conversations = await get_recent_conversations(user_id)
context = {"recent_conversations": recent_conversations}
await router._call_internal_llm(..., context=context)
```
- 장점: 깔끔한 책임 분리, 기존 context 파라미터 활용
- TODO 주석 추가: "리팩토링 - context는 호출하는 쪽에서 준비"
## 4. 주의사항
- **UUID 처리**: Frontend(UUID) vs Slack(변환 필요) 구분
- **성능**: PostgreSQL 조회 추가로 인한 지연 고려
- **순서**: 최근 대화를 먼저, 벡터 검색을 보조로
## 5. 추가 이슈
- ChromaDB telemetry 오류 발생 중 → `ANONYMIZED_TELEMETRY=false` 설정 필요
- user_id UUID 타입 처리 필요 (Frontend=UUID, Slack=변환)
- LLM: Gemini 2.5 Flash Lite (DEFAULT_LLM_MODEL=gemini-2.5-flash-lite)
## 6. 위험성 완화 방안
- **성능**: 캐싱 레이어 추가 또는 비동기 처리로 지연 최소화
- **UUID 오류**: try-except로 UUID 검증, 실패 시 slack_user_id 폴백
- **토큰 한계**: 최근 5개로 제한, 각 대화 200자 truncate
- **로직 충돌**: PostgreSQL은 최근 사실, ChromaDB는 장기 기억으로 역할 분리
- **점진적 적용**: 환경변수 `USE_POSTGRES_CONTEXT=true`로 기능 토글