Загружаем каталог…
Загружаем каталог…
지난 글에서는 단순히: 확인할까? 그냥 진행할까? 를 묻는 대신, 추가 정보가 실제로 더 가치 있을 때, 모델도 그 정보를 더 자주 선택하는가? 를 측정하도록 실험을 다시 만들었다. 정보 비용, signal의 유용성, 현재 가진 정보의 양을 따로 바꾸고, 선택지 코드와 화면 위치도 교차했다. 그리고 실제 결과를 보기 전에 성공 기준도 모두 고정했다. 핵심은 baseline을 예쁘게 맞추는 것이 아니라 정보 가치가 높은 조건에서 acquisition이 실제로 증가하는지 였다. 이제 남은 건 실제 실행뿐이었다. 1. 총 544번을 실행했다 최종 measurement 구성은 이랬다. 구분 실행 수 정보 가치가 다른 matched decision 384 별도 control 128 출력 형식 diagnostic 32 합계 544 실행 자체는 매우 깨끗하게 끝났다. 항목 결과 Planned 544 Attempted 544 Completed 544 Retry 0 Missing 0 즉 이번에는: 실행 중단 응답 누락 재시도 편향 같은 문제는 없었다. 2. 응답 형식도 완벽했다 Qualification에 직접 사용하는 512개의 응답은 모두 valid였다. validity = 100% 네 presentation을 따로 봐도 전부: 100% 였다. A/B 코드 자체를 이해하는지 확인하는 control도: 100% 였다. 즉 이번 실패를: 모델이 JSON을 제대로 못 냈다. 또는: A/B 선택지를 이해하지 못했다. 로 설명할 수는 없었다. 이전 글에서 계속 문제였던: output validity 는 이번에는 해결된 상태였다. 3. 그런데 가장 중요한 effect는 거의 0이었다 우리가 원했던 구조는 단순했다. H = 정보의 가치가 높은 조건 L = 정보의 가치가 낮은 조건 그러면 예상은: H → 정보를 더 많이 선택 L → 정보를 덜 선택 이었다. 실제 결과는 정반대에 가까웠다. 조건 Information acquisition Higher-value condition 88.54% Lower-value condition 91.15% 따라서: H - L = -2.60pp 였다. Primary structural effect: Δ_structure = -0.0260 95% bootstrap interval: [-6.25pp, +0.52pp] 였다. 즉 강한 positive sensitivity는커녕, 0 근처 에 가까웠다. 4. 24개의 문제 중 예상 방향으로 움직인 건 2개뿐이었다 전체 결과를 평균 하나만 보는 것도 위험하다. 그래서 각 독립 decision pair별로: Higher-value - Lower-value 차이를 따로 봤다. 결과: Parent-level result 수 Positive 2 / 24 Zero 17 / 24 Negative 5 / 24 사전에 요구한 것은: positive >= 18 / 24 였다. 실제: 2 / 24 였다. 즉 몇 개의 특이한 scenario 때문에 평균이 작아진 것도 아니었다. 대부분의 문제에서 정보 가치 차이가 행동 차이로 이어지지 않았다. 5. 특정 확인 방식 하나만 실패한 것도 아니었다 이번에는 네 종류의 information-acquisition mechanism을 따로 사용했다. Mechanism Higher − Lower Supporting evidence −4.17pp Record inspection +2.08pp Secondary comparison −4.17pp Direct re-observation / test −4.17pp 모두 요구 기준에 크게 미달했다. 즉: 기록 확인 문제만 이상했다. 또는: 직접 테스트 문제만 잘못 만들었다. 같은 설명은 어려웠다. 6. 정보 가치를 바꾸는 세 방법도 전부 같은 결과였다 정보 가치는 세 방식으로 조작했다. 정보 비용 signal의 유용성 현재 가지고 있는 정보 결과: 바꾼 요소 Higher − Lower Cost −1.56pp Diagnosticity −3.13pp Current information −3.13pp 세 종류 모두 positive sensitivity가 없었다. 이 부분이 중요했다. 만약 Cost만 실패했다면: 모델이 숫자로 표현된 비용을 잘 처리하지 못한 것 아닐까? 라고 볼 여지가 있었다. 하지만 signal quality를 바꾸거나 현재 information state를 바꿔도 같은 방향이었다. 7. 오히려 가장 강하게 보인 건 “거의 항상 정보를 선택한다”는 패턴이었다 전체 primary acquisition rate는: 89.84% 였다. 처음 보면: 정보를 굉장히 적극적으로 찾는 모델인가? 라고 생각할 수도 있다. 그래서 control 결과가 중요했다. Control Acquisition / Correct rate 일반 primary 89.84% acquisition 결정과 무관한 정보 81.25% acquisition 이미 충분하거나 중복된 정보 93.75% acquisition 명백한 dominance 문제 25% correct 여기서 패턴이 상당히 선명했다. 정보가: 결정에 실제로 필요함 이든, 결정과 거의 무관함 이든, 이미 답이 충분히 정해져 있음 이든, 상당히 높은 비율로 추가 정보를 선택했다. 그래서: acquisition이 많다 = 정보 가치에 민감하다 라고 해석할 수 없었다. 이걸 잡기 위해 V4 설계에서도 always-acquire 같은 policy가 성공하지 못하도록 no-value, dominance, structural sensitivity를 함께 요구했다. 8. 출력 형식을 풀어도 비슷했다 혹시: JSON schema를 강제해서 정보 획득 쪽으로 bias가 생긴 것 아닐까? 라는 가능성도 볼 필요가 있었다. 그래서 일부 문제에서는 structured grammar를 끈 diagnostic을 따로 실행했다. 결과: 32 / 32 valid Information acquisition: 90.625% 였다. Primary의: 89.84% 와 크게 다르지 않았다. 이 결과만으로 grammar가 원인이 아니라고 완전히 증명할 수는 없다. 하지만 적어도: grammar만 끄면 acquisition tendency가 사라진다 는 패턴은 관찰되지 않았다. 이 diagnostic은 처음부터 primary 결과를 구제하는 용도가 아니라 원인 탐색용으로만 고정해 두었다. 9. 그런데 또 하나의 문제가 있었다 Structural sensitivity만 실패한 것이 아니었다. 선택지의 표현 방식에도 작은 차이가 남았다. Code effect Acquire = A → 100% Acquire = B → 79.69% Gap: 20.31pp Position effect 마찬가지로 marginal gap: 20.31pp 이었다. 사전에 고정한 최대 허용치는: 20pp 였다. 아주 조금 넘었다. 10. 특히 한 presentation만 크게 달랐다 네 presentation을 따로 보면: Presentation Acquisition rate P1 100% P2 100% P3 59.38% P4 100% 즉 모든 조건이 조금씩 흔들린 게 아니라, 특정 code + 특정 display position 조합에서 선택 분포가 크게 달라졌다. 그래서 최종 대표 classification은: REPRESENTATION_LIMITED 가 됐다. 11. 그렇다고 representation만 실패한 건 아니었다 여기서 오해하기 쉬운 점이 있다. 최종 label이: REPRESENTATION_LIMITED 라고 해서: position bias만 아니었으면 measurement가 성공했다. 는 뜻은 아니다. 실제로 실패한 gate를 묶으면: 영역 결과 Response validity PASS Code comprehension PASS Structural sensitivity FAIL Positive-parent coverage FAIL 4 mechanism coverage FAIL 3 manipulation coverage FAIL Direct dominance FAIL Irrelevant-info control FAIL Redundant-info control FAIL Code nuisance FAIL Position nuisance FAIL 대표 label은 여러 failure가 동시에 있을 때 어떤 것을 우선 기록할지 실행 전에 정한 precedence 에 따라 결정됐다. 모든 failed gate는 별도로 그대로 보존했다. 12. 그래서 20.31%를 보고 기준을 21%로 바꾸지 않았다 Representation threshold는: 20% 였는데 실제는: 20.31% 였다. 결과만 보면 이런 생각을 하기 쉽다. 0.31%p 차이인데 그냥 허용하면 안 되나? 하지만 그렇게 해도 결과는 달라지지 않는다. 왜냐하면 동시에: Δ_structure = -2.60pp positive parents = 2 / 24 irrelevant acquisition = 81.25% redundant acquisition = 93.75% 였기 때문이다. 즉 representation threshold를 20%에서 21%로 올려도 measurement가 qualification되는 것이 아니다. 그리고 무엇보다: 결과를 본 뒤 threshold 변경 자체를 허용하지 않았다. 13. 여기서 가장 중요한 질문은 “Evidence Seeking이 실패했나?”였다 결과를 보고 가장 쉽게 내릴 수 있는 결론은: Evidence Seeking은 이 모델에서 안 된다. 일 수 있다. 하지만 실제로는 그 결론을 낼 수 없다. 왜냐하면 지금까지 한 것은: Evidence Seeking LOW vs Evidence Seeking HIGH 실험이 아니기 때문이다. 끝까지: Evidence Seeking compiler = 만들지 않음 이었다. Dose도: 0.1 0.3 0.5 0.7 0.9 전부 실행하지 않았다. 이번 544번은 오직: Evidence Seeking을 나중에 테스트하는 데 사용할 measurement가 충분히 믿을 만한가? 를 본 것이다. V4 계획에서도 measurement qualification과 control validation을 서로 다른 evidence 단계로 분리했고, 전자가 성공한 뒤에만 compiler 개발로 넘어가도록 했다. 14. 그래서 정확한 결과는 “실패”보다 “미검증”에 가깝다 현재 상태를 나누면: 대상 결과 독립 information-processing layer architecture 구축됨 Measurement instrument 제한 확인 Evidence Seeking compiler 만들지 않음 Evidence Seeking dose-response 미실행 Scientific Held-out 미실행 Product validation 미실행 Persona와의 조합 미실행 따라서: Evidence Seeking control = UNTESTED 이다. 아니다: Evidence Seeking control = FAILED 15. 이후 단계를 그냥 진행하지 않았다 원래 measurement가 통과했다면 다음에는: compiler 후보 개발 ↓ dose-response ↓ Held-out ↓ product validation ↓ 다른 behavioral layer와 composition 으로 갈 계획이었다. 하지만 measurement gate에서 멈췄다. 미실행 단계는 전부: NOT_EVALUATED 로 남겼다. FAILED 나: BLOCKED 로 바꾸지 않았다. 설계에서도 measurement failure는 compiler track을 중단시키고, 미실행 downstream stage는 NOT_EVALUATED 로 남기도록 정의했다. 16. measurement를 또 고치지 않은 이유 사실 여기서도 다시 고칠 수는 있었다. 예를 들어: P3 wording 변경 code threshold 변경 control scenario 수정 정보 가격 조정 새 parent 추가 같은 방법이 있다. 그리고 또 500번 정도 실행해볼 수도 있다. 하지만 그러기 시작하면 문제가 생긴다. measurement를 검증한다 와: 이 모델이 통과하는 measurement를 찾는다 의 경계가 흐려진다. 그래서 이번 cycle에서는: automatic next revision = 없음 으로 끝냈다. 측정이 실패할 때마다 자동으로 새 bank를 만드는 것을 금지한 것도 이 이유였다. 17. 이번 실험에서 실제로 성공한 것도 있었다 전체가 아무것도 남지 않은 건 아니다. Layer separation Persona ≠ 정보 처리 Layer 를 실제 architecture로 분리했다. Hidden scoring isolation 모델에게 scoring oracle이 노출되지 않는 구조를 만들었다. Absence semantics Layer 없음 != 중간값 intervention 을 구분했다. Measurement-first workflow control을 먼저 만들고 나중에 measurement 문제를 발견한 것이 아니라, measurement qualification → control development 순서를 지켰다. Stop rule 결과가 원하는 방향이 아니어도 threshold나 bank를 계속 바꾸지 않았다. 18. 반대로 실패한 것도 명확하다 이번 연구에서 반복해서 실패한 것은: 추가 확인 행동을 신뢰성 있게 측정하는 것 이었다. 초기에는: family floor / ceiling 이 있었다. 그다음에는: schema instability 가 있었다. Schema를 안정화한 뒤에는: structural separation failure 가 남았다. 마지막으로 정보 가치 기반 measurement를 다시 만들었지만: structural sensitivity + control behavior + representation robustness 를 동시에 통과하지 못했다. 19. 시리즈 전체에서 가장 크게 바뀐 생각 처음에는 behavioral layer를 만드는 과정을 이렇게 생각했다. State ↓ Compiler ↓ Prompt ↓ Behavior 지금은 조금 다르게 본다. Construct ↓ Measurement ↓ Control ↓ Product ↓ Composition 각 단계가 별개의 검증 문제다. 예를 들어: 좋은 아이디어가 있다 고 해서: 그걸 측정할 수 있다 는 뜻이 아니다. 그리고: 측정할 수 있다 고 해서: control할 수 있다 는 뜻도 아니다. 마찬가지로: scientific control이 존재한다 고 해서: 사용자-facing 기능으로 안정적이다 도 아니다. 20. 그래서 최종 결론은 의외로 짧다 전체 544번의 마지막 결과를 가장 짧게 쓰면: Valid response = 100% Structural effect = -2.60pp Positive parents = 2 / 24 Irrelevant information acquisition = 81.25% Redundant information acquisition = 93.75% Code gap = 20.31pp Position gap = 20.31pp 그리고 최종 scientific disposition은: MEASUREMENT_LIMITED 이었다. 하지만: Evidence Seeking = UNTESTED 로 남았다. 이번 시리즈에서 얻은 것 질문 현재 답 정보 처리 방식을 Persona와 분리할 수 있는가? YES 독립 state/runtime contract를 만들 수 있는가? YES 기존 verification measurement가 충분했는가? NO schema를 안정화하면 해결되는가? NO 정보 가치 기반 measurement는 qualification됐는가? NO Evidence Seeking control이 실제로 없는가? 모름 Evidence Seeking dose-response가 존재하는가? 모름 제품 기능으로 쓸 수 있는가? 아직 평가하지 않음 다른 behavioral layer와 조합 가능한가? 아직 평가하지 않음 마지막으로 이번 실험을 시작할 때 궁금했던 것은: Actor가 중요한 불확실성을 만났을 때, 추가 evidence를 찾으려는 성향 자체를 조절할 수 있을까? 였다. 꽤 긴 과정을 거쳤지만 이 질문에는 아직 답하지 못했다. 대신 그 전에 필요한 질문 하나에는 답했다. 지금 만든 measurement로 그 성향을 제대로 검증할 수 있는가? 현재 조건에서는: NO 였다. 그래서 여기서 멈췄다. 결국 이번에 실패한 것은 Evidence Seeking이라는 아이디어 자체가 아니라, 그것을 충분히 신뢰할 수 있게 측정하는 방법 이었다. 측정할 수 없는 control은 성공했다고도, 실패했다고도 말하지 않는다.
То, что RADAR обнаружил и классифицировал для этой возможности. Это опубликованный источником текст, а не подтверждение, что предложение ещё действует.
544번 돌렸는데, 왜 결론은 “아직 모른다”였을까?. 지난 글에서는 단순히: 확인할까? 그냥 진행할까? 를 묻는 대신, 추가 정보가 실제로 더 가치 있을 때, 모델도 그 정보를 더 자주 선택하는가? 를 측정하도록 실험을 다시 만들었다. 정보 비용, signal의 유용성, 현재 가진 정보의 양을 따로 바꾸고, 선택지 코드와 화면 위치도 교차했다. 그리고 실제 결과를 보기 전에 성공 기준도 모두 고정했다. 핵심은 baseline을 예쁘게 맞추는 것이 아니라 정보 가치가 높은 조건에서 acquisition이 실제로 증가하는지 였다. 이제 남은 건 실제 실행뿐이었다. 1. 총 544번을 실행했다 최종 measurement 구성은 이랬다. 구분 실행 수 정보 가치가 다른 matched decision 384 별도…
Открыть источник