기억은 늘 한 덩어리로 끝나지 않는다. 긴 문서를 나눠 담을 때도 있고, 며칠에 걸친 조사나 여러 단계의 절차를 계속 이어 적을 때도 있다. AiAkiv는 이런 저장들을 스레드로 엮어 나중에 순서대로 따라갈 수 있게 한다.
핵심은 하나다. 잘라내지 말고 이어라.
왜 필요한가
긴 내용을 만나면 흔히 두 가지 잘못을 한다.
- 요약해서 넣는다 → 원문이 사라진다. 나중에 "정확히 뭐라고 했더라"를 되살릴 수 없다.
- 잘라서 앞부분만 넣는다 → 뒷부분이 통째로 없어진다.
기억은 나중에 원문으로 되살릴 수 있어야 값을 한다(저장하기). 그래서 길면 줄이는 게 아니라 나눠서 이어 붙인다.
어떻게 엮이나: prev_event_id
저장 하나가 끝나면 그 기억의 event_id 가 돌아온다. 다음 조각을 저장할 때 그
값을 prev_event_id 로 넘기면, 두 기억이 순서대로 연결된다.
save_memory(summary="1부 …", entities=[…], content="…")
→ event_id: evt_a1b2
save_memory(summary="2부 …", entities=[…], content="…",
prev_event_id="evt_a1b2")
→ event_id: evt_c3d4 (evt_a1b2 뒤에 연결됨)
save_memory(summary="3부 …", entities=[…], content="…",
prev_event_id="evt_c3d4")
외울 필요는 없다. 저장 응답마다 continuation_hint 가 따라오고, 거기에 다음
호출에 넣을 값이 그대로 적혀 있다.
사람은 이렇게 말하면 된다:
ak 이어서 저장해줘
AI가 직전 저장의 event_id를 prev_event_id로 넘겨 알아서 엮는다.
언제 엮나
세 가지 경우다.
- 긴 문서를 나눠 담을 때: 한 번에 안 들어가는 원문을 순서대로 분할.
- 진행 중인 기록: 며칠에 걸친 조사, 이어지는 회의록처럼 흐름이 계속될 때.
- 절차의 N단계: 순서 자체가 의미인 작업 기록.
반대로, 서로 독립된 기억은 엮지 않는다. 관계가 없는데 이어 붙이면 나중에 검색이 엉뚱한 흐름을 따라간다. 연결은 "이건 앞의 그것에 이어지는 내용"일 때만.
자동이 아니다. 서버는 연속 여부를 스스로 판단하지 않는다. 이어지는 저장인지는 사람이나 AI가 판단해서 지시해야 한다. 그래서
ak 이어서 저장해줘같은 한마디가 필요하다.
크기 제한: 넘치면 나눈다
| 항목 | 한도 | 넘치면 |
|---|---|---|
content (원문) |
50,000자 | 분할해서 이어 저장 |
summary (요약) |
500자 | 압축한다 (분할이 답이 아니다) |
content가 한도를 넘으면 서버가 저장을 거부하고, 오류 메시지가 이 분할 방식을
안내한다. 그때 잘라내지 말고 나눠서 다시 저장하면 된다.
주의할 구분이 하나 있다. 요약이 길다고 나누는 게 아니다. 요약이 500자를 넘는다는 건 요약이 장황하다는 뜻이니 짧게 줄이면 된다. 분할·연결은 원문이 클 때만 쓰는 장치다.
검색에서 어떻게 쓰이나
엮어 둔 기억은 검색 결과의 연결 지도(hint) 에 하나의 흐름으로 나타나고, 회수할 때 체인을 따라 앞뒤를 이어 볼 수 있다(검색하기). 3부작으로 나눠 저장한 문서 중 2부가 검색에 걸리면, 1부와 3부로 이어지는 길이 함께 보인다.
나눠 담되 흐름은 잃지 않는 게 이 장치의 목적이다.
주의사항
- 저장 대상이 같아야 한다.
prev_event_id가 지금 저장하는 곳(같은 팀·프로젝트 범위)의 살아 있는 기억이 아니면 무시된다: 연결 없이 저장만 된다. 저장 위치는 팀과 프로젝트 참고. - 순서대로 저장한다. 1부 → 2부 → 3부 순으로, 각 호출에 직전 저장의
event_id를 넘긴다. - 각 조각도 제대로 된 기억이어야 한다. 조각마다 요약·엔티티·태그를 채운다. "2부"만 검색에 걸려도 그것만으로 읽을 수 있어야 한다(저장하기).