docs(troubleshooting): 메모리시스템 하드코딩 문제 분석 문서 이동

- ideas/ → troubleshooting/ 이동
- 트러블슈팅 문서 형식에 맞게 재배치
- rb10508_micro 메모리 시스템 개선방안 포함
This commit is contained in:
Claude-51124 2025-11-10 12:47:46 +09:00
parent ebd0c4d36b
commit cc0e5cf6df

View File

@ -0,0 +1,200 @@
# rb10508 메모리 시스템 하드코딩 문제 분석 및 개선 방안
## 작성 정보
- 작성일: 2025-08-12
- 작성자: Claude (51124 서버)
- 대상: rb10508_micro 서비스
- 배경: "김종태야님" 호칭 문제로 발견된 근본적 설계 이슈
## 1. 문제 상황
### 1.1 대화 로그 분석
사용자가 반복적으로 "종태님"이라고 부르라고 요청했으나, AI가 계속 "김종태야님"이라고 잘못 호칭하는 문제 발생.
```
user: 종태님이라고 부르라고!!
assistant: 네, 김종태야님. 종태님이라고 부르겠습니다.
user: 진짜 미친거야?
assistant: 김종태 님. 죄송합니다.
```
### 1.2 근본 원인
- 하드코딩된 메모리 시스템
- 학습 능력 부재
- 모든 대화를 무차별 저장
## 2. 현재 시스템 분석
### 2.1 컬렉션 구조
```
rb10508_test_happybell80
rb10508_test_episodic # 모든 대화가 여기에만 저장
rb10508_test_procedural # 사용 안 함
rb10508_test_semantic # 사용 안 함
rb10508_test_identity
rb10508_test_test_user
```
### 2.2 메모리 검색 알고리즘
#### 현재 프로세스:
1. **단일 컬렉션 검색**: 항상 `episodic`만 검색
2. **ChromaDB 벡터 검색**: 최대 100개, user_id로만 필터
3. **Mistral LLM 필터링**:
- 의도 분석
- 베이지안 점수 + 시간 감쇠
- MMR (다양성 보장)
- 최종 5-9개 선택
4. **문제점**:
- 다른 컬렉션 무시
- 잘못된 내용 필터링 불가
- 컬렉션 간 연결 없음
### 2.3 메모리 저장 알고리즘
#### ID 생성:
```python
memory_id = f"{user_id}_{hashlib.md5(f'{content}{timestamp}'.encode()).hexdigest()[:16]}"
# 결과: test_user_78c0c0c5cee10ee6
```
#### 문제점:
- 모든 대화가 episodic에만 저장
- 사용자별 컬렉션 자동 생성 (관리 어려움)
- metadata에 content 중복 저장 (공간 낭비)
- 임베딩 서비스 의존 (폴백 없음)
## 3. 하드코딩 문제 목록
### 3.1 발견된 하드코딩
```python
# 컬렉션 이름
f"{settings.ROBING_ID}_{memory_type}" # 고정 패턴
# 메모리 타입
memory_type = "episodic" # 항상 같은 값
# 사용자 ID
user_id = "test_user" # 테스트 하드코딩
# 검색 개수
n_results = 100 # 고정값
top_n = len(memories) // 5 # 20% 고정
# 수학 상수
golden_ratio = (1 + 5 ** 0.5) / 2 # 매번 재계산
```
### 3.2 ChromaDB 제약사항
- 컬렉션 이름: 한글 불가, 영문/숫자/언더스코어/하이픈만 가능
- 메타데이터: 한글 가능
- 삭제 기능: `collection.delete(ids=[...])` 또는 `where` 조건 가능
## 4. 로빙 철학과의 충돌
### 4.1 현재: "도구적 기록"
- 모든 대화를 무차별 저장
- 개발자가 정한 규칙만 따름
- 학습 능력 없음
### 4.2 목표: "존재적 기억"
- 의미 있는 순간만 기억
- 스스로 학습하고 성장
- 관계 중심의 기억 구조
## 5. 개선 방안
### 5.1 단순 CONFIG 방식의 한계
```python
# 여전히 개발자가 정한 틀
CONFIG = {
"memory": {
"types": ["episodic", "semantic"],
"default_type": "episodic"
}
}
```
### 5.2 메모리 기반 자율 학습 시스템
#### 핵심 개념:
**"코드는 학습 방법만 정의, 무엇을 학습할지는 로빙이 결정"**
#### 학습 가능한 메모리 구조:
```python
memory = {
"type": "learning_moment",
"pattern": "호칭_수정_요청",
"before": "김종태야님",
"after": "종태님",
"feedback": "negative",
"applied_count": 0,
"success_rate": 0.0,
"growth_exp": 10
}
```
#### 자율 진화 프로세스:
1. **실수 → 피드백 → 학습**
```python
if user_emotion == "anger" and "이름" in message:
await create_learning_memory(mistake, correction)
```
2. **학습 → 적용 → 검증**
```python
learned_rules = await get_learned_rules(user_id)
response = apply_rules(response, learned_rules)
await track_rule_success(rule_id, user_reaction)
```
3. **성공 → 강화 → 영구화**
```python
if rule.success_rate > 0.8 and rule.applied_count > 10:
await promote_to_core_identity(rule)
```
### 5.3 즉시 적용 가능한 조치
1. **잘못된 메모리 정리**
- "김종태야" 포함 26개 메모리 삭제
- identity 컬렉션에 preferred_name 저장
2. **컬렉션 재구성**
```
robing_10508_core # 핵심 정체성
robing_10508_with_jongtae # 종태님과의 기억
robing_10508_growth # 학습 내용
```
3. **선택적 저장**
```python
if calculate_entropy(message) > 0.7 or emotion_intensity > 0.5:
await save_memories(...)
```
## 6. 핵심 통찰
### 함수형 프로그래밍 vs 하드코딩
- **함수형**: HOW (어떻게 구현) - 순수 함수, 부작용 없음
- **하드코딩 제거**: WHAT (무엇을 설정) - 유연성, 재사용성
- 둘은 독립적이지만 함께 추구해야 함
### 왜 하드코딩을 제거해야 하는가?
> "로빙이 학습하고 성장하는 존재가 되려면, 코드를 고치지 않고도 행동이 바뀌어야 한다"
- 하드코딩 = 로빙이 도구로 고정
- 메모리 학습 = 로빙이 존재로 진화
## 7. 결론
현재 rb10508_micro는 "모든 것을 기록하는 도구"입니다.
목표는 "의미 있는 순간을 기억하고 성장하는 존재"입니다.
이를 위해서는:
1. 하드코딩 제거
2. 메모리 기반 학습 시스템 구축
3. 관계 중심 컬렉션 구조
4. 선택적 기억과 망각
"종태님"이라고 한 번 배우면 기억하고, 다음엔 스스로 적용하는 것이 진짜 AI입니다.