AI 장면 재작성을 제약된 상태 변화로 다루기

고지: 저는 Laper를 구축하고 있습니다. 이 기사는 AI의 도움을 받아 생성되었습니다. 아래 워크플로우는 독립적인 디자인 예시이며, 출시된 제품 동작이나 측정된 결과를 설명하는 것은 아닙니다.

AI 재작성은 모든 문장을 개선할 수 있지만 다음 장면을 망가뜨릴 수도 있습니다. 글쓰기 도구를 개발하는 개발자에게 이것은 평가 문제입니다: 유창성이 작가의 의도를 보존하는 것과 같지 않습니다.

가상의 시나리오 장면을 고려해 보세요. 두 자매가 돌아가신 아버지의 아파트를 정리하고 있습니다. 언니는 허락 없이 내일 방문 예약을 잡았습니다. 여동생은 아직 그것을 모릅니다. 마지막에는 그녀가 방문에 동의하지만 여분의 열쇠를 간직합니다.

그녀가 열쇠를 넘겨주는 세련된 재작성은 대화 이상을 변경했습니다. 이제 아파트에 대한 그녀의 통제권을 중심으로 구축되는 나중 장면은 또 다른 검토를 필요로 합니다.

왜 하나의 “품질” 점수가 실패를 놓치는지

리뷰어는 고립된 상태에서 더 화해적인 버전을 선호할 수 있습니다. 하지만 그것이 이 시나리오에 올바른 대체물이라는 것을 의미하지는 않습니다. 적어도 두 가지 질문을 분리해야 합니다: 장면이 잘 읽히는가, 그리고 현재 수정 브리프를 충족하는가?

브리프는 좋은 스토리텔링의 객관적인 정의가 아닙니다. 작가는 그것을 바꿀 수 있습니다. 중요한 부분은 다른 결과를 스타일 개선으로 조용히 취급하는 대신, 그 결정을 명시적으로 만드는 것입니다.

1. 수정 계약(revision contract)을 산문과 분리하여 저장하기

작가가 승인한 작고의 기록만으로 충분합니다. 다음은 생산 스키마가 아닌 예시적인 JSON입니다:

{
  "sceneId": "apartment-07",
  "revisionGoal": "언니의 요청을 덜 직접적으로 만들기"
...

원본 장면, 계약 버전, 그리고 후보 재작성을 함께 보관합니다. 나중에 누군가가 계약을 편집하더라도, 이전 검토가 새로운 요구 사항을 유효화하는 것처럼 보여서는 안 됩니다.

이것은 완전한 캐릭터 데이터베이스보다 의도적으로 작습니다. 이 수정에 필요한 사실들을 기록할 뿐, 가상의 세계의 모든 사실을 기록하지는 않습니다.

2. 증거를 요구하고, 스스로 승인하는 패스는 금지하기

별도의 검토 단계(review step)를 통해 후보(candidate)가 각 요구사항과 비교될 수 있습니다. 관련 구절을 인용하여 제시하고 세 가지 상태 중 하나(supported, contradicted, unclear)를 반환하도록 요청합니다.

예를 들어, “그녀가 열쇠를 여동생의 손바닥에 떨어뜨린다”는 필수적인 최종 상태와 모순됩니다(contradicts). “그들이 문을 본다”라는 내용은 누가 열쇠를 가지고 있는지 확립하지 못하므로, 증거를 지어내기보다는 불분명하다(unclear)로 표시해야 합니다.

이러한 라벨은 벤치마크 결과가 아닌 제안된 검토 결과입니다. 모델이 생성한 확인 과정은 함의(implication), 비꼬는 말(sarcasm), 또는 신뢰할 수 없는 화자(speaker)를 놓칠 수 있습니다. 이를 자동 승인 게이트가 아니라 작가가 검사해야 할 주장들의 대기열로 취급하십시오. 검토자가 증거를 지적할 수 없다면, 그 불확실성을 보여주어야 합니다.

3. 패치를 수락하기 전에 경계를 검토하기

원래 장면과 제안된 대체본을 나란히 보여주고, 이어서 다음 장면의 시작 부분을 제시해야 합니다. 작가는 원본을 덮어쓰지 않으면서 후보를 수락하거나 거부하거나 수정할 수 있어야 합니다.

아파트 예시의 경우, 다음 장면이 여동생이 여전히 열쇠를 가지고 있다고 가정하는지 확인하십시오. 또한 그녀가 관람 사실을 알게 되는 시점도 확인해야 합니다. 만약 작가가 의도적으로 다른 출처를 확립하지 않았다면, '내일'이라는 단어를 언급하는 구절은 지식 유출(knowledge leak)일 수 있습니다.

구조적 검토는 의미론적 검토와 분리하여 진행하십시오. 소프트웨어는 출력에 필수 필드나 유효한 상태 값을 포함하는지 확인할 수 있습니다. 하지만 그것이 시나리오 해석이 정확하다는 것을 증명하지는 못합니다.

아주 작은 평가 세트를 시도해보기

자동화를 추가하기 전에, 같은 장면에 대해 손으로 작성된 세 가지 후보(candidate)를 준비하십시오: 간략한 내용을 보존하는 것, 열쇠를 건네주는 것, 그리고 열쇠의 위치를 모호하게 남겨두는 것입니다. 인간이 관련 구절에 라벨을 지정한 후, 검토자의 출력을 해당 라벨과 비교해 보세요.

이 작은 세트는 검토 설계의 명백한 약점을 노출할 수 있습니다. 일반적인 신뢰성을 확립할 수는 없습니다. 더 광범위한 주장을 하기 전에 다양한 장면과 실패 유형을 추가하고, 인간의 검토를 승인 경로에 유지해야 합니다.

유용한 질문은 단순히 “이 재작성이 더 나은가?”가 아닙니다. 그것은 “무엇이 바뀌었는지, 어떤 증거가 그 읽기를 뒷받침하는지, 그리고 작가가 의도했는지”입니다. 그러한 질문들을 노출시키는 글쓰기 도구는 사용자에게 자신감 있는 점수보다 더 유용한 무언가를 제공합니다.