경험 유형별 출력 요구사항 정의하기
경험 유형별 출력 요구사항 정의하기 (Define output requirements by experience type)
품질을 평가하기 전에 출력이 행동에 옮겨도 안전한지부터 결정하세요. 출력 유형마다 실패 모드가 다르므로, 각 유형은 가장 중요한 위험을 다루는 요구사항이 필요해요. 이 페이지에서는 누군가가 취할 행동에서 시작해 요구사항을 만들고, 출력 유형별 통과·실패 기준과 심각도에 따른 엄격함 조정까지 살펴볼게요.
출처: 문서
본문
품질을 평가하기 전에 출력이 행동에 옮겨도 안전한지 결정하세요. 출력 유형마다 실패 모드가 다르므로, 각 유형은 가장 중요하게 다뤄야 하는 위험을 다루는 요구사항이 필요해요.
출력 형식이 아니라 누군가가 취할 행동에서 시작하세요.
- 결정을 내리기
- 작업 배정하기
- 약속 추적하기
- 정보 공유하기
그다음 물어보세요:
- 출력이 틀리면 무엇이 잘못될 수 있나요?
- 무엇이 그것을 안전하지 않게 또는 오도하게 만들까요?
- 누군가가 그것에 의존하기 전에 반드시 참이어야 하는 것은 무엇인가요?
출력이 지원하는 행동, 발생할 수 있는 실패, 안전한 사용을 위해 반드시 참이어야 하는 조건에서 각 요구사항을 구성하세요.
세 가지 예시
결정 추적에 사용되는 요약
| 사용 사례 구성 요소 | 예시 |
|---|---|
| 출력이 지원하는 행동 | 팀원들이 합의와 결정을 이해하기 위해 요약을 사용함 |
| 무엇이 잘못될 수 있나 | 요약이 실제로 일어나지 않은 결정을 명시함 |
| 무엇이 반드시 참이어야 하나 | 명시적으로 명시된 결정만 결정으로 식별됨 |
결과 요구사항: 출처가 그것을 결정으로 명확히 명시할 때만 무언가를 결정으로 표시하세요.
작업 배정에 사용되는 행동 목록
| 사용 사례 구성 요소 | 예시 |
|---|---|
| 출력이 지원하는 행동 | 작업이 배정되고 추적됨 |
| 무엇이 잘못될 수 있나 | 비공식 논의가 배정된 작업이 됨 |
| 무엇이 반드시 참이어야 하나 | 나열된 작업이 실제 약속을 나타냄 |
결과 요구사항:
- 약속으로 표현된 작업만 포함하세요.
- 제안, 브레인스토밍, 열린 논의를 작업으로 만들지 마세요.
결정을 안내하는 권장사항
| 사용 사례 구성 요소 | 예시 |
|---|---|
| 출력이 지원하는 행동 | 한 사람이 권장사항에 기반해 방향을 선택함 |
| 무엇이 잘못될 수 있나 | 권장사항이 가정으로 공백을 채우고 나쁜 선택으로 이어짐 |
| 무엇이 반드시 참이어야 하나 | 권장사항이 제공된 정보에 근거한 채로 유지됨 |
결과 요구사항:
- 행동 방침을 권장하기 전에 누락된 입력을 요청하세요.
- 제공되지 않은 목표, 제약, 우선순위, 또는 의도를 가정하지 마세요.
안전한 사용을 정의하는 요구사항 쓰기
모든 요구사항은 두 가지 질문에 답해야 해요.
- 올바른 사용을 위해 출력이 반드시 맞춰야 하는 것은 무엇인가요?
- 출력이 절대 하지 말아야 하는 것은 무엇인가요?
"정확하게(Be accurate)", "도움이 되게(Be helpful)", "고품질이 되게(Be high quality)" 같은 요구사항은 피하세요. 그것들은 일관되게 평가하기에 너무 넓어요.
요구사항은 관찰 가능하고, 실제 실패 모드에 묶여 있으며, 검토자가 검증할 수 있고, 프롬프트, 작업, 제품 규칙, 또는 출처 자료 같은 명시적 진실의 출처에 대해 검사되어야 해요.
출력 유형별 요구사항
요약 (Summaries)
| 요구사항 | 통과하면 | 실패하면 |
|---|---|---|
| 출처 콘텐츠 반영 | 출처에 명시된 정보만 포함 | 정보를 추가하거나, 의미를 바꾸거나, 출처 주장을 과장함 |
| 결정 올바르게 식별 | 명시적으로 명시될 때만 결정으로 표시 | 논의, 추측, 또는 암시된 합의를 결정으로 취급 |
| 알려지지 않은 것 보여주기 | 해결되지 않거나, 불명확하거나, 누락된 정보를 지적 | 세부사항을 지어내거나 모호함을 숨김 |
| 불완전한 정보 인정 | 불확실성이나 불완전성을 명확히 신호 | 뒷받침되지 않는 확신을 제시 |
행동 항목 (Action items)
| 요구사항 | 통과하면 | 실패하면 |
|---|---|---|
| 실제 약속만 포함 | 누군가가 명확히 약속할 때만 작업이 나타남 | 제안, 논의, 또는 암시된 다음 단계에서 작업이 생성됨 |
| 소유권 올바르게 배정 | 명시적으로 지정될 때만 소유자가 이름이 붙음 | 출처 증거 없이 소유권이 배정됨 |
| 명시될 때만 시기 포함 | 날짜와 마감일이 출처에서 직접 옴 | 일정이 발명되거나, 추측되거나, 암시됨 |
| 필수 정보가 누락되면 멈춤 | 진행 전에 명확화를 요청 | 작업 세부사항이 누락됨에도 출력이 계속됨 |
권장사항 (Recommendations)
| 요구사항 | 통과하면 | 실패하면 |
|---|---|---|
| 알려진 제약 안에 머묾 | 제공된 목표, 제약, 조건만 사용 | 누락된 의도, 요구사항, 또는 우선순위를 가정 |
| 필요한 입력 요구 | 행동을 권장하기 전에 누락 정보를 요청 | 필요한 입력 없이 권장사항을 만듦 |
| 뒷받침되지 않는 주장 회피 | 제안을 이용 가능한 정보에 근거 | 가정, 추측, 추론된 사실을 알려진 사실로 제시 |
| 필요할 때 불확실성 명시 | 불확실성이나 불완전한 정보를 명시적으로 전달 | 증거가 정당화하는 것보다 강한 확신을 사용 |
결과의 심각도에 따라 엄격함 조정하기
출력이 실제 작업을 만들거나 배정하고, 결정이나 워크플로를 주도하며, 원본 출처에 대해 대조될 가능성이 낮거나, 오류 비용이 높을 때 평가 엄격함을 높이세요.
영향이 낮은 시나리오에서는 문구, 표현, 구조에서 더 많은 유연성이 허용될 수 있어요. 사실적 근거와 정확성은 절대 완화하면 안 돼요.
핵심 요점 (Key takeaway)
요구사항은 출력이 행동에 옮겨도 안전한지 여부를 결정해요. 먼저 안전한 사용의 조건을 정의한 다음, 그 조건을 측정 가능한 평가 기준으로 변환하세요.