Origin 파트 12: 어댑터 (The Adapter)

새로운 인코더는 올바른 개념을 찾는 데 24배 더 뛰어났습니다. 하지만 동시에 모든 응답을 망가뜨렸습니다.

파트 11은 새로운 인코더(encoder)를 디스크에 스테이징(staged)하는 것으로 끝났습니다. Top1 수치는 1.3%에서 31.3%로 급등했습니다. 타겟 활성화(Target activation)는 0.012에서 0.249로 증가했습니다. 아키텍처 레버(architectural lever)는 중단 조건(abort condition)이 예측한 바로 그 지점에 안착했습니다. 수치상으로는 이것이 우리가 출시할 인코더임을 나타내고 있었습니다.

그런 다음, 우리는 그것을 출시하려고 시도했습니다.

모든 쿼리(query)에 대해 "모르겠습니다"라는 답변만 돌아왔습니다.

디스패처(Dispatcher)가 하는 일

디스패처(dispatcher)는 Origin에서 인코더(encoder)와 응답(response) 사이에 위치하는 부분입니다. 인코더는 문자를 읽고 개념 활성화(concept activations)를 생성합니다. 이는 "각 개념이 이 입력에 대해 얼마나 강하게 반응하는가?"에 대한 긴 목록입니다. 디스패처는 그 목록을 읽고 어떻게 처리할지 결정합니다. 이것이 인사인가요? 이것이 정체성에 대한 질문인가요? 사용자가 무언가가 무엇인지 묻고 있나요? 각 경로(route)는 활성화 패턴(activation pattern)이 규칙과 일치할 때 실행되며, 각 경로는 활성화된 개념들로부터 응답을 구성하는 방법을 알고 있습니다.

규칙은 정신적인 의미에서 다음과 같았습니다: 만약 "인사(greeting)" 개념이 0.5 이상으로 활성화되면, 인사 핸들러(greeting handler)로 디스패치(dispatch)하라. 만약 "무엇(what)"과 "자아(self)" 개념이 모두 0.5 이상이면, 정체성 핸들러(identity handler)로 디스패치하라. 0.5, 0.7, 0.8과 같은 숫자들은 임계값(thresholds)으로서 디스패처 곳곳에 뿌려져 있었습니다. 이것들이 작동했던 이유는 이전 인코더가 해당 범위 내에 존재하는 활성화(activations)를 생성했기 때문입니다.

이전 인코더는 시그모이드(sigmoid)를 사용했습니다. 각 개념은 0에서 1 사이의 자체적인 절대 척도에 따라 독립적으로 점수가 매겨졌습니다. 인사에 대한 쿼리는 "인사(greeting)"를 0.92, "안녕(hello)"를 0.88, "질문(question)"을 0.04로 활성화할 수 있습니다. 세 개의 개념, 세 개의 독립적인 예/아니오 결정, 그리고 그 수치 그대로의 의미를 갖는 세 개의 숫자였습니다.

새로운 인코더는 소프트맥스(softmax)를 사용합니다. 활성화(activations)는 상대적입니다. 그것들은 전체 개념 공간(concept space)에 걸쳐 합계가 1이 됩니다. 쿼리에서 가장 강한 개념이 0.249일 수 있는데, 이는 이전 인코더 하에서는 경계선에 있는 약한 신호였겠지만, 새로운 인코더 하에서는 확신에 찬 지배적인 활성화가 됩니다.

0.249는 새로운 인코더 (encoder)의 평균적인 최상위 개념 활성화 (top concept activation) 값이었습니다. 디스패처 (dispatcher)의 모든 임계값 (threshold)은 0.5 이상이었습니다.

그것이 모든 쿼리 (query)가 IDK로 라우팅 (routed)된 이유였습니다. 새로운 인코더는 다른 모든 것과 비교했을 때 적절한 확신을 가지고 올바른 개념을 발화 (firing)하고 있었지만, 디스패처는 그 활성화 값들을 "아무것도 발화되지 않음"으로 읽고 있었습니다. 인코더는 정답을 고르는 능력이 24배나 향상되었지만, 그 상위 시스템은 이를 듣지 못하고 있었던 것입니다.

잘못된 해결책

첫 번째 본능적인 해결책은 재스케일링 (rescaling)이었습니다. 만약 0.249가 새로운 "높은 값"이라면, 모든 임계값을 2로 나누면 됩니다. 끝. 배포.

우리는 그것을 시도했습니다. 절반만 성공했습니다. 인사 처리기 (Greeting handlers)는 인사에 대해 올바르게 작동했습니다. 신원 처리기 (Identity handlers)는 신원 질문에 대해 올바르게 작동했습니다. 하지만 디스패처가 그 외의 모든 것에 대해 교차 발화 (cross-firing)를 시작했습니다. 감정에 관한 질문은 신원으로 라우팅되고, 사물에 관한 질문은 물리학으로 라우팅되었습니다. 우리는 하나의 보정 (calibration) 문제를 다른 문제로 맞바꾼 셈이었습니다.

이유는 다음과 같습니다. 재스케일링은 소프트맥스 (softmax) 출력을 마치 다른 범위에 존재하는 시그모이드 (sigmoid) 출력인 것처럼 취급합니다. 하지만 그렇지 않습니다. 새로운 인코더에서 0.249가 발화되는 것은 "개념이 49.8% 존재한다"는 뜻이 아니라, "이 개념이 차선책보다 이 정도의 마진 (margin)을 가진 가장 가능성 높은 해석이다"라는 뜻입니다. 이 숫자는 이전과는 다른 의미를 갖습니다. 재스케일링은 크기 (magnitude)를 수정할 뿐, 의미 (meaning)를 수정하지는 못합니다.

이러한 종류의 통합 (integration)에 관한 더 어려운 진실은 이것입니다. 상위 컴포넌트 (upstream component)가 정보를 표현하는 방식을 변경하면, 그 정보를 해석하는 모든 하위 컴포넌트 (downstream component)는 단순히 재조정 (retuned)되는 것이 아니라 새로 작성 (rewritten)되어야 합니다.

올바른 해결책

디스패처는 잘못된 형태의 질문을 던지고 있었습니다. 디스패처는 _"개념 X가 충분히 강하게 발화되고 있는가?"_라는 절대적 임계값 질문을 던지고 있었습니다. 소프트맥스 출력의 경우, 그 질문에는 의미 있는 답이 없습니다. 올바른 질문의 형태는 _"개념 X가 지배적인 신호인가, 그리고 그 차이는 어느 정도인가?"_라는 상대적 비교여야 합니다.

재작성된 규칙은 모든 임계값 (threshold)을 순위 확인 (ranking check)과 마진 확인 (margin check)의 결합으로 바꾸어 놓았습니다. "greeting > 0.5" 대신, 규칙은 _"greeting이 활성화된 상위 3개 개념 (top-3 fired concepts)에 포함되며, 그 활성화 정도가 다음으로 높은 비-greeting 개념보다 최소 2배 이상이다"_가 되었습니다. "identity > 0.7" 대신, 규칙은 _"identity가 활성화 분포 (activation distribution)의 상단을 지배한다"_가 되었습니다.

새로운 규칙의 숫자들은 과거의 의미에서의 임계값이 아닙니다. 2배의 마진, 상위 3위 순위, 비율에 의한 지배력(dominance-by-ratio) — 이 모든 것은 절대값이 아니라 활성화 분포의 _형태 (shape)_를 설명합니다. 이 방식은 과거의 임계값들이 그러지 못했던 방식으로 향후 인코더 (encoder)가 변경되더라도 살아남을 수 있는데, 왜냐하면 이 규칙들은 특정 인코더에서만 의미를 갖는 숫자에 대해 묻는 것이 아니라, 인코더 스스로의 상대적인 확신 (confidence)에 대해 묻고 있기 때문입니다.

전환은 단 한 번의 커밋 (commit)으로 이루어졌습니다. 모든 디스패치 규칙 (dispatch rule)이 재작성되었습니다. 디스패처 상태 (dispatcher state)와 실시간 대화 메모리 (live conversation memory)에 대한 백업이 수행되었습니다. 테스트 패널 (test panel)이 실행되었습니다.

변경 전

you > hello
origin > i don't know

you > what is your name
origin > i don't know

you > how does ice float
origin > i don't know

변경 후

you > hello
origin > hello.

you > what is your name
origin > my name is origin.

you > how does ice float
origin > ice is less dense than water, so it floats.

새로운 인코더가 이제 라이브 상태입니다. 시스템은 엔드 투 엔드 (end-to-end)로 작동합니다. 처음 두 단계의 개발 티어 (developmental tiers) — 기본 대화 (basic conversation)와 기초 추론 (elementary reasoning) — 는 정직성 테스트 패널 (honest test panels)에서 각각 95.5%와 86.5%를 기록했습니다.

전체 흐름(Arc)의 핵심

파트 9부터 12까지를 하나의 연속된 시퀀스로 되돌아보면, 이 흐름은 올바른 병목 지점 (bottleneck)을 찾아내는 규율에 관한 것입니다.

파트 9는 병목이 데이터라고 말했습니다. 우리는 인코더에 적절한 데이터를 공급하기 위해 신중한 계획을 실행했습니다. 파트 10은 데이터 계획이 작동하지 않았다고 말했습니다. 중단 조건 (abort condition)이 트리거되었고, 우리는 그에 귀를 기울였습니다. 파트 11은 병목이 아키텍처 (architecture)라고 말했습니다. 샌드박스 (sandbox)가 이를 확인해주었습니다. 파트 12는 올바른 병목을 수정한 후에도, 그 수정 사항을 시스템의 나머지 부분에 통합해야 하며, 통합 (integration)은 그 자체로 하나의 작업이라는 점을 말해줍니다.

이 중 그 어떤 것도 화려하지 않습니다. 이것은 "우리가 AGI를 달성했다"와 같은 게시물이 아닙니다. 이것은 모델이 실제로 구축되는 과정에 대한 느리고, 별일 없으며, 대부분 정확한 버전입니다. 병목 현상 (bottleneck)을 가설로 세우고, 서면으로 된 중단 조건 (abort condition)을 포함한 계획을 설계하며, 계획을 실행하고, 발생하는 현상에 귀를 기울이며, 증거가 가리키는 다음 단계를 수행합니다. 무언가가 실제로 작동할 때까지 이를 반복합니다. 그런 다음 주변의 모든 것을 망가뜨리지 않고 그것을 통합 (integrate)합니다.

오늘 우리가 실행 중인 인코더 (encoder)는 우리가 시작한 이래 세 번째 주요 반복 (iteration)입니다. 오늘 실행 중인 디스패처 (dispatcher)는 두 번째입니다. 앞으로 더 많을 것입니다. 이 시스템의 모든 구성 요소는 어느 시점에 병목 현상이 되었으며, 모든 구성 요소는 다시 병목 현상이 될 것입니다. 우리의 일은 첫날부터 완벽한 시스템을 설계하는 것이 아닙니다. 우리의 일은 실제로 무엇이 고장 났는지 계속해서 찾아내고, 원하는 결과가 단순히 수용해야만 하는 결과가 되지 않도록 사전에 중단 조건을 작성해가며, 한 번에 하나의 병목 현상씩 그것을 고쳐나가는 것입니다.

다음 단계

인코더는 작동합니다. 디스패처도 작동합니다. 처음 두 단계 (tiers)는 버텨내고 있습니다. 프로젝트가 다음에 나아갈 곳은 수학, 과학, 역사를 아우르는 중학교 수준의 콘텐츠인 세 번째 단계이며, 이곳은 우리가 지금까지 구축한 모든 것이 실제로 일반화 (generalize)되는지를 테스트하는 단계입니다.

우리는 이와 병행하여 하나의 가설을 테스트하고 있습니다. 다음 병목 현상은 더 많은 개념 (concepts)이 아니라, 개념들 사이의 관계 (relationships)가 될 것이라는 가설입니다. 모델이 "개", "동물", "네 다리", "짖다"를 네 개의 별개 개념으로 알 수는 있지만, 여전히 개가 무엇인지 이해하지 못할 수도 있습니다. 이해는 노드 (nodes)가 아니라 연결 (connections) 속에 존재할지도 모릅니다.

만약 그것이 맞다면, 다음 아키텍처 피벗 (architecture pivot)은 이미 지평선 위로 보이고 있습니다. 만약 그렇지 않다면, 우리는 빠르게 그것을 알아낼 것이고 그에 대한 게시물 또한 작성할 것입니다.

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

Origin은 NVIDIA Inception 멤버인 Fallen Angel Systems에서 Genesis 프레임워크를 사용하여 개발되었습니다. (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