4P by GN⁺ | ★ favorite | 댓글 2개
  • needle-in-a-needlestack는 GPT-4o, Llama, Jamba, Sonnet, Gemini 관련 실험 글과 코드를 한곳에 모은 공개 페이지임
  • 프로젝트의 코드 저장소가 함께 제공되어 Needle in a Needlestack 실험 자료를 직접 확인할 수 있음
  • 모델별 글은 긴 컨텍스트 처리와 확장성 차이를 중심으로 Llama 3.1 8B, Jamba 1.5 등의 결과를 비교함
  • GPT-4o-mini는 GPT-4 Turbo와 비슷하면서 가격이 98.5% 낮은 사례로, Sonnet 3.5는 NIAN에서 Sonnet 3.0보다 나은 사례로 소개됨
  • 페이지 자체가 오픈소스라 GitHub의 “Improve this page” 링크로 문서 수정에 참여할 수 있음

Needle in a Needlestack 관련 링크

모델별 비교 글

오픈소스 문서

  • 이 사이트는 오픈소스
  • Improve this page 링크를 통해 GitHub에서 페이지를 수정할 수 있음

댓글과 토론

기술 발전이 정말 어마무시합니다..ㅠ

Hacker News 의견들
  • 이 테스트는 2021년에 공개된 리머릭 데이터셋을 기반으로 한 것임: https://zenodo.org/records/5722527
    GPT-4o가 이 데이터로 학습됐을 가능성이 매우 높다고 봄. 굳이 안 넣을 이유가 없기 때문임. NIAN 팀이 왜 여러 모델로 리머릭을 생성하고, 그 결과가 데이터셋에 없는지 확인하지 않는지 궁금함. 그러면 모델들이 해당 리머릭으로 학습됐을 가능성을 배제할 수 있음

    • 리머릭을 제공하지 않으면 LLM들이 질문에 답할 수 없는지 테스트했음. 4o를 제외하면 이 벤치마크에서 성능이 매우 나쁘기 때문에, 학습 데이터 포함 여부 때문에 테스트가 무효화된다고 보지는 않음
    • 그냥 완전한 무작위 텍스트를 만들고 그 안에서 찾게 하면 안 되나?
    • NIAN은 아주 멋진 아이디어지만, 그냥 N개의 다른 언어로 번역해서 질문하면 안 되나? DeepL, Google Translate, LLM 자체 번역 등을 섞어서 쓸 수도 있음
  • 작은 법률 문서 두 개를 비교해 봤는데, 한쪽에는 있고 다른 쪽에는 없는 조항이 있다고 완전히 환각했음. 계약서의 서로 다른 세 구간에서 그랬음
    ctrl-f로 확인해 보니 양쪽에 동일하게 들어 있었음. 표본 하나일 뿐이지만 90%라는 수치는 그럴듯해 보이지 않음. 전체는 대략 8만 토큰 정도였음

    • 비슷한 느낌임. 6천 개 항목 목록에서 중복을 찾게 했더니 답변 전체를 여러 번 거의 환각했음. 가끔 일부 중복을 찾긴 하지만, 그 사이에 환각한 항목들을 섞어 넣음
      고정된 수의 어텐션 헤드로는 어려운 작업이라고 생각해서 정답을 기대하진 않았지만, Claude Opus나 GPT-4보다 훨씬 나빠 보였음
    • 그건 건초더미 속 바늘 찾기가 아님
      LLM은 두 문서를 더 작은 구간으로 나누고, 구간별로 반복 처리하면 이 작업을 더 잘함. 추론 능력이나 기억이 없어서 비교적 작은 조각을 넘어선 두 덩어리 텍스트를 구조적으로 분석하지 못함. 대신 의미적으로 독립적이고 관련 있는 작은 조각으로 점진적으로 훑으면 꽤 잘 작동함
      이들을 마법 기계라고 가정하는 건 잘못임. 한계와 능력이 있고, 다른 도구처럼 무엇이 되는지와 안 되는지를 이해해야 하며 왜 그런지도 아는 편이 좋음. 개발자 99.9%에게 여전히 꽤 새로운 발전인데, 왜 기대치가 사실상 무한히 높은지 모르겠음. 이전 기술들은 “좋아, 제대로 쓰는 법을 찾아보자”는 식의 기준이 더 합리적이었음. 어쩌면 사람처럼 말해서 없는 능력까지 있어 보이기 때문일 수도 있고, 인간과 너무 비슷하게 들려서 인간이 아니라고 탓하는 것일 수도 있음. 과장은 과장대로 있고 과소평가도 동시에 있음. XML조차 한때 세계 기아를 끝낼 것처럼 여겨졌던 비슷한 과열 주기를 겪어 봤음
    • 그건 needle-in-a-needlestack과는 다른 테스트지만, 모델들이 얼마나 취약한지는 잘 보여줌. 어떤 영역에서는 유능하지만 다른 영역에서는 처참하게 나쁨
      needle-in-a-needlestack은 서로 다른 것들 사이에서 찾는 needle-in-a-haystack과 달리, 비슷한 데이터들 사이에서 특정 데이터를 찾는 문제임. 예를 들어 수천 개의 리머릭 중 하나를 찾는 식임
    • 지역 법규로 같은 실험을 해 봤고, GPT가 벌금과 수수료를 환각하는 걸 잡아냈음. 실제로 존재하는 문제임
    • 흥미로운데, 적어도 공식적으로 GPT-4o의 문맥 창은 128k임
  • needle-in-a-haystack 테스트는 모델의 실제 긴 문맥 처리 능력을 매우 제한적으로만 보여줌. 초기 모델들이 이 작업을 형편없이 못했고 테스트하기 쉬워서 주로 쓰였을 뿐임
    사실 최신 모델 대부분은 이 한 작업에서는 꽤 잘하지만, 실제로는 32K 토큰을 넘어서 복잡한 일을 하는 능력이 크게 떨어짐. RULER가 훨씬 나은 테스트임: https://github.com/hsiehjackson/RULER

    기본 needle-in-a-haystack(NIAH) 테스트에서 거의 완벽한 성능을 달성했음에도, 모든 모델(Gemini-1.5-pro 제외)은 RULER 작업에서 시퀀스 길이가 늘어날수록 큰 성능 저하를 보임
    모든 모델이 32k 토큰 이상의 문맥 크기를 주장하지만(Llama3 제외), 절반만이 정성 기준인 Llama2-7b의 4K 성능(85.6%)을 넘겨 32K 시퀀스 길이를 효과적으로 처리할 수 있음. 기준을 넘은 성능은 밑줄로 표시됨

    • 그럴 수도 있지만, 첫째 이 글은 NIHS가 아니라 자체 변형 테스트를 다루므로 더 관련성이 있을 수 있음. 둘째 글의 핵심 주장은 GPT-4o가 더 잘한다는 것인데, 언급한 테스트는 GPT-4o를 벤치마크하지 않았음
    • RULER가 벤치마크한 모델들은 needle-in-a-needlestack에서 더 나쁘게 나옴. 4o가 RULER에서 어떻게 나올지 궁금함
  • Gemini Pro 1.5로도 이걸 보고 싶음. 지난주에 Moby Dick 전체를 넣어 봤고, 한 번은 Byung Chul-Han이 낸 모든 책을 넣어 봤는데, 두 경우 모두 내 질문을 언급하거나 답하는 문장 일부를 매번 그대로 찾아냈고 환각도 없었음

    • 연구실의 여러 사람이 소설 작품에 대한 LLM의 긴 문맥 평가를 연구하고 있음. Moby Dick은 학습 데이터에 들어 있을 가능성이 매우 높음. 그래서 연구실 사람들은 이런 문제를 피하려고 최근 출간된 책들을 탐색해 왔음
      지난주 ICLR에서 발표된 BooookScore(https://openreview.net/forum?id=7Ttk3RzDeu)와 최근 프리프린트 FABLES(https://arxiv.org/abs/2404.01261)를 참고하면 됨
    • 그 내용은 아마 학습 세트에 들어 있지 않나? 모델의 마지막 릴리스보다 더 최근에 출간된 책 모음으로 같은 작업을 하면 흥미로울 듯함
    • 글에 링크된 2500개 예제를 Gemini 1.5 Flash에 넣어 봤고, 정답인 “The tree has diseased leaves and its bark is peeling.”를 맞혔음: https://aistudio.google.com/
    • 그 모델에 접근 권한이 있고, 인상적인 문맥 추출을 본 적도 있음. 큰 코드베이스를 통째로 넣었더니 요약도 아주 잘했음
      누군가 거대한 로그 파일을 분석하는 것도 봤지만, 모델이 뭔가를 놓치는 시점을 식별하려면 이런 needle-in-a-needlestack 같은 것이 정말 필요함. 적어도 모델 개발자들이 제안 모델을 분석하는 데 쓸 수 있음
    • 이제 2~5년쯤 뒤면 ePub을 넣고 몇 분 안에 정확한 그래픽 노블 버전을 얻을 수 있을 듯함. Tolkien식 나무 그림 4천 장을 볼 준비가 됐음
  • 누군가 검색뿐 아니라 다양한 정보 사이의 이해 깊이, 연결, 추상화를 테스트하는 “haystack에서의 종합” 테스트를 만들어야 함
    사람이 책을 읽으면 그 책에 대한 “전체적인 직관”이 생김. 이를 정량화할 방법이 필요함. needle-in-haystack 테스트는 너무 단순해서 충분히 멀리 가지 못하는 느낌임

    • 정교한 Agatha Christie식 범인 찾기가 가능할 듯함. 반전과 알리바이를 여러 개 넣고, 작품 끝부분을 잘라내면 가장 유력한 용의자가 바뀌도록 만드는 방식임
    • 바늘들이 그래프를 이루고, 프롬프트가 그래프 기반 작업을 묻는 방식도 가능함
    • 상세하고 내부적으로 일관된 세계관과 잘 설계된 동기를 가진 등장인물들이 들어 있는 미공개 소설이나 각본을 사서, 중간 이후 임의 지점부터 아직 만나지 않은 두 인물을 엮는 새 줄거리를 계속 쓰게 하는 아이디어가 있음
      문맥을 이해한다면 이야기의 새 부분을 쓸 수 있어야 하고, 독자가 직관적으로 느끼는 인물 동기를 사용해 그들의 서사를 전개할 수 있어야 함. 다만 유용하려면 전체를 철저히 비공개로 보관해야 하므로 개인 벤치마크에 가깝게만 쓸 수 있음. 아니면 방법론을 공개해 분야 개선에 쓰기보다는 결론의 신뢰성 자체로 평가받는 권위 있는 상처럼 만들 수도 있음
    • 비슷한 생각을 했음. 질문의 일부가 LLM이 리머릭을 찾기에 충분한 정보가 되게 하고, 두 번째 부분에서는 그 리머릭이나 다른 텍스트에 대한 더 깊은 이해가 필요한 내용을 묻는 방식임
    • 이해는 존재하지 않아서 그런 건 못함
      GPT-4o도 학습 세트에 없는 서로 다른 두 아이디어의 교차점을 아직 다루지 못함. 심지어 서로 다른 두 아이디어의 교차점에 대한 무작위 변형도 만들지 못함. 더 나아가 모델이 이런 일을 하리라고 기대하면 안 됨. 모델과 실제 유용성, 그리고 이해 없이도 해내는 놀라운 일들에 공정하지 않음. 모델이 이해한다고 믿는 건 스스로를 속이는 일임
  • 이제 GPT를 써서 원시 동적 데이터를 즉석에서 보기 좋은 HTML 레이아웃으로 바꿀 수 있음. 트래픽이 낮은 변경 로그나 감사 로그 같은 페이지에서 개발 시간을 크게 줄이고, 데이터 구조가 바뀌어도 HTML을 최신 상태로 유지할 수 있음
    이전 시도는 GPT-4-Turbo가 가끔 문맥과 지시를 거의 완전히 무시해서 일관되게 작동하지 않았음

  • 이 글은 GPT-4o가 입력 창 전체에 걸쳐 주의를 기울이는 능력이 GPT-4 Turbo와 Claude-3 Sonnet보다 얼마나 나아졌는지 보여줌
    한동안 needle-in-a-haystack의 업그레이드가 필요했는데, 이 “Needle In A Needlestack”은 좋은 다음 단계임. NIAN은 수천 개의 리머릭을 포함한 프롬프트를 만들고, 특정 위치의 리머릭에 대한 질문을 던짐

    • 동의함. 한동안 Claude에 돈을 냈음. 큰 문맥을 지원한다고 강하게 말하고, 큰 문맥을 쓰면 토큰을 엄청나게 잡아먹지만, 불과 몇 페이지 전의 소스 코드도 문맥에 있으면 거의 쓸모없었음
      다른 모든 면은 괜찮았고 분위기도 마음에 들었기에 더 답답했음. 어젯밤 4o를 써 봤는데, 20개 질문 전에 붙여 넣은 C++ 클래스를 여전히 완벽하게 인식하고 있었음. 똑똑한지는 관심 없고 유용한지가 중요하며, 이건 유용성에 정말 크게 기여함
  • 공개 인터넷에서 제대로 된 LLM 평가를 할 줄 아는 사람이 아무도 없는 것 같다는 확신이 점점 커짐

    • 그래도 2022~2023년에 모두가 하던 “미국의 29대 대통령은 누구인가”, “Van Gogh 스타일로 그려라” 같은 LLM 평가를 드디어 지나왔다는 것만으로도 다행임
  • 이 테스트가 의미 있으려면 테스트 세트 데이터가 학습 데이터에 포함되지 않았다는 걸 알아야 함

    • 리머릭을 먼저 제공하지 않고 질문하면 절대 정답을 맞히지 못함. LLM이 틀릴 때는 보통 학습 데이터로 되돌아가서 리머릭에 맞지 않는 일반적인 답을 내놓음
    • 꼭 그럴 필요는 없음. 자료를 업로드하기 전후의 모델 성능을 비교하면 됨
    • 테스트 리머릭은 자동 생성된 줄 알았음
  • 듣기 좋음. GPT-4.0에서 가장 큰 문제는 대화가 길어질수록 품질이 떨어지는 것이었고, 특히 코딩 프로젝트에서 중요했음
    이제 나아졌을지 궁금함. 오늘 테스트해 볼 예정임

    • 지금까지 내 경험도 그랬음. 현재 대화들은 예전 GPT-4 대화들보다 말도 안 되게 길어졌음. 예전에는 문맥을 자주 복사해서 새 채팅에서 다시 시작해야 했음
    • 같은 경험을 했음. 16k 프롬프트에서는 Turbo가 거의 완벽했지만, 32k에서는 별로였고 100k 이상에서는 쓸 수 없었음. 긴 프롬프트에서 좋은 결과를 얻으려면 정보를 반복해서 넣어야 함