Lyotic · 운영 기준

평가

계약 검사를 통과한 것, 사람이 더 잘 이해한 것, 실제 외부 시스템에서 안전하게 운영된 것은 각각 다른 주장입니다.

평가의 경계

후속 연구에서 검증 대상을 좁힌 이유는 평가에서도 중요하다. 더 좋은 에이전트, 더 안전한 실행기, 더 많은 증거, 더 잘 만든 UI를 동시에 바꾸면 무엇이 효과를 냈는지 알 수 없다. EBSRC의 효과를 보려면 동일한 권위 있는 상태와 동일한 에이전트 실행 기록, 동일한 허용 행동을 입력으로 두고 표현 방식을 비교할 수 있어야 한다. 결정론적 Resolver와 고정된 agent trace를 사용하는 초기 연구 범위는 이러한 분리를 위한 것이다.

가장 중요한 비교 대상은 제대로 만든 고정형 감독 인터페이스다. 이 인터페이스에도 같은 증거, 권한 정보, 제안, 복구 기능을 제공해야 한다. Lyotic만 중요한 정보를 갖고 있다면 적응형 표현의 효과를 검증한 것이 아니다. Chat-only나 자유도가 높은 generative UI는 다른 비교 조건으로 사용할 수 있지만, 약한 기준선 하나만 이겼다고 해서 Lyotic의 기여가 입증되는 것은 아니다.

백엔드가 차단한 무권한 실행을 UI의 성과로 계산해서도 안 된다. 서버에서 잘못된 작업이 차단되었더라도 사용자가 무엇을 승인했는지 잘못 이해했다면 감독 경험에는 문제가 남는다. 반대로 사용자가 문제를 정확히 알아차렸지만 실행 경계가 무너지면 안전한 시스템이 아니다. 따라서 인터페이스의 이해·개입 효과와 런타임의 집행 효과를 별도로 측정하고, 최종 시스템에서는 둘을 함께 검증해야 한다.

사람 대상 연구에서 측정할 것

사람 대상 연구는 업무 상태 이해, 중요한 판단 지점의 인식, 잘못된 제안의 발견, 적절한 개입, 거짓 완료 믿음, 증거 이해, 감독 부담, 재개와 인계의 정확성, 접근성, 다른 도메인으로의 전이를 다뤄야 한다. 선호와 작업 시간도 중요하지만, 더 빠르게 틀린 결정을 내린 결과를 개선이라고 해석하면 안 된다. 효과 크기와 불확실성, 어떤 조건에서 효과가 없었는지도 함께 보고해야 한다.

적응과 애니메이션도 분리해서 시험할 필요가 있다. 업무에 맞는 표현을 선택하는 것은 도움이 되지만 그 사이의 움직임은 도움이 되지 않을 수 있다. 반대로 동일한 정보라도 객체의 연속성을 유지하는 전환이 인계나 재개에 도움이 될 수 있다. 이런 차이를 확인해야 모핑이 브랜드 장식인지, 이해를 지원하는 인터랙션인지 설명할 수 있다. 어떤 작업에서는 고정된 표현이 더 낫다는 결과도 Lyotic을 정교하게 만드는 근거다.

합성 사용자

후속에 논의한 합성 사용자 앙상블은 사람 대상 연구 전에 이런 시나리오와 인터랙션을 압박하는 단계다. MatrAIx, UXAgent, RealUserSim, TinyTroupe 같은 후보를 같은 업무와 관찰 조건에 연결하되, 각 도구가 실제로 무엇을 보고 무엇을 조작할 수 있는지 먼저 확인해야 한다. 평가자는 정답 상태를 알아도 합성 사용자에게는 해당 역할의 실제 관찰만 제공해야 한다. 그렇지 않으면 인터페이스가 이해를 도운 것이 아니라 정답을 미리 전달한 실험이 된다.

여러 합성 사용자가 동의했다는 사실도 사람의 이해를 입증하지 않는다. 비슷한 모델과 지시문을 사용하면 같은 오해를 반복할 수 있다. 중요한 것은 동의율 자체보다 어느 상태에서 왜 해석이 갈리는지, 어떤 표시가 잘못된 다음 행동을 유도하는지다. 텍스트만 읽는 시뮬레이터는 모핑의 시각적 연속성이나 실제 시선 이동을 검증할 수 없다. 합성 평가는 시나리오와 구현의 결함을 찾는 보조 근거이며, 인간에 대한 효과 주장으로 승격되지 않는다.

현재 하네스의 범위

컴포넌트 검사와 사람 대상 평가 사이에도 구분이 있다. 스키마 검사는 필수 필드와 타입을 확인할 수 있다. 의미 검사는 해당 상태에서 완료 표시나 실행 제어가 허용되는지 확인한다. 시간에 따른 검사는 승인 이후 변경, 늦은 응답, 중지, 재접속 과정에서 계약이 유지되는지 본다. 사람 대상 평가는 그 표현을 사용자가 실제로 이해하고 적절히 개입하는지를 확인한다. 앞의 검사를 통과했다고 뒤의 효과까지 자동으로 성립하지 않는다.

Invariant 테스트는 구체적인 위반을 대상으로 해야 한다. 동일한 Case에 테마만 바꿨을 때 허용 행동이 달라지는지, 대상 revision이 바뀌었는데 이전 승인이 유지되는지, 성공 응답 뒤에 불일치가 관찰되었는데 완료 표시가 남는지, 복구 후 새 세션이 미확정 효과를 잊는지 검사한다. 잘못된 레코드 매칭, 오래된 근거, 숨은 추가 변경, 검증 출처의 부재도 포함한다. 테스트가 관찰할 수 없는 영역은 통과로 처리하지 않고 커버리지의 한계로 남긴다.

정확한 통과·실패는 테스트를 실행한 커밋과 로그에 연결합니다. 문서의 구현 요구사항을 적었다는 사실은 그 요구사항이 모든 경로에서 충족되었다는 결과가 아닙니다.