기존의 소프트웨어에는 두 가지 상태가 있습니다. 작동했거나, 작동하지 않는다고 알려주거나입니다. 언어 모델 (Language Model)을 기반으로 구축된 기능에는 세 번째 상태가 존재하며, 이 세 번째 상태가 바로 전체 학문의 핵심입니다. 무언가를 생성해냈지만, 그 무언가가 잘못되었으며, 시스템 어디에서도 그 사실을 알지 못하는 상태입니다.

변화 (The shift)

결정론적 구성 요소 (Deterministic component)의 계약은 동일한 입력이 동일한 출력을 생성하며, 실패 시에는 신호가 전달된다는 것입니다. 이 두 가지 측면 모두 인터페이스 설계에서 중요한 역할을 합니다. 출력이 반복 가능하기 때문에 이를 사실로서 보여줄 수 있습니다. 또한 실패가 신호로 전달되기 때문에, 성공 상태 옆에 오류 상태를 배치함으로써 두 상태가 모든 상황을 커버한다는 확신을 가질 수 있습니다.

언어 모델은 이 두 가지 중 어느 것도 준수하지 않습니다. 모델은 다음 토큰 (Next tokens)에 대한 확률 분포 (Probability distribution)를 반환하고 무언가가 그 분포에서 샘플링을 수행하므로, 구조적으로 두 개의 동일한 요청은 서로 달라집니다 — 해당 개념의 런타임 정의를 참조하세요. 그리고 틀린 답은 예외 경로 (Exception path)가 아닙니다. 그것은 단지 사실이 아닐 뿐인, 높은 가능성을 가진 연속이며, 정답과 정확히 동일한 유창성, 구조 및 HTTP 상태 코드로 전달됩니다.

이 클러스터의 다른 모든 것들은 그 결과로 나타납니다. 여기서 단 한 가지만 기억한다면 다음과 같습니다: 모델에는 틀렸을 때를 위한 오류 상태 (Error state)가 없다. 따라서 인터페이스가 이를 제공해야 하며, 이를 제공할 수 있는 유일한 존재는 출력을 확인하는 사람뿐입니다.

다섯 가지 속성, 다섯 가지 결과

어떤 속성이 어떤 결정을 강제하는지 구체적으로 명시할 가치가 있습니다. 왜냐하면 이러한 속성 중 하나로 추적할 수 없는 권장 사항은 대개 단순한 취향에 불과하기 때문입니다.

검증 격차 (The verification gap)

AI 기능이 실제로 도움이 될지 여부를 결정하는 하나의 불평등(inequality)이 존재하며, 이는 추상적인 모델 품질과는 아무런 관련이 없습니다. 기능의 가치는 출력을 생성하고 이를 검증하는 비용이 직접 작업을 수행하는 비용보다 적을 때 발생합니다:

생성 시간 (generate_time) + 검증 시간 (verify_time) < 직접 수행 시간 (do_it_yourself_time)

그리고, 별도로 다음과 같은 리스크 항(risk term):
...

두 식 모두 성립해야 합니다. 첫 번째 식은 그럴듯한 800단어 분량의 문서를 생성하는 기능이 왜 순손실(net loss)이 될 수 있는지를 설명합니다. 즉, 그 문서를 신뢰할 수 있을 만큼 주의 깊게 읽는 데 드는 시간이 직접 300단어를 쓰는 시간보다 더 오래 걸리기 때문입니다. 두 번째 식은 컴파일러와 테스트 스위트(test suite)가 무료로 검증해 주는 코드 에디터에서는 승리였던 동일한 모델이, 사람이 숫자가 맞는지 읽어서 검증해야 하는 고객 환불 규모의 상황에서는 왜 부채(liability)가 되는지를 설명합니다.

디자인 작업은 대부분 검증 시간 (verify_time)을 줄이기 위한 공격입니다. 특정 구간에 고정되는 인용(Citations), 문서를 새로 쓰는 대신 차이점만 보여주는 디프(diffs), 문단 형태가 아닌 양식(form)으로 렌더링되는 구조화된 출력(structured output), 그리고 어떤 부분이 근거가 있는지 알려주는 신뢰도 공개(confidence disclosure) — 이 모든 것들은 모델을 더 좋게 만들기 위해서가 아니라, 검증 비용을 낮추기 위해 존재합니다.

두 번째 식은 별도의 주의를 기울일 가치가 있습니다. 왜냐하면 그 식을 지배하는 항은 p_wrong(오답 확률)이 아니기 때문입니다. 팀들은 모델 품질에 대해 논쟁하며 상당한 비용을 들여 그 확률을 몇 퍼센트 포인트 움직이려 노력하지만, 감지되지 않은 오류의 비용 (cost_of_an_undetected_error)은 기능마다 수십 배(orders of magnitude) 차이가 나며, 출력을 어디에 배치하느냐에 따라 완전히 결정됩니다. 동일한 모델이라도 동일한 오류율을 가질 때, 태그를 제안하는 용도로는 좋은 아이디어이지만 가격을 설정하는 용도로는 나쁜 아이디어가 될 수 있습니다. 이는 배치(placement)의 결정이며, 비용이 들지 않으면서도 더 큰 항을 변화시킵니다.

이는 여러분의 로드맵에서 인식할 만한 하나의 패턴을 설명해 줍니다. 모델이 개선되기를 기다리며 두 분기 동안

가역성 (Reversibility)은 설계 변수입니다

잘못된 출력을 방지할 수 없을 때, 그다음으로 최선인 방법은 잘못된 출력을 저렴하게 만드는 것입니다. 이것이 가역성 (Reversibility)이 다른 어떤 종류보다 AI 인터페이스에서 더 많은 역할을 수행하는 이유이며, 무엇인가를 설계하기 전에 모든 AI 기반 동작을 이 기준에 따라 분류할 가치가 있는 이유입니다.

• 가역적이며 비공개적인 (Reversible and private) — 텍스트 박스의 초안, 제안된 재작성 (rewrite), 제안된 필터. 여기서 적절한 확인 마찰 (confirmation friction)의 양은 '제로'입니다. 낙관적으로 배포하고 그 옆에 실행 취소 (undo)를 배치하세요.
• 가역적이지만 공개적인 (Reversible but visible) — 다른 사람들이 볼 수 있는 상태 변경, 재정렬된 보드. 실행 취소 (undo)가 여전히 작동하지만, 인터페이스는 몇 초 이내에 실행 취소를 발견할 수 있도록 만들어야 합니다. 그 이후에는 피해가 기술적인 것이 아니라 사회적인 것이 되기 때문입니다.
• 비가역적인 (Irreversible) — 전송된 이메일, 완료된 결제, 삭제된 행, 게시된 메시지. 모델의 품질이 아무리 높더라도, 실제 효과를 보여주는 명시적인 인간의 확인 (human confirmation) 없이 이러한 작업을 수행하는 것을 정당화할 수는 없습니다. 승인 설계 (approval design)의 모든 영역은 이 행에 속합니다.

이 분류가 아닌 것이 무엇인지 주목하십시오. 이것은 모델이 해당 작업을 얼마나 잘 수행하는지에 대한 판단이 아닙니다. 비가역적인 일을 수행하는 매우 뛰어난 모델이라 할지라도 여전히 확인 (confirmation)이 필요합니다. 왜냐하면 여러분이 설계하는 대상은 꼬리 부분 (tail, 예외 사례)이며, 그 꼬리는 모든 품질 수준에서 존재하기 때문입니다.

이미 출시한 기능을 재분류하기

대부분의 팀은 이미 라이브 상태인 기능을 가지고 이 클러스터에 도달합니다. 다음의 네 가지 질문을 순서대로 던져보십시오. 각 질문에는 구체적인 해결책이 따라옵니다:

• 출력이 어디에 도달하는가? (Where does output land?) 만약 출력이 적용되기 전에 수정할 수 없는 곳에 도달한다면, 그것이 바로 버그입니다. 출력을 초안 상태 (draft state)로 이동시키십시오.
• 사용자가 이를 확인하기 위해 무엇을 하는가? (What does the user do to check it?) 만약 답변이 "읽고 기도하기"라면, 검증 비용 (verification cost)은 무한하며, 해당 기능은 최소한 일부 사용자들에게 위 부등식의 잘못된 쪽에 위치하게 됩니다.
• p95 지연 시간 (p95 latency)에서는 어떤 일이 발생하는가? (What happens at p95 latency?) 중앙값 (median)이 아닙니다. 기능을 실행하고, 40초 동안 아무 일도 일어나지 않는다고 상상하며 화면에 무엇이 떠 있는지 확인하십시오. 40초의 문제 (the forty-second problem)를 참조하십시오.
• 두 번째 시도의 비용은 얼마인가? (What does a second attempt cost?) 비용 측면과 사용자 노력 측면 모두에서 고려하십시오. 만약 재생성 (regenerating)은 클릭 한 번이지만 컨텍스트 (context)를 다시 입력하는 것이 20번의 클릭이라면, 사용자들은 눈에 보이는 방식인 비용이 더 많이 드는 쪽을 선택할 것입니다.

관련 항목 (Related)

• 정밀함을 속이지 않고 신뢰도를 보여주는 법 (Showing Confidence Without Faking Precision)
• 채팅 vs 양식 vs 인라인: AI 상호작용 모델 선택하기 (Chat vs Forms vs Inline: Choosing an AI Interaction Model)
• 실행 취소, 재생성 및 편집: 복구 어포던스 (Undo, Regenerate and Edit: Recovery Affordances)