GPT 토큰 5억 개 처리 후 얻은 교훈들

 (kenkantzer.com)
4P by GN⁺ | ★ favorite | 댓글 1개
  • Truss는 최근 6개월간 LLM 중심 기능을 운영하며 OpenAI 모델로 5억 토큰 이상을 처리했고, B2B 텍스트 요약·분석·추출에서 실제로 부딪힌 한계를 정리함
  • 프롬프트는 세부 지시를 많이 넣을수록 안정적이지 않았고, GPT가 이미 아는 상식은 짧고 덜 구체적인 지시가 더 나은 결과를 낸 경우가 있었음
  • Langchain, JSON mode, function calling, assistants 없이도 chat API와 JSON 추출 함수 하나로 여러 기능을 운영했으며, 핵심 코드는 40줄짜리 함수와 오류 처리·자동 잘라내기 정도였음
  • GPT는 “없으면 빈 값 반환” 같은 귀무가설(null hypothesis) 처리와 긴 출력에 약했고, GPT-4의 128k 입력 창과 별개로 출력은 4k 수준에 머무름
  • RAG와 벡터 DB는 Truss의 제한된 텍스트 추출 업무에는 잘 맞지 않았고, 전체 문맥을 넣는 분석·요약·추출은 신뢰도가 높지만 입력이 비어 있거나 관련 정보가 없을 때 문제가 커짐

사용 범위와 전제

  • Truss는 지난 6개월 동안 LLM 중심 기능 몇 가지를 출시했고, 사용량은 추정상 5억 토큰을 조금 넘음
  • 사용 모델은 OpenAI 계열이며, 토큰 사용량은 GPT-4 85%, GPT-3.5 15% 임
  • 다루는 데이터는 텍스트뿐이며 gpt-4-vision, Sora, Whisper 같은 비텍스트 기능은 포함하지 않음
  • 제품 맥락은 B2B이고, 주요 작업은 요약·분석·추출임
  • 5억 토큰은 약 75만 페이지 분량의 텍스트에 해당함

프롬프트는 덜 구체적일 때 나아질 수 있음

  • GPT가 이미 아는 일반 지식에 대해 정확한 목록과 지시를 과하게 넣으면 결과가 더 나빠질 수 있었음
  • 한 파이프라인은 텍스트 블록이 미국 50개 주 또는 연방정부 중 어디와 관련되는지 분류해야 했음
    • 초기 프롬프트는 locality_id 필드에 50개 주와 federal의 ID 목록을 JSON 형태로 넣고 선택하게 함
    • 이 방식은 대략 98% 이상 동작했지만, 실패가 충분히 많아 추가 조사가 필요했음
  • 다른 필드인 name은 명시적으로 요구하지 않았는데도 올바른 주의 전체 이름을 안정적으로 반환했음
    • 이후 name에 나온 문자열을 검색해 주를 찾는 방식으로 바꾸자 잘 동작함
  • 더 나은 접근은 “50개 주를 알고 있으니 해당 주의 전체 이름 또는 Federal을 반환하라”처럼 상식에 맡기는 프롬프트였음
  • 부가 관찰도 있었음
    • 실패는 Maryland, Maine, Massachusetts, Michigan 같은 M으로 시작하는 주에서 더 자주 나타남
    • ID를 목록에서 고르게 할 때, 각 주를 한 줄씩 둔 보기 좋은 JSON이 쉼표로 이어진 목록보다 덜 혼란스러웠음

API와 추상화는 단순하게 유지됨

  • Langchain은 이 사례에서 섣부른 추상화에 가까웠고, 수백만 토큰과 3~4개의 다양한 프로덕션 기능 이후에도 openai_service 파일에는 40줄짜리 함수 하나만 남음
  • 실제로 사용한 API는 chat뿐임
    • 항상 JSON을 추출함
    • JSON mode, function calling, assistants는 필요하지 않았음
    • system prompt도 사용하지 않음
    • gpt-4-turbo가 출시됐을 때는 코드베이스에서 문자열 하나만 바꿈
  • 함수 대부분은 OpenAI API의 500 오류나 소켓 종료 같은 오류 처리를 담당함
    • 이런 오류는 개선됐고, OpenAI의 부하를 감안하면 놀랍지 않다고 봄
  • 컨텍스트 길이 제한은 자체 자동 잘라내기로 처리함
    • 문자열 길이가 model_context_size * 3보다 크면 잘라냄
    • 마침표나 숫자가 매우 많을 때는 토큰 비율이 문자 3개당 1토큰보다 작아져 실패할 수 있음
    • context_length_exceeded가 나오면 model_context_size * 3 / 1.3 기준으로 다시 잘라 재시도함

스트리밍 UX는 과소평가하기 어려움

  • 스트리밍 API로 지연 시간을 줄이고, 사용자에게 가변 속도로 입력되는 글자를 보여주는 방식은 처음에는 장난처럼 보였음
  • 실제 사용자는 가변 속도 “타이핑” 표시를 매우 긍정적으로 받아들임
  • 이 경험은 AI에서 마우스·커서 UX에 해당하는 순간처럼 느껴졌음

빈 결과와 긴 출력이 약점임

  • “찾지 못하면 빈 출력 반환”은 가장 오류가 많았던 프롬프트 문구에 가까웠음
    • 실제로 아무것도 출력하지 말라는 뜻이 아니라 {value: ""} 같은 빈 값 표현을 반환하게 한 것임
    • 문제는 출력 제한 실패가 아니라 귀무가설 판별 자체의 어려움에 가까웠음
  • GPT는 빈 값을 반환해야 할 때 환각을 선택하기도 했고, 반대로 자신감이 낮아져 빈 값을 너무 자주 반환하기도 했음
  • 텍스트 블록이 비어 있을 수 있는 버그가 있었을 때 환각이 심하게 발생함
    • 예시로 Sunshine Bakery, Golden Grain Bakery, Bliss Bakery 같은 가짜 베이커리 이름이 나옴
    • 해결은 텍스트가 없으면 프롬프트를 아예 보내지 않는 방식이었음
  • GPT-4는 입력에 대해 128k 토큰 창을 가질 수 있지만, 출력 창은 여전히 4k 수준임
    • “context window”라는 표현은 입력과 출력을 혼동하게 만듦
  • JSON 객체 목록을 반환하게 할 때, 간단한 객체여도 10개를 넘기기 어려웠음
    • 15개를 요청하면 약 15% 정도만 성공하는 것으로 추정함
    • 10개 수준에서 멈출 때도 출력은 700~800토큰 정도에 불과했음
  • 한 번에 하나씩 요청하고 이전 결과를 다시 넣는 방식으로 출력 한계를 우회할 수는 있지만, GPT와 전화 게임을 하는 형태가 되고 Langchain 같은 도구를 다루게 됨

RAG와 벡터 DB는 이 사용 사례에 잘 맞지 않음

  • 벡터 DB와 RAG/임베딩은 Truss의 사례에서는 대부분 쓸모가 없었음
  • 벡터 DB와 RAG는 검색, 그것도 Google·Bing 같은 진짜 검색에 더 잘 맞는다고 봄
  • 핵심 문제는 관련성 기준임
    • 관련성에 명확한 컷오프가 없음
    • Cohere의 rerank 같은 해법이나 자체 휴리스틱이 있을 수 있지만 안정적이지 않음
    • 관련 없는 결과로 검색 결과가 오염되거나, 너무 보수적으로 잡아 중요한 결과를 놓칠 위험이 있음
  • 벡터를 일반 데이터와 떨어진 전문·독점 DB에 저장하는 것도 손실이 큼
    • Google·Bing 규모가 아니라면 문맥 손실이 트레이드오프를 정당화하지 못한다고 봄
  • 비즈니스 앱 안의 검색에서는 사용자가 도메인 전문가인 경우가 많음
    • 사용자가 직접 입력하지 않은 의미까지 추측해 반환하는 의미 검색을 좋아하지 않는다고 봄
  • 대부분의 검색 사례에서는 LLM을 일반 completion prompt로 써서 사용자 검색어를 faceted search, 복잡한 쿼리, SQL로 바꾸는 방식이 더 나을 수 있음
    • 이 방식은 RAG가 아님

환각은 문맥이 충분할 때 크게 줄어듦

  • Truss의 사용 사례는 대부분 “텍스트 블록을 주고 거기서 무언가를 추출”하는 형태임
  • 텍스트에 언급된 회사명을 달라고 하면, GPT는 보통 임의의 회사를 반환하지 않음
    • 단, 텍스트에 회사가 없을 때는 귀무가설 문제가 다시 나타남
  • 코드에서도 GPT는 전달한 코드 블록을 다시 쓰는 중에 변수를 지어내거나 중간에 오타를 임의로 넣는 의미의 환각은 잘 하지 않음
    • 다만 어떤 것을 만들어 달라고 하면 표준 라이브러리 함수의 존재를 지어낼 수 있음
    • 이 역시 “모른다”고 말하지 못하는 문제에 가깝다고 봄
  • 전체 문맥을 제공하고 분석·요약·추출하게 하는 작업에서는 매우 신뢰할 만했음
  • 좋은 데이터를 넣으면 좋은 GPT 토큰 응답이 나오는 구조에 가까움

향후 전망에 대한 판단

  • 현재의 transformer, 인터넷 데이터, 수십억 달러 규모 인프라 접근만으로는 AGI에 도달하지 못한다고 봄
  • GPT-4는 마케팅이 아니라 100% 유용한 기술이며, 아직 인터넷 초기와 비슷한 단계라고 봄
    • 모두를 해고할 기술은 아님
    • 이전에는 Google만 접근 가능했던 ML/AI의 진입 장벽을 낮추는 효과가 큼
  • Claude, Gemini 등은 엄밀한 A/B 테스트를 하지는 않았음
    • 일상적인 코딩에서 테스트했을 때는 의도를 직관하는 미묘한 부분에서 GPT-4에 가깝지 않다고 느낌
  • LLM/AI 흐름을 모두 따라갈 필요는 없다고 봄
    • The Bitter Lesson에 비춰 일반 모델 성능 향상이 특화 개선보다 중요하다면, GPT-5 출시 여부만 신경 쓰면 된다는 판단임
    • Sora 같은 별도 영역을 제외하면 OpenAI의 중간 릴리스는 대부분 잡음에 가깝다고 봄
  • GPT-5는 모든 것을 바꾸기보다 점진적 개선일 가능성이 큼
    • GPT-3에서 GPT-3.5로 갈 때는 훈련 강도를 2배로 올리면 성능이 2.2배 좋아지는 초선형 개선을 기대했음
    • 실제로는 로그형 개선처럼 보이고, 점진적 개선을 위해 토큰 속도와 토큰당 비용이 기하급수적으로 커지는 상황으로 봄
  • GPT-4는 현재의 작업 세트에서는 최적점일 수 있음
    • GPT-3.5 대비 GPT-4에 20배 비용을 낼 의향은 있었지만, GPT-4에서 GPT-5로 가기 위해 토큰당 20배를 내지는 않을 것 같다고 봄
    • GPT-5가 이를 깰 수도 있고, iPhone 4에서 iPhone 5로 가는 정도일 수도 있음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 내가 맡은 팀은 매달 50억+ 토큰을 처리하고 있고 계속 늘어나는 중인데, 몇 가지 배운 점이 있음
    첫째, 너무 이른 추상화가 많음. Langchain 같은 도구가 언젠가 유용할 수는 있지만, 결국 프롬프트는 API 호출일 뿐이고 LLM 호출을 특별한 것으로 다루기보다 불안정한 API 호출처럼 표준 코드로 다루는 편이 더 쉬움
    둘째, 환각은 확실히 큰 문제임. 요약은 테스트상 꽤 견고하지만 추론은 정말 어렵고, 사용자 입력을 받아 다음 행동을 LLM이 결정하게 하는 행동 모델은 특히 문맥 이해와 “확실하지 않다”라고 말하게 하는 부분이 어려움. 그래도 이걸 할 수 있다는 사실 자체는 판도를 바꿈
    셋째, 글쓴이보다 조금 더 “판도를 바꾼다”는 쪽에 가깝지만 세상이 끝난다고 보지는 않음. 일부 직업은 큰 영향을 받고, 봇들이 플랫폼에서 여론 조작하는 힘든 몇 년이 올 수 있음. 전체적으로는 인터넷 같은 돌파구라기보다 능력 증폭기에 가까워 보임
    개인적으로는 2000년대 DevOps 변화와 비슷함. 이제 배포를 돕는 거대한 전담팀이 필요하지 않고, 소수의 전문가를 뽑고 대부분은 기성 솔루션을 구매함. 마찬가지로 일부 머신러닝 작업은 나 같은 웹 개발자도 쉽게 구현할 수 있게 됨

    • LLM을 현대 개발 흐름에서 어떻게 기대해야 하는지 설명할 때 이런 비유가 유용함. 만능 해결책이 아니라 절충이라는 점을 보여주기 때문임
      DevOps의 진화에도 절충은 있었음. 예를 들어 “그냥 AWS RDS 쓰면 된다”의 직접 결과로 데이터베이스 관리 같은 핵심 역량이 사라졌고, 클라우드 청구 비용도 폭증했음. 특히 데이터 규모나 지역 복잡도가 크지 않은 스타트업의 운영비도 커졌고, 이런 흐름이 GitLab의 큰 장애와 비슷한 사고들로도 이어졌다고 봄
    • “확실하지 않다”라고 말하게 하는 건 언어 모델 자체의 함수에 가까움. 출력에 도달할 때쯤 계산에 내재된 불확실성은 예측 속에서 사라짐
      동전 앞뒤를 맞히라고 해서 “앞면”이라고 답하면, 답하기 전에는 Pr[앞면] = .5 같은 불확실성을 말할 수 있지만 실제 예측과 동전 던지기 결과에서는 그 불확실성이 사라지는 것과 비슷함. LLM도 토큰의 최종 예측에서 계산 중 불확실성이 사라지므로, 예측 자체가 불확실성 표현이 아닌 한 “이해하지 못했다”는 출력은 거의 나오지 않을 것임. 다만 그 이유는 애초에 이해하지 않고 예측하기 때문임
    • DevOps 비유를 전에는 생각해본 적이 없었는데, 뭔가 맞아떨어져서 방금 이 아이디어를 바탕으로 글을 썼음: https://kenkantzer.com/gpt-is-the-heroku-of-ai
      기본적으로 우리는 GPT를 AI 운영에서 PaaS/Heroku/Render 같은 등가물로 쓰고 있다고 봄
    • “인터넷 같은 돌파구라기보다 능력 증폭기”라는 데 동의함. 고객들도 대형 모델 비용 대비 산출물에서 가격 충격을 느끼고 있음. 시간이 지나면 비용은 내려갈 것임
    • 요약은 견고하지만 추론은 어렵다는 말에 공감함. 비유를 요청하는 방식은 흥미롭고 의외로 유용했음

  • “우리는 항상 JSON을 추출한다. JSON 모드는 필요 없다”는 부분이 궁금함. 내 경우에는 꽤 잘 동작했음
    “Lesson 4: GPT는 귀무가설을 만드는 데 정말 약하다”는 말은 정말 공감함. 어제도 텍스트 수정 규칙 프롬프트를 테스트하면서 끝에 “어떤 규칙도 텍스트에 적용되지 않으면 원문을 변경 없이 반환하라”고 썼음
    규칙이 하나도 적용되지 않는 텍스트에 ChatGPT가 뭐라고 답했는지 아는가? “The original text without any changes”라는 문자열 그대로였음

    • 변덕스러운 지니가 소원의 문구를 문자 그대로 해석해 저주받은 소원을 들어주는 이야기들이 있는데, 지금 우리가 가진 게 그거임. 이미지 생성 모델에 오래 프롬프트를 넣어온 사람들은 어느 정도 감을 잡았지만, LLM 때문에 들어온 사람들에게는 꽤 놀라울 수 있음
      예전에 타로 카드용으로 멋진 정원에서 와인을 마시는 세 여자의 이미지를 만들던 중, 프롬프트 끝에 “lush vegetation”을 넣었더니 그중 lush의 중의성 때문에 우아한 분위기에서 빨간 코의 파티 여대생 느낌으로 바뀐 적이 있음
    • “우리 방식이 잘 동작해서 JSON 모드를 쓸 필요가 없다”는 뜻으로 읽었음. 우리 회사도 같은 상황임. 1년째 운영 중이고 바꿀 필요가 없었음. 우리 프롬프트는 GPT-3.5가 항상 JSON을 내도록 꽤 효과적임
    • 케이크 장식 실패 사이트들을 보면, 사람도 이런 종류의 실수를 늘 함

  • 더 나은 프롬프트를 쓰면 더 싼 모델을 사용할 수 있음
    “아무것도 찾지 못하면 아무것도 반환하지 말라”는 LLM에게 빠져나갈 길을 주는 레벨 0 방식임. 더 부드러운 탈출구를 주는 편이 낫다. 예를 들어 “결정적인 진술을 할 충분한 정보가 없으면, 그렇게 하고 있다고 명확히 밝히고 가설의 근거와 논리적 기반을 적는 한 가설을 세워도 된다”처럼 쓰고, 마지막에 자기 답변을 평가하게 하면 됨

    • 프롬프트는 추상적으로 개발하면 안 됨. 프롬프트의 목표는 모델 내부 표현을 활성화해 작업을 가장 잘 수행하게 하는 것임
      자동화된 방법이 없다면, 다양한 입력에 대한 모델 반응을 반복 테스트하면서 요청을 어떻게 해석하는지, 어디서 실패하는지 이해하고 그 구멍을 메워야 함. 심지어 모델이 nothing이 무슨 뜻인지 알고 있는지도 검증해야 함

  • LLM 분야의 상위 3개 서비스에 모두 가입해서 같은 프롬프트를 자주 던져보는데, GPT-4 쪽으로 매우 일방적으로 유리함. GPT-4가 나온 지 1년이 됐고 그 사이 업데이트가 몇 번 있었음을 감안해도 놀라움
    적어도 내 사용 패턴에서는 환각도 드문 편임. 반면 Claude는 코드를 쓸 때 존재하지 않는 그럴듯한 API를 꽤 쉽게 지어냄. GPT-4는 자신이 맞다고 알 때 더 고집 있고 덜 맞장구침. 이런 차이는 지표에 거의 잡히지 않아서 개인적으로 써봐야 보임

    • 내 경우에는 Claude 3 Opus가 GPT-4보다 나았음. 특히 설명을 더 잘하고, 더 중요하게는 더 철저히 해줌
      코딩 작업에서도 코드를 작성하게 하기보다는 주제나 코드 설명을 요청하는데, 훨씬 더 미묘한 답을 주는 경향이 있음. 긴 텍스트를 주고 대화하면 Claude Opus가 내용을 더 깊게 이해하는 느낌이고, GPT-4는 주어진 텍스트를 요약하는 쪽에 머무는 반면 Claude는 더 잘 확장해 추론함
    • Claude Opus와 비교한 것인지, 아니면 하위 변형과 비교한 것인지 궁금함. Opus는 영어 문안 생성에 정말 마음에 듦
    • GPT-4는 형태가 나쁘거나 정보가 부족하거나 구조가 엉망인 프롬프트에 더 잘 대응함. 큰 프롬프트를 지능적으로 구조화하지 않으면 Claude는 무엇을 요청하는지 헷갈릴 수 있음
      다만 잘 구성된 프롬프트에서는 Claude Opus가 GPT-4보다 더 나은 출력을 내는 경향이 있음. Claude는 더 유연하고 긴 답변을 제공하는 반면, ChatGPT/GPT-4는 늘 자기 특유의 짧고 “전형적인” 답변처럼 들리는 편임
    • 내 경험은 반대였음. 여러 서비스에 가입해서 같은 질문을 복사해 붙여넣는데, 소프트웨어 개발 관련 질문에서는 Claude Opus가 훨씬 앞서 있어서 이제 GPT-4를 쓸 필요가 없을지도 모른다고 생각 중임
      요청한 코드 예시에서 GPT-4가 만든 코드는 컴파일조차 안 되는 경우가 많았고, Claude에서는 거의 그런 일이 없었음
    • 나도 세 서비스 모두 구독하고 같은 방식으로 비교함. 새 버전이 나올 때마다 특히 그럼
      요즘 쓰는 리트머스 테스트는 “Austin에서 200마일 이내의 특이한 바 10곳을 알려줘”임. 이건 모두에게 엄청 어렵고, GPT-4는 그럭저럭 가까웠지만 Claude는 그냥 지어냈고 Gemini는 완전히 무너졌음

  • GPT는 아주 멋지지만, 글의 두 문단 해석에는 강하게 동의하지 않음
    “GPT야, 너는 50개 주를 분명히 알고 있으니, 이것이 해당되는 주의 전체 이름을 주거나 미국 정부에 해당하면 Federal이라고 답하라”는 식이 더 나은 접근이었다는 요약은 가능함
    하지만 더 모호하게 말했을 때 GPT의 품질과 일반화가 좋아지는 것이 고차원적 위임/사고의 전형적 표식이라는 해석은 과하다고 봄. 자연어는 GPT에 가장 확률 높은 출력임. 학습한 텍스트와 비슷하기 때문임. 이 경우 개발자는 GPT가 잘하는 쪽으로 더 기대었을 뿐, 일을 더 시킨 게 아님
    GPT를 실패하게 만드는 단순 작업은 많음. 글자 치환, 의도적 오타 같은 작업은 GPT에게 매우 어려움. ID 매핑 같은 것도 마찬가지고, 특히 학습 중 본 매핑과 크게 다른 경우에는 더 그렇다. 예를 들어 ISO가 아닌 국가 코드처럼 비슷한 세 글자 코드가 그렇음
    흥미로운 점은 GPT가 매핑을 “이해”한다는 사실 자체임. 그게 오히려 고차원 패턴 매칭의 실제 단서라고 봄

    • 아니면 그냥 매핑을 암기하는 것일 수도 있음. 그대로 재현한다는 의미는 아니고, 전에 본 매핑과 비슷한 벡터를 갖고 있다는 뜻임

  • ‘null’ 문제에 대한 팁: LLM은 토큰을 출력하도록 만들어졌지, 토큰을 출력하지 않도록 만들어진 게 아님
    그래서 “아무것도 반환하지 말라” 대신 결과가 없을 때 “XYZ의 기본값을 반환하라”고 하고, 상태명 검색하듯 결과에서 그 기본값, 예를 들어 XYZ를 텍스트 검색하면 됨
    또 시스템 프롬프트는 매우 유용할 수 있음. 기본적으로 LLM에게 X 역할극을 시킬 기회임. 시스템 프롬프트를 직접 넘길 수 있게 해주면 좋겠지만, 그래도 없는 것보다는 낫다

  • GPT가 JSON 객체 목록을 10개 넘게 제대로 못 반환한다는 건 프롬프트 문제임. 나는 올바른 순서로 최대 200개까지 안정적으로 반환하게 한 적이 있음
    요령은 목록을 전혀 쓰지 않고 출력에서 "item1": {...} 같은 JSON 키를 쓰는 것임. 어떤 입력에 대해 0~n개의 출력이 있을 때는 값으로 목록을 사용할 수 있음

    • 사용자가 불완전한 목록으로 답하는 걸 무례하고 모욕적으로 여기는 문화권 출신이라고 말해주고 있음
    • 더 자세히 설명해줄 수 있으면 좋겠음. 지금 이 문제로 머리를 싸매고 있음
      GPT-4에 정의된 구조를 가진 기존 항목 목록을 주고 스키마 변환 같은 방식으로 JSON으로 바꾸게 하면 하루 종일도 잘함. 하지만 어떤 종류든 추론이 필요하고 사실상 자기 목록을 만들어야 하면 매우 제한된 부분집합만 줌
      다른 LLM에서도 비슷한 문제가 있음. 어떻게 접근하는지 매우 궁금함

  • “텍스트 블록에서 회사명을 추출하라” 같은 작업은 두 단계로 나누면 됨
    먼저 “이 텍스트 블록에 회사가 언급되어 있는가?”라고 묻고, 아니면 null 결과를 얻은 것임. 그렇다면 “이 텍스트 블록에 있는 회사 이름을 나열하라”고 하면 됨

  • 개인용 글쓰기 앱에서 OpenAI 모델을 쓰고 있는데 이 글은 정말 정확함. “프롬프트는 적을수록 좋다”는 Lesson 1과 관련해 배운 게 있음
    노트에 대한 지능형 검색 기능을 만들면서 ChatGPT가 구조화된 JSON 데이터를 반환하게 하려 했음. 예를 들어 “지난 2년 안에 Haskell을 언급하고 초안으로 표시된 내 노트를 모두 줘”라고 묻고, ChatGPT가 무엇을 반환할지 알아서 판단하게 하려 했음. 이건 가끔만 동작했음
    대신 데이터를 SQLite 데이터베이스에 넣고, ChatGPT에 스키마를 보낸 뒤 원하는 결과를 반환하는 질의를 작성하게 했더니 훨씬 잘 동작했음

    • 이건 LLM보다 데이터베이스와 좋은 검색 필터가 더 적합해 보임
    • response_format=json_object를 써봤는지 궁금함
      구조화된 응답을 얻는 데는 함수 호출이 더 잘 맞았지만, 그냥 JSON 본문을 받는 것보다 제약이 더 많음

  • 너무 정확하게 지시하면 정확도가 낮아지는 예시는, 이런 시스템이 동작하는 방식에 대한 내 조악한 이해로는 말이 됨
    주 목록 전체를 넣으면 모든 주에 대한 벡터를 어느 정도 활성화하는 셈임. 그냥 “state”라고 말하고 전달한 텍스트에 명시적인 주가 있으면, 찾는 대상과 관련된 벡터가 더 적게 활성화됨. 그래서 소프트맥스를 수행할 때 올바른 주가 선택될 가능성이 더 높아짐
    같은 맥락에서 /n과 쉼표 비교도 아마 토큰화 차이 때문일 가능성이 큼

답변달기
GeekNews BeeBS 게시판 오픈! 자유로운 이야기와 소소한 일상을 함께 나눠보세요.