happybell80
2f01e13d36
- main.py 엔드포인트들이 router._call_internal_llm() 직접 호출 - router.handle_message()는 사용되지 않음 - 해결 방안 2가지 제시: 구조 변경 vs 각 엔드포인트 수정
2.9 KiB
2.9 KiB
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 해결 방안 (2가지 중 선택)
- 방안 1: main.py 엔드포인트들이
router.handle_message()호출하도록 변경- 장점: 한 곳에서 최근 대화 조회 관리
- 단점: 큰 구조 변경 필요
- 방안 2: 각 엔드포인트(
/api/message,/api/slack/events)에서 직접 최근 대화 조회- 장점: 기존 구조 유지
- 단점: 중복 코드 발생
- gemini_handler.py: 어느 방안이든 context['recent_conversations'] 활용 필요
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로 기능 토글