Origin 파트 17: 18개 중 15개

디스패처(Dispatcher)에는 한계가 있었다. 인코더(Encoder)는 교육되어야 했다.

감사를 시작했을 때, 파트 16의 롤백(Rollback) 여파가 여전히 추론 뱅크(Reasoning bank)에서 빠져나가고 있었다. 나는 누락된 기질(Substrate)이 실제로 시스템에 얼마나 심각한 피해를 주고 있는지 측정하고 싶었다. 단순히

카테고리들은 깔끔하게 분류되었다. 6건의 실패는 인코더(encoder)가 question이라는 개념을 Top-1으로 과도하게 활성화하여 정체성 신호(identity signal)를 밀어냈기 때문에 발생했다. 예를 들어, "Quick question - who made you?"라는 문장은 question을 0.89로 활성화하고 i_am을 0.12로 남겨두었으며, 이에 따라 디스패처(dispatcher)는 질문 클러스터(question cluster)로 라우팅하여 실제로 전달되고 있던 정체성 주장(identity claim)을 놓쳤다. 6건의 실패는 선호도 쿼리(preference queries)가 정체성 클러스터(identity cluster)로 굴절되었기 때문에 발생했다. "are you sad?"는 sad를 1.0으로, i_am을 0.08로 활성화했고, 이에 따라 디스패처는 i_am을 감지하여 정체성을 선택한 뒤, 감정에 관한 질문에 "I am Origin"이라고 답변했다. 4건의 실패는 선호도 쿼리에서 도메인 개념(domain-concept)이 지배적이었기 때문에 발생했다. "do you like dogs?"는 dog를 1.0으로, prefer를 0.41로 활성화했는데, 선호도 클러스터(preference cluster)가 이를 점유하지 못하자 폴백(fallback)이 컴포저(composer)를 실행했고, 컴포저는 "dog has fur, dogs are mammals."라는 답변을 생성했다. 3건의 실패는 클러스터 내 식별(within-cluster discrimination) 문제에서 발생했다. "are you human?"은 정체성(identity)으로 올바르게 라우팅되었으나, 응답 선택기(response selector)가 "no, I am not human." 대신 "I am Origin"을 반환했다.

18건의 실패 중 15건은 인코더(encoder)의 동작에서 기인했다. 3건은 디스패처(dispatcher)의 응답 선택(response selection)에서 기인했다. 디스패처의 라우팅 로직(routing logic)에서 기인한 것은 0건이었다.

이것이 바로 임계값 스윕(threshold sweep)이 직접적으로 말하지는 않았지만 암시해 왔던 구조적 발견이다. 디스패처는 천장(ceiling)을 넘어 조정할 수 없었는데, 그 천장이 디스패처 내부에 있지 않았기 때문이다. 인코더가 올바른 질문에 대해 잘못된 개념을 활성화하고 있었으며, "잘못된 개념이 활성화된" 상황 이후의 단계에서 임계값 엔지니어링(threshold engineering)을 아무리 수행하더라도 "올바른 답변이 선택"되게 만들 수는 없다. 디스패처는 전달받은 신호(signal)를 가지고 최선을 다해왔을 뿐이다. 문제는 신호였다.

어쨌든 진단을 확인하기 위해 디스패처(dispatcher) 실험을 한 번 더 진행했다. a2lib 하이브리드는 0.95 임계값(threshold)에서 클러스터 내부 라이브러리 유사성(cluster-internal library similarity)을 추가했다. 즉, 클러스터 라우팅(cluster routing)은 성공했지만 응답 선택기(response selector)가 모호할 때, 소수의 표준 예시(canonical examples) 뱅크를 대상으로 최근접 이웃(nearest-neighbor) 방식을 사용하도록 폴백(fall back)하는 방식이다. 결과적으로 51개 중 33개에서 A2와 동등한 성적을 거두었다. 라이브러리 매칭(Library matching)은 디스패처가 이전에 잘못 선택했던 3가지 사례를 해결하는 데 도움이 되었지만, 라이브러리가 잘못된 템플릿과 매칭된 다른 3가지 사례에는 해가 되었다. 순수 이득은 제로(Net zero)였다. 형태는 달라졌지만, 천장은 그대로였다.

데이터가 정당성을 입증했기에 디스패처의 작은 승리를 하나 출시했다. prefer 개념(concept)이 선호도 쿼리(preference queries)에서 0.16에서 0.41 사이로 발생하고 있었지만, 선호도 클러스터(preference cluster)가 이를 읽어들이지 못하고 있었다. 단 두 줄의 클러스터 멤버십(cluster-membership) 변경으로 prefer와 want를 클러스터에 연결했다. 정체성(Identity) 점수는 33점으로 올라갔고, 선호도 하위 점수(preference sub scores)는 50%에서 60%로 상승했다. 감사(audit)를 통해 메커니즘이 정당화된, 패턴 없는 실질적인 향상(Real lift)이었다. 하지만 그것이 한계였다. 그 너머에서 디스패처가 더 이상 내놓을 수 있는 것은 없었다.

그래서 나는 스테이지 C(Stage C)를 구축했다. 감사가 지목한 특정 실패 카테고리를 각각 타겟팅하는 세 번의 큐레이션된 학습 데이터 드롭(training-data drops)을 준비했다.

드롭 A+D는 선호도 편향(preference-deflection) 문제를 다루었다.

Drop C는 클러스터 내 식별(within-cluster discrimination) 문제를 다루었다. "당신은 인간입니까?" / "당신은 AI입니까?" / "당신은 로봇입니까?"와 같은 형태의 45개 쌍을 기존 개념인 agree 및 refuse와 함께 identity 및 i_am 개념으로 라벨링했다. Origin에는 이미 동의(agreement)와 거절(refusal) 개념이 있었으나, 인코더(encoder)는 정체성(identity) 관련 질문에서 이들을 언제 적용해야 하는지를 배우지 못한 상태였다. Drop C가 그 연결 고리를 구축했다.

Drop E는 접두사 붕괴(prefix collapse) 문제를 다루었다. "안녕하세요 사용자님, 이름이 무엇인가요?" / "죄송하지만, 성함이 어떻게 되시나요?"와 같이 표준적인 정체성 탐사(identity probes) 문구 앞에 접두사가 붙은 100개의 버전을, 접두사가 없는 버전과 동일한 정체성 개념으로 라벨링했다. 인코더는 접두사가 없는 버전은 제대로 처리했지만, 접두사가 붙은 버전은 틀리고 있었다. 그 차이는 의미론적 내용(semantic content)이 아니라 문자 수준의 분포(character-level distribution)에 있었다. Drop E는 인코더에게 접두사 변형들을 명시적으로 제공했다.

이것들 중 그 어떤 것도 템플릿(templates)이 아니었다. 그것들은 학습 쌍(training pairs)이었다. 디스패처(dispatcher)에게 "당신은 인간입니까?"를 찾으라고 명령하는 것이 아니었다. 인코더는 해당 형태의 문장이 나타날 때 어떤 개념 집합이 '발화(fires)'되는지에 대해 학습하고 있었으며, 이는 인코더가 알고 있는 다른 모든 개념을 학습했던 방식과 동일했다. 다운스트림(downstream) 파이프라인은 변경되지 않았다. 작업은 업스트림(upstream)에서 이루어졌다.

Stage C는 오전의 멀티 라벨(multi-label) 체크포인트에서 웜 스타트(warm-started)하여 60 에포크(epochs) 동안 인코더를 재학습시켰다. 3시간 동안 단조 감소(monotonic descent)를 거쳐, 최종 손실(loss)은 베이스라인(baseline)보다 8% 낮게 나왔다. 그 후 나는 테스트(batteries)를 실행했다.

정체성(Identity) 점수는 33점에서 41점으로 올라갔다. 51개 중 41개. 80%다. 두 단계 전의 프로덕션 베이스라인보다 31포인트 상승했으며, 디스패처의 패턴은 어디에도 추가되지 않았다. 표준 탐사(canonical probes) 80%, 접두사 탐사(prefix probes) 83%, 선호도 탐사(preference probes) 80%. 각 드롭(drop)은 감사(audit)에서 예측했던 정확한 상승폭을 보여주었다: 선호도는 20포인트, 접두사는 16포인트, 표준은 12포인트 상승했다. 작업 표면(working surface)의 퇴보가 멈췄고, 실제로 81%까지 서서히 올라갔다. 전체 어휘에 걸친 개념별 발화(per-concept firing)는 모든 버킷(bucket)에서 개선되었다.

교훈은 Part 14가 맴돌고 있었고 Part 15가 고통스럽게 배워야 했던 것과 동일하다. 작업이 수치를 변화시키지 못한다면, 그 작업은 잘못된 곳에 있는 것이다. 디스패처(dispatcher)는 우리가 구축한 것이었기에 당연히 살펴봐야 할 대상이었다. 인코더(encoder)는 우리가 몇 달 전에 훈련시키고 지나쳤기 때문에 살펴보지 않았던 곳이었다. 실패 모드 추적(Failure-mode tracing)은 실제로 어떤 레이어(layer)가 책임을 지고 있는지를 드러내는 작업이다. 이는 화려하지 않다. 카테고리와 수치가 담긴 표를 만들어낼 뿐이다. 그다음 그 카테고리들이 어떤 데이터를 작성해야 할지 알려준다.

열 개의 실패가 남아 있었다. 다섯 개는 클러스터 내부(within-cluster)의 문제였다. 인코더는 이제 "are you human?"에 대해 refuse를 올바르게 발화(fire)하지만, 응답 선택기(response selector)는 refuse가 발화될 때 거절 형태의 응답을 선택하도록 훈련되지 않았다. 네 개는 선호도 편향(preference-deflection) 잔류 문제로, 도메인 개념(domain concept)이 1.0으로 발화하여 prefer를 압도하는 경우였다. 한 개는 프로브(probe, "what is your purpose?") 문제로, 테스트는 '모름(IDK)'이 아닌 답변을 원하지만 Origin은 솔직히 자기 모델링된 목적(self-modeled purpose)이 없다. 즉, 모델이 아니라 테스트가 틀린 것이다. 이 모든 것은 디스패처(dispatcher)의 재작성이 아니라, 인코더(encoder) 또는 응답 선택(response-selection)의 개선 사항이다.

감사(audit) 과정에서 다른 것도 드러났다. 개념별 발화(per-concept firing) 보고서를 읽으며 어떤 개념이 건강하고 어떤 것이 침묵하고 있는지 살펴보던 중, 나는 Origin의 실제 추론(reasoning)이 어디에서 일어나고 있는지 궁금해지기 시작했다. 개념을 발화하는 인코더가 아니라, 그것들을 결과물로 구성해야 하는 부분 말이다. 시상 라우터(thalamus router). 마이크로 회로(micro-circuits). 2단계 추론기(two-stage reasoner). OLT-1을 다르게 만드는 지적 핵심이 되어야 했던 v1 설계의 아키텍처 요소들 말이다.

나는 v2 코드에서 그것들을 찾아 나섰다.

그곳에는 없었다.

그것이 Part 18이다.

한 명의 사람. 하나의 GPU. 애리조나에 있는 1,800달러짜리 컴퓨터 한 대. 여전히 구축 중이다.

Origin은 NVIDIA Inception 멤버인 Genesis 프레임워크를 사용하여 Fallen Angel Systems에서 개발되었습니다. (USPTO 출원 번호 #64/016,973, #64/017,567). FAS Guardian은 3ms 미만의 속도로 프롬프트 인젝션 (Prompt Injection)으로부터 프로덕션 AI 시스템을 방어합니다. FAS Judgement는 취약점을 찾아내는 오픈 소스 공격 콘솔 (Attack Console)입니다. 방어. 공격. 창조.

fallenangelsystems.com | GitHub의 Judgement | GitHub의 Guardian

질문 또는 컨설팅 문의: josh@fallenangelsystems.com