토크나이저는 LLM의 "섹시한" 부분으로 간주되지 않지만, 기회로 보는 사람도 있음. xVal 같은 논문은 토크나이제이션의 전문화 전략을 제시함. 철자와 문자 작업은 토크나이제이션 혁신으로 이익을 볼 수 있는 또 다른 문제임
LLM은 단어의 문자 수를 세거나 문자 생략을 수행하는 데 약함. 예를 들어, GPT-4o는 문자의 인스턴스를 세기 위해 작은 파이썬 프로그램을 작성하고 실행함. 토크나이제이션은 프롬프트의 문자에 대한 지식을 효과적으로 지우고 이러한 작업의 성능에 직접적으로 부정적인 영향을 미침
데이터를 이해해야 의미 있는 작업을 수행할 수 있음. 많은 사람들이 자동화된 데이터 처리 도구를 사용하는 주된 이유는 데이터를 직접 보고 싶지 않기 때문임. 컴퓨터가 데이터를 보고 추가 정보 수집 요청을 할 수 있기를 바람
블로그 게시물에서 오타에 대한 부분을 특히 감사하게 생각함. 프로젝트에서 RAG와 유사한 애플리케이션을 돕고 있으며, 사용자 쿼리의 작은 오타나 형식 차이가 임베딩 거리 계산에 미치는 영향을 걱정하고 있음
훈련 데이터에 의도적인 오타/대체/대문자화를 추가하여 "wrk"와 "work"가 아마도 동의어임을 학습하도록 해야 하는지 고민 중임
Elasticsearch를 사용하여 1-2문장 입력과 문단 이상의 문서 간 유사성을 고급 텍스트 쿼리로 처리하는 앱에서 일한 경험이 있음. 토크나이제이션 전략이 특정 쿼리에 얼마나 영향을 미칠 수 있는지 흥미로웠음
예를 들어, "W-4" 또는 "W4" 같은 경우, 표준 토크나이제이션은 "-" 또는 문자/숫자 경계에서 나눌 수 있음. 이 입력은 인덱스에서 완전히 식별할 수 없게 됨
기사에서 각 문제에 대한 해결책이 논의된 부분이 부족하다고 느낌. 철자 검사를 토크나이징 전에 실행하거나 잘못된 철자 단어와 잠재적 수정 단어를 나란히 토크나이징하는 방법을 제안함
브랜드 이름 문제는 해결 방법을 알 수 없음. 이 문제는 덜 일반적인 언어 또는 복합어를 많이 사용하는 언어에서 더 심각할 수 있음
많은 개발자가 전통적인(결정론적) 공간에서 개발하는 데 익숙하지만, 통계적 공간에서 문제를 생각하는 방식을 변경하지 못함. LLM 앱은 궁극적으로 통계적 공간임
개발자로서 이 문제를 사용자에게 설명하는 데 어려움을 겪고 있음
RAG를 구현하는 대부분의 사람들이 토크나이제이션에 대해 생각하지 않고 임베딩에 대해 생각함
데이터 코퍼스를 청크로 나누고 각 청크에 대한 임베딩을 계산함. 쿼리를 생성하고 각 쿼리에 대한 임베딩을 계산함. 쿼리에 대한 거리로 코퍼스 청크를 순위 매김. 반환 값을 구성함
이 기사는 시스템 성능에 큰 영향을 미칠 수 있는 숨겨진, 상대적으로 평범한 작업의 중요성을 강조함
블로그 게시물의 일부 숫자를 재현할 수 없음. 예를 들어, SentenceTransformer를 사용한 코드에서 두 문장의 코사인 유사도를 계산한 결과가 예상과 다름
여러 RAG 구현에서 대상 문서가 들어오는 쿼리에 대한 좋은 검색 키가 될 것이라고 가정하는 문제를 봄. 최근 프로젝트에서 검색 키를 반환 값(청크된 문서)과 분리하고 LM을 사용하여 적절한 키를 생성하여 임베딩함으로써 검색 관련성이 크게 향상됨
많은 대형 LLM 어휘가 상당히 크다고 하지만, 영어만 해도 100만 개 이상의 단어가 있음. 30k-300k 토큰은 작아 보임
Hacker News 의견
토크나이저는 LLM의 "섹시한" 부분으로 간주되지 않지만, 기회로 보는 사람도 있음. xVal 같은 논문은 토크나이제이션의 전문화 전략을 제시함. 철자와 문자 작업은 토크나이제이션 혁신으로 이익을 볼 수 있는 또 다른 문제임
데이터를 이해해야 의미 있는 작업을 수행할 수 있음. 많은 사람들이 자동화된 데이터 처리 도구를 사용하는 주된 이유는 데이터를 직접 보고 싶지 않기 때문임. 컴퓨터가 데이터를 보고 추가 정보 수집 요청을 할 수 있기를 바람
블로그 게시물에서 오타에 대한 부분을 특히 감사하게 생각함. 프로젝트에서 RAG와 유사한 애플리케이션을 돕고 있으며, 사용자 쿼리의 작은 오타나 형식 차이가 임베딩 거리 계산에 미치는 영향을 걱정하고 있음
Elasticsearch를 사용하여 1-2문장 입력과 문단 이상의 문서 간 유사성을 고급 텍스트 쿼리로 처리하는 앱에서 일한 경험이 있음. 토크나이제이션 전략이 특정 쿼리에 얼마나 영향을 미칠 수 있는지 흥미로웠음
기사에서 각 문제에 대한 해결책이 논의된 부분이 부족하다고 느낌. 철자 검사를 토크나이징 전에 실행하거나 잘못된 철자 단어와 잠재적 수정 단어를 나란히 토크나이징하는 방법을 제안함
많은 개발자가 전통적인(결정론적) 공간에서 개발하는 데 익숙하지만, 통계적 공간에서 문제를 생각하는 방식을 변경하지 못함. LLM 앱은 궁극적으로 통계적 공간임
RAG를 구현하는 대부분의 사람들이 토크나이제이션에 대해 생각하지 않고 임베딩에 대해 생각함
블로그 게시물의 일부 숫자를 재현할 수 없음. 예를 들어, SentenceTransformer를 사용한 코드에서 두 문장의 코사인 유사도를 계산한 결과가 예상과 다름
여러 RAG 구현에서 대상 문서가 들어오는 쿼리에 대한 좋은 검색 키가 될 것이라고 가정하는 문제를 봄. 최근 프로젝트에서 검색 키를 반환 값(청크된 문서)과 분리하고 LM을 사용하여 적절한 키를 생성하여 임베딩함으로써 검색 관련성이 크게 향상됨
많은 대형 LLM 어휘가 상당히 크다고 하지만, 영어만 해도 100만 개 이상의 단어가 있음. 30k-300k 토큰은 작아 보임