Skip to content

howSTMBworks-ko.md

Latest commit

 

History

History
368 lines (264 loc) · 14.2 KB

howSTMBworks-ko.md

File metadata and controls

368 lines (264 loc) · 14.2 KB
Raw

SillyTavern 메모리 북(STMB)의 작동 방식

이 문서는 STMB가 어떻게 작동하는지에 대한 높은 수준의 설명입니다. 코드를 설명하려는 문서가 아닙니다. 대신 STMB가 어떤 정보를 조합하는지, 어떤 순서로 보내는지, 그리고 모델이 무엇을 반환해야 하는지를 설명합니다.

이 문서는 STMB용 프롬프트를 작성하거나 수정할 때 참고하는 용도입니다.

STMB의 3가지 주요 프롬프트 흐름

STMB에는 세 가지 주요 워크플로가 있습니다.

  1. 메모리 생성
  2. 트래커 & 사이드 프롬프트
  3. 통합

서로 관련은 있지만, 기대하는 출력 형태는 서로 다릅니다.

  • 메모리 생성은 엄격한 JSON을 기대합니다.
  • 트래커 & 사이드 프롬프트는 보통 정리된 일반 텍스트를 기대합니다(Markdown이나 다른 로어북 항목 형식은 사용할 수 있지만, 사이드 프롬프트에는 JSON을 사용하지 마세요).
  • 통합도 엄격한 JSON을 기대하지만, 메모리와는 다른 스키마를 사용합니다.

I. 메모리 생성

메모리를 만들 때 STMB는 보통 다음 요소들을 이 순서대로 조합한 하나의 프롬프트를 보냅니다.

  1. 선택된 메모리 프롬프트 또는 사전 설정 텍스트

    • 이는 요약 프롬프트 관리자의 지시 블록입니다.
    • 어떤 종류의 요약을 써야 하는지, 어떤 JSON 형태로 반환해야 하는지를 모델에 알려줍니다.
    • {{user}}, {{char}} 같은 매크로는 전송 전에 해석됩니다.

  2. 선택적인 이전 메모리 문맥

    • 실행 시 이전 메모리를 포함하도록 설정되어 있으면, 그것들이 읽기 전용 문맥으로 삽입됩니다.
    • 이것들은 문맥이라고 분명히 표시되며, 다시 요약해야 할 대상이 아닙니다.

  3. 현재 장면 대화 기록

    • 선택된 채팅 범위는 Speaker: message 형식으로 줄마다 정리됩니다.
    • 이것이 모델이 실제로 메모리로 바꿔야 하는 장면입니다.

대략적인 형태는 이렇습니다.

[memory prompt / preset instructions]

=== PREVIOUS SCENE CONTEXT (DO NOT PROCESS) ===
[zero or more earlier memories]
=== END PREVIOUS SCENE CONTEXT - PROCESS ONLY THE SCENE BELOW ===

=== SCENE TRANSCRIPT ===
Alice: ...
Bob: ...
=== END SCENE ===

모델이 반환해야 하는 것

우리가 기대하는 것은 하나의 JSON 객체입니다.

{
  "title": "Short scene title",
  "content": "The actual memory text",
  "keywords": ["keyword1", "keyword2", "keyword3"]
}

모범 사례:

  • JSON 객체만 반환하세요.
  • 키는 정확히 title, content, keywords를 사용하세요.
  • keywords는 문자열로 이루어진 실제 JSON 배열이어야 합니다.
  • 제목은 짧고 읽기 쉽게 유지하세요.
  • 키워드는 장소, 사물, 고유명사, 특징적인 행동, 식별자처럼 구체적이고 검색에 유리하게 만드세요.

STMB가 약간 지저분한 출력은 가끔 복구해 줄 수는 있지만, 프롬프트가 그것에 의존해서는 안 됩니다.

좋은 메모리 프롬프트를 만드는 요소

좋은 메모리 프롬프트는 네 가지를 분명하게 해 줍니다.

  1. 어떤 종류의 메모리를 써야 하는지 말해 준다

    • 상세한 장면 로그
    • 압축된 시놉시스
    • 최소한의 요약
    • 문학적인 서술형 메모리

  2. 무엇이 중요한지 말해 준다

    • 스토리 비트
    • 결정
    • 캐릭터 변화
    • 드러난 사실
    • 결과
    • 연속성에 중요한 세부 사항

  3. 무엇을 무시해야 하는지 말해 준다

    • 보통 OOC
    • 군더더기
    • 더 타이트한 메모리를 원한다면 분위기만 있는 잡담

  4. 정확히 어떤 JSON을 반환해야 하는지 말해 준다

약한 메모리 프롬프트가 되는 이유

약한 프롬프트는 보통 다음 중 하나의 방식으로 실패합니다.

  • 글쓰기 스타일은 설명하지만 JSON 형태는 설명하지 않는다.
  • 최종 메모리 객체 대신 "도움이 되는 분석"이나 "생각"을 요구한다.
  • 구체적인 검색 키워드 대신 추상적인 키워드를 권장한다.
  • 이전 문맥과 현재 장면을 구분하지 않는다.
  • 한 번에 너무 많은 출력 형식을 요구한다.

메모리용 프롬프트 작성 실전 조언

  • 요약이 철저해야 하는지, 토큰 효율이 우선인지 분명하게 쓰세요.
  • content 안에 markdown을 원한다면 그 점을 명확히 말하세요.
  • 짧은 메모리를 원한다면 JSON 스키마가 아니라 본문 길이를 제한하세요.
  • 검색 성능을 강하게 원한다면, 요약 스타일보다 키워드 품질에 프롬프트 공간을 쓰세요.
  • 이전 메모리는 다시 써야 할 원문이 아니라 연속성 문맥으로 취급하세요.

II. 트래커 & 사이드 프롬프트

사이드 프롬프트는 메모리가 아닙니다. 이것들은 보통 별도의 로어북 항목을 작성하거나 덮어쓰는 추적기/업데이트 프롬프트입니다. 이는 메모리와는 완전히 다른 개념이며, 이 점을 분명히 기억하는 것이 매우 중요합니다.

사이드 프롬프트가 실행될 때 STMB는 보통 다음 요소들을 이 순서대로 조합합니다.

  1. 사이드 프롬프트의 메인 지시 텍스트

    • 이것이 그 트래커의 실제 작업 프롬프트입니다.
    • {{user}}, {{char}} 같은 ST 표준 매크로가 해석됩니다.
    • 수동 실행 시 사용자 정의 런타임 매크로도 삽입될 수 있습니다.

  2. 선택적인 기존 항목

    • 그 사이드 프롬프트에 이미 저장된 내용이 있다면, STMB는 현재 버전을 먼저 포함할 수 있습니다.
    • 이렇게 하면 모델이 매번 처음부터 새로 쓰는 대신 기존 트래커를 갱신할 수 있습니다.

  3. 선택적인 이전 메모리 문맥

    • 템플릿이 이전 메모리를 요구하면, STMB는 그것들을 읽기 전용 문맥으로 삽입합니다.

  4. 컴파일된 장면 텍스트

    • 이것이 트래커가 반응해야 하는 현재 장면 자료입니다.

  5. 선택적인 응답 형식 안내

    • 이것은 파서 스키마처럼 강제되는 것이 아닙니다.
    • 단지 어떤 출력 형식을 원하는지에 대한 추가 지시일 뿐입니다.

대략적인 형태는 이렇습니다.

[side prompt instructions]

=== PRIOR ENTRY ===
[existing tracker text, if any]

=== PREVIOUS SCENE CONTEXT (DO NOT PROCESS) ===
[optional previous memories]
=== END PREVIOUS SCENE CONTEXT ===

=== SCENE TEXT ===
[compiled scene text]

=== RESPONSE FORMAT ===
[optional format guidance]

모델이 반환해야 하는 것

STMB는 저장 가능한 일반 텍스트를 기대합니다.

여기서 메모리와의 핵심 차이가 드러납니다.

  • 사이드 프롬프트는 JSON을 원하지 않습니다.
  • STMB는 보통 반환된 텍스트를 그대로 저장합니다.
  • 사이드 프롬프트에서 JSON을 요구하더라도, 그것은 당신의 워크플로가 따로 그 형식에 의존하지 않는 한 그냥 텍스트일 뿐입니다.

즉, 사이드 프롬프트는 파서 친화적인 메모리 JSON이 아니라 실제로 바로 쓸 수 있는 최종 출력물을 목표로 해야 합니다.

좋은 사이드 프롬프트를 만드는 요소

좋은 사이드 프롬프트는 범위가 좁고, 안정적이며, 갱신하기 쉽습니다.

예시:

  • 등장인물 목록을 중요도 순으로 유지한다.
  • 현재 관계 상태를 추적한다.
  • 미해결 플롯 스레드를 추적한다.
  • {{char}}가 현재 {{user}}에 대해 무엇을 믿고 있는지 추적한다.

가장 좋은 사이드 프롬프트 문구는 보통 다음을 해 줍니다.

  1. 작업을 분명히 정의한다

    • "등장인물 트래커를 유지하라"
    • "현재 관계 시트를 갱신하라"
    • "미해결 스레드 보고서를 유지하라"

  2. 갱신인지, 교체인지, 추가인지 말해 준다

    • 기존 항목 텍스트가 포함될 수 있으므로 이 점이 중요합니다.

  3. 출력 레이아웃을 정의한다

    • 제목
    • 글머리표 구조
    • 섹션
    • 정렬 규칙

  4. 무엇을 포함하지 말아야 하는지 말해 준다

    • 추측
    • 중복 항목
    • 오래된 정보
    • 작업 자체에 대한 서술

약한 사이드 프롬프트가 되는 이유

  • 범위가 너무 넓다: "모든 것을 추적하라."
  • 기존 항목을 수정해야 하는지, 다시 써야 하는지를 전혀 말하지 않는다.
  • 최종 트래커 텍스트 대신 사고 과정이나 설명을 요구한다.
  • 형식을 모호하게 남겨 두어서 시간이 지나며 트래커가 흔들린다.

트래커 & 사이드 프롬프트용 프롬프트 작성 실전 조언

  • 사이드 프롬프트는 요약 프롬프트가 아니라 유지보수 지침처럼 작성하세요.
  • 모델이 현재 트래커를 먼저 보고, 그다음 새 장면을 볼 수 있다고 가정하세요.
  • 각 트래커는 하나의 작업에만 집중하게 두세요.
  • 응답 형식 필드를 사용해 레이아웃, 섹션 이름, 정렬 방식을 통제하세요.

III. 통합

통합은 하위 단계 항목들을 더 상위 단계의 요약으로 결합합니다.

예시:

  • 메모리를 아크 요약으로
  • 아크 요약을 챕터 요약으로
  • 챕터 요약을 북 요약으로

통합이 실행될 때 STMB는 보통 다음 요소들을 이 순서대로 조합합니다.

  1. 선택된 통합 프롬프트 또는 사전 설정 텍스트

    • 이것은 모델이 원본 항목들을 어떻게 압축해야 하는지를 설명합니다.
    • 또한 모델이 반환해야 할 JSON 스키마도 정의합니다.

  2. 선택적인 이전 상위 단계 요약

    • 해당 단계의 이전 요약을 이어받는 경우, 그것이 먼저 정사 문맥으로 포함됩니다.
    • 프롬프트는 모델에게 그것을 다시 쓰지 말라고 지시합니다.

  3. 시간순으로 정렬된 선택된 하위 단계 항목들

    • 각 원본 항목은 식별자, 제목, 내용과 함께 포함됩니다.
    • 이것이 모델이 묶고, 압축하고, 상위 단계 요약으로 바꿔야 하는 자료입니다.

대략적인 형태는 이렇습니다.

[consolidation prompt / preset instructions]

=== PREVIOUS ARC/CHAPTER/BOOK (CANON - DO NOT REWRITE) ===
[optional previous higher-tier summary]
=== END PREVIOUS ... ===

=== MEMORIES / ARCS / CHAPTERS ===
=== memory 001 ===
Title: ...
Contents: ...
=== end memory 001 ===

=== memory 002 ===
Title: ...
Contents: ...
=== end memory 002 ===
...
=== END ... ===

모델이 반환해야 하는 것

STMB는 다음과 같은 형태의 JSON 객체를 기대합니다.

{
  "summaries": [
    {
      "title": "Short higher-tier title",
      "summary": "The consolidated recap text",
      "keywords": ["keyword1", "keyword2"],
      "member_ids": ["001", "002"]
    }
  ],
  "unassigned_items": [
    {
      "id": "003",
      "reason": "Why this item was left out"
    }
  ]
}

중요한 개념:

  • 통합은 하나의 요약을 반환할 수도 있고, 여러 개를 반환할 수도 있습니다.
  • member_ids는 반환된 각 요약에 어떤 원본 항목들이 속하는지 STMB에 알려줍니다.
  • unassigned_items는 모델이 "이 항목은 방금 만든 요약에 맞지 않는다"라고 말하는 방식입니다.

좋은 통합 프롬프트를 만드는 요소

좋은 통합 프롬프트는 세 가지를 잘 해냅니다.

  1. 압축 목표를 정의한다

    • 하나의 아크
    • 하나 이상의 아크
    • 간결하지만 완전한 요약
    • 강하게 압축된 요약

  2. 선택 로직을 정의한다

    • 시간 순서 유지
    • 연속성 유지
    • 관련된 항목끼리 병합
    • 관련 없는 항목은 미배정으로 남김

  3. JSON 구조를 매우 분명하게 정의한다

가장 좋은 통합 프롬프트는 무엇을 보존해야 하는지도 말해 줍니다.

  • 주요 비트
  • 전환점
  • 약속
  • 결과
  • 미해결 스레드
  • 관계 변화
  • 연속성에 결정적으로 중요한 인용문이나 식별자

약한 통합 프롬프트가 되는 이유

  • 요약을 요청하지만, 원본 항목을 어떻게 묶을지 전혀 설명하지 않는다.
  • 튀는 항목을 어떻게 처리해야 하는지 말하지 않는다.
  • member_ids를 요구하지 않는다.
  • 통합 JSON 객체 대신 자유 형식 산문을 요구한다.
  • 스타일에만 지나치게 집중하고, 선택과 그룹화 규칙은 충분히 지정하지 않는다.

통합용 프롬프트 작성 실전 조언

  • 하나의 일관된 요약을 원하는지, 아니면 가능한 가장 적은 수의 일관된 요약들을 원하는지 모델에 말하세요.
  • 시간 순서를 요구하세요.
  • 남는 항목을 명시적으로 처리하게 하세요.
  • 여기서도 키워드는 구체적으로 유지하세요. 상위 단계 요약도 여전히 검색 가치가 필요합니다.

진짜 프롬프트 작성 규칙

STMB용 글을 쓸 때는 단지 "AI가 무엇을 말하게 하고 싶은가?"라고 생각하지 마세요.

이렇게 생각하세요.

  1. STMB가 장면 앞에 어떤 문맥을 놓는가?
  2. 실제로 분석되는 자료의 단위는 무엇인가?
  3. 이 경로는 엄격한 JSON을 기대하는가, 아니면 최종 일반 텍스트를 기대하는가?
  4. 나중에 검색을 위해 어떤 정보가 살아남아야 하는가?
  5. 모델이 무엇을 무시하고, 압축하고, 보존하고, 이어받아야 하는가?

프롬프트가 이 다섯 가지 질문에 분명하게 답한다면, 보통 STMB와 잘 맞습니다.

FAQ 형식의 메모

  • "실제로 AI에 무엇이 보내졌는지 볼 수 있나요?" 네. 조합된 프롬프트를 확인하고 싶다면 터미널/로그 출력을 보세요.

  • "내 프롬프트가 약해도 STMB가 좋은 출력을 강제로 만들어 주나요?" 그 정도는 아닙니다. STMB가 가끔 잘못된 JSON을 복구할 수는 있지만, 애초에 잘못된 것을 요구한 모호한 프롬프트까지 고쳐 주지는 못합니다.

  • "프롬프트를 다시 쓸 때 무엇부터 최적화해야 하나요?" 먼저 반환 형식을 최적화하세요. 그다음 어떤 세부 사항을 보존할지 최적화하세요. 스타일은 그다음입니다.