바이트 잠재 변환기: 패치가 토큰보다 더 잘 확장되는 기술

Hacker News 의견

• BERT가 출시되던 여름, 캐릭터 기반 CNN 모델을 사용하여 분류 작업을 하던 스타트업에서 일하고 있었음. 팀원들은 워드 벡터에 관심이 있었지만, 사전 외 단어가 많아 실패로 이어질 수 있다고 생각했음

  • "기초 모델"에서도 사전 외 단어가 문제가 되었음
  • 캐릭터 기반 모델로 괜찮은 성과를 내고 있었지만, 신경망에 "사전"을 저장하는 것이 비효율적이라는 의견이 있었음
  • Word2Vec 같은 방식이 실패할 것이라고 확신하여 이전 프로젝트를 떠났음
  • 바이트 쌍 인코딩이 도입되었을 때, 처음으로 지지할 수 있는 토크나이제이션 방식이라고 말했음
  • 캐릭터 레이블로 작업할 수 있기를 바람. 토크나이저에 대한 반감이 있음

• 계층 구조가 흥미롭지만 두 단계만 있는 것이 아쉬움. 더 많은 계층을 쌓는 것이 연구의 방향이 될 수 있음

  • FLOP 예산을 계층에 따라 분배하는 것에 주의해야 함
  • 패치를 더 큰 단위로 그룹화하는 방법을 찾아야 함

• 패치를 생성하기 위해 작은 모델을 사용하여 입력 문자열의 다음 문자의 가능성을 예측함

  • 예: 다음 문자가 'a'일 가능성이 100% 또는 'a', 'b'일 가능성이 각각 10%일 수 있음
  • 문자 추정치를 함께 묶어 패치(또는 토큰)를 만듦

• 샘플링은 LLM의 어려운 점이지만, 유효한 JSON을 항상 출력하도록 강제하거나 온도를 조정하여 다양한 분포를 얻는 등 흥미로운 사용을 가능하게 함

  • BLT에서는 디코더에 허용/금지된 바이트를 추가 입력으로 제공하고 유효한 출력을 얻을 때까지 디코딩을 반복하는 방법을 생각할 수 있음

• AI가 이진 파일로 사전 훈련할 수 있는지에 대한 질문이 있음

• 토크나이제이션을 암시적으로 만들어 바이트(또는 문자)만 모델에 제공할 수 없는지에 대한 질문이 있음

• Karpathy의 관련 인용문: 토크나이제이션은 LLM의 많은 이상함의 중심에 있음

  • LLM이 단어를 철자할 수 없는 이유는 토크나이제이션 때문임
  • LLM이 간단한 문자열 처리 작업을 수행하지 못하는 이유는 토크나이제이션 때문임
  • LLM이 비영어권 언어에 약한 이유는 토크나이제이션 때문임
  • LLM이 간단한 산술에 약한 이유는 토크나이제이션 때문임
  • GPT-2가 Python 코딩에 불필요한 어려움을 겪은 이유는 토크나이제이션 때문임
  • LLM이 "<|endoftext|>" 문자열을 보면 갑자기 멈추는 이유는 토크나이제이션 때문임
  • "trailing whitespace" 경고가 나타나는 이유는 토크나이제이션 때문임
  • "SolidGoldMagikarp"에 대해 질문하면 LLM이 깨지는 이유는 토크나이제이션 때문임
  • LLM에서 YAML을 JSON보다 선호해야 하는 이유는 토크나이제이션 때문임
  • LLM이 실제로 끝에서 끝까지 언어 모델링을 하지 않는 이유는 토크나이제이션 때문임
  • 고통의 진정한 근원은 토크나이제이션임

• 3가지 구성 요소로 이루어진 모델임

  • 인코더: 바이트 그룹을 받아 패치라는 숨겨진 상태/인코딩을 출력함
  • 트랜스포머: 패치의 인코딩을 자동회귀 방식으로 처리함
  • 디코더: 트랜스포머가 처리한 인코딩을 바이트로 출력함
  • 손실은 바이트 간 교차 엔트로피(다음 바이트 예측)에 기반함

• 바이트를 그룹화하는 방법

  • 엔트로피 임계값 사용: 바이트 시퀀스의 엔트로피가 임계값보다 낮으면 그룹화함
  • 데이터에서 학습된 모델임

• 현재 LLM의 바이트 쌍 토크나이제이션보다 이점이 있음

  • 인코더/디코더가 "학습 가능한" 토크나이제이션 방식으로 작동함
  • 효율성 거래가 더 나음 (예측 가능한 바이트 시퀀스의 경우, 인코더가 주요 트랜스포머의 계산 노력을 "오프로드"할 수 있음)
  • 역사가 보여주듯이 끝에서 끝까지 학습된 시스템이 인간이 설계한 메커니즘을 능가함

• 우리는 정체기에 접어들어야 한다고 생각했음