프로세스를 스토리라인으로 모델링하는 올바른 방법

복잡한 프로세스를 스토리라인으로 전환하는 것은 전사(transcription)가 아닌 모델링 작업입니다. 메커니즘은 스토리라인 컴파일에서 다루며, 이는 결과가 대부분 작동하는 그래프가 아니라 신뢰할 수 있는 결과가 되도록 어떻게 생각해야 하는지에 관한 것입니다.

프로필에서 시작하여 결정 지점을 매핑하세요

노드를 그리기 전에 무엇을 추적할지 결정하십시오 — 이것이 profile_schema(예: docs_ready, risk_flag, attempts)입니다. 그런 다음 행복한 경로(happy path)뿐만 아니라 실제 결정 지점을 매핑하십시오. 대화가 분기하거나 실패할 수 있는 모든 곳은 종료 지점을 가진 노드입니다. 이상적인 경로만 모델링하면 사용자가 예기치 않은 행동을 하는 순간 흐름이 무너집니다.

하나의 노드 = 하나의 일관된 단계

노드는 사람이 명명할 수 있는 한 가지 작업("문서 수집", "신원 확인")을 수행해야 합니다. 전체 하위 프로세스를 단일 노드의 task에 밀어 넣고 모델이 이를 순차적으로 처리하기를 기대하지 마십시오 — 그러면 분기, 재개 및 측정을 할 수 있는 능력을 잃게 됩니다. 노드의 작업에 "그리고 나서, 그리고 나서"가 있다면, 그것은 여러 노드입니다.

결과가 신뢰해야 할 경우 분기를 결정론적으로 만드세요

• 분기가 예측 가능해야 할 경우 rule(프로필 차원 기준) 또는 **user_choice**에 따라 라우팅하십시오. ai 종료 지점은 실제 판단("사용자가 실제로 문제를 설명했는가?")에만 남겨두십시오.
• 종료 지점은 우선순위 기반으로 정렬됩니다 — 결정론적인 것을 먼저, ai 대체안을 마지막에 배치하십시오.
• 백-에지(back-edge)와 writes 카운터(op: "inc") 및 rule 제한을 사용하여 재시도 루프를 모델링하십시오. 모델이 루프를 충분히 돌았다고 결정하는 것에 의존하지 마십시오.

신원 및 안전성은 노드가 아닌 에이전트에 유지하세요

에이전트의 soul과 안전 경계는 전체 스토리라인에 걸쳐 일정합니다 — 그것이 핵심입니다. 매 노드마다 페르소나를 다시 명시하거나 안전을 재적용하려고 하지 마십시오. 노드는 작업/기술/지식/도구를 추가하고 프로필 차원을 기록하는 역할만 합니다.

node_key는 안정적으로 유지하고 게시 전에 검증하세요

node_key는 종료 지점의 신원 및 깔때기 참조입니다. update_storyline으로 편집할 때 이를 안정적으로 유지하십시오 — 노드를 리네임하면 종료 지점이 조용히 고아 상태가 됩니다. publish_storyline 전에 항상 validate_storyline을 실행하십시오 — 이는 도달할 수 없는 노드, 막다른 길 및 고아 종료 지점을 잡아냅니다.

과모델링하지 마세요

작업이 단일 질문과 답변이라면, 그것은 스토리라인이 아닙니다 — 그것은 지식 베이스를 가진 에이전트입니다. 진정한 다단계 상태를 유지해야 할 때(정보 수집, 튜터링, 안내된 신청서 등) 스토리라인을 사용하십시오. 일회성 Q&A를 그래프로 모델링하면 비용과 실패 모드가 추가될 뿐입니다.

흔히 발생하는 오류 (이러한 실수를 피하세요)

• 행복한 경로만 — "사용자가 혼란스러움" 또는 "제공하지 않음"에 대한 종료 지점이 없으므로 흐름이 멈춥니다.
• 모든 것이 ai 종료 지점 — 라우팅이 도박이 됩니다. 동일한 입력이 다른 경로를 따릅니다.
• 메가 노드 — 단일 노드의 task가 전체 프로세스를 설명합니다. 분기하거나 재개할 수 없습니다.
• 무제한 루프 — 카운터나 제한이 없는 백-에지.
• 노드마다 안전성 재선언 — 에이전트의 실제 경계와 경쟁하는 노이즈.

실제 상태를 명명하고 각 결정을 결정론적인 종료 지점으로 이동하여 이러한 문제를 해결하십시오.