Team C: 네임스페이스 설계

분석 대상

Memory 네임스페이스 구조, retrieve_memories 검색, save_conversation 저장

네임스페이스 구조

examplecorp/
├── user/
│   └── {actor_id}/
│       ├── facts/          ← Semantic Memory
│       │   ├── "imaging-ops@examplecorp.com 권한 정보"
│       │   └── "VPC-A에 reporting, VPC-B에 database"
│       │
│       ├── preferences/    ← User Preference Memory
│       │   ├── "SOP: CloudWatch → 연결성 분석 → 수정"
│       │   └── "요약 형식 선호, 한국어 응답"
│       │
│       └── {session_id}/   ← Summary Memory
│           ├── "PathID: nip-xxx, 분석 완료"
│           └── "SG 수정 필요, 포트 3306"

retrieve_memories: 벡터 검색

검색 동작:

  1. query를 Amazon Titan Embed V2로 벡터화

  2. 지정된 namespace 내에서 코사인 유사도 검색

  3. 유사도 높은 상위 top_k개 메모리 반환

반환 형식

save_conversation: 대화 저장

저장 동작:

  1. 메시지 텍스트와 역할(user/assistant)을 튜플로 전달

  2. AgentCore Memory가 자동으로 적절한 전략에 따라 저장

  3. Semantic Memory → 사실 추출 후 벡터화

  4. Summary Memory → 대화 요약 자동 생성

top_k 파라미터와 성능

top_k
장점
단점

1

빠름, 가장 관련성 높은 결과

정보 누락 가능

3 (현재)

균형 잡힌 성능

적당한 컨텍스트 크기

10

풍부한 컨텍스트

프롬프트 길이 증가, 비용 증가

크로스-세션 검색 패턴

토론 질문

  1. 네임스페이스를 더 세분화하면 (예: facts/dns, facts/connectivity) 검색 성능이 향상될까요?

  2. top_k=3에서 중복된 결과가 반환될 수 있나요?

  3. save_conversation이 호출될 때마다 벡터 임베딩이 새로 생성되나요?

마지막 업데이트