Jev 1.13의 들쭉날쭉함

Jev는 완벽하지 않습니다. 여기 jev-1.13에서 저희가 인지하고 있는 몇 가지 거친 모서리가 있습니다. 이 중 상당수는 이후 버전에서 수정될 예정입니다.

jev-1.13는 빠르고 캘리브레이션되어 있으며 상식적 판단을 잘하지만 완벽하지는 않습니다. jev-1.13는 System One 작업에서 가장 뛰어납니다. 추가적인 간접 참조 수준을 요구하는 작업에는 어려움을 겪을 수 있습니다. 이해가 상당히 문자 그대로일 수 있습니다. 수치 정밀도를 요구하는 작업에는 어려움을 겪습니다.

실패 모드 자세히 보기

문자 그대로 읽기

jev-1.13는 여러분이 의도한 질문이 아니라 여러분이 쓴 질문에 답합니다. 범위를 한정하는 단어, 부정, 함의된 조건은 액면 그대로 읽힙니다. 질문은 지침에 쓰인 단어를 기준으로 답변되지만, 사람이라면 지침 뒤의 의도를 읽었을 수도 있습니다.

대신: instructions에 정확한 조건을 명시하십시오. 구체적으로 쓰십시오. 경계 사례는 기준에 넣으십시오. 잘못된 답변을 보고 “내가 정말로 의도한 것은…“이라고 설명하고 있는 자신을 발견한다면, 그 설명이 지침에서 빠진 나머지 절반입니다. 해석이 불가피한 곳에서는 두 개의 문자 그대로의 질문으로 나누고 코드에서 결합하십시오.

수학과 숫자

Jev는 계산기가 아닙니다. 수학적 로직은 코드로 구현하시기를 강력히 권합니다. Jev는 수학적 질문보다 의미론적 질문에서 더 나은 성능을 냅니다.

세기

jev-1.13는 안정적으로 세지 못합니다. 여기에는 단어 안의 문자 수, 구절 안에서 어떤 용어가 나타나는 횟수, 긴 목록 안의 항목 수가 포함됩니다. 모델은 개수를 세는 대신 답변의 모양을 인식하며, 오류는 세는 대상의 크기가 커질수록 커집니다.

세는 질문을 하기 전에, 그 개수에 애초에 모델이 왜 필요한지 물으십시오. 단위가 정규식이나 파서로 찾을 수 있는 것이라면 개수는 코드에 속하며 모델이 보탤 것이 없습니다.

대신: 코드에서 세십시오. 어떤 기준에 맞는 항목을 세고 싶다면, 코드에서 후보들을 순회하며 각각에 질문 하나를 던지고, 그다음 답변을 직접 더하십시오.

from typesafe_sdk import Noul, TypeSafeClient

client = TypeSafeClient(model="jev-1.13")
YES = 0.5  # up to you on what you want the threshold to be, depends on your usecase.

items = ["typesafe", "apple", "california", "banana", "likes", "calibration", "orange", "vertex"]

result = client.system_one(
    {"items": items},
    {
        f"item_{i}": Noul(instructions=f"Is `items[{i}]` the name of a fruit?")
        for i in range(len(items))
    },
)

count = sum(result.nouls[f"item_{i}"].noul > YES for i in range(len(items)))

수치 표현

jev-1.13는 수치 표현보다 의미론적 표현에서 더 나은 성능을 냅니다. 예를 들어 16진수 값을 사용한 색상 질문은 영어 이름을 사용한 질문보다 성능이 떨어집니다. RGB 삼중값이나 16진수 값이 주어지면 두 값이 서로 가까운지 안정적으로 판단하지 못합니다.

마찬가지로 고수준 프로그래밍 언어에 관한 질문은 저수준 어셈블리나 이진 인코딩 명령에 관한 질문보다 더 나은 성능을 냅니다.

대신: 변환은 코드에서 하고, 계산된 숫자나 이름 붙은 버킷 중 하나를 전달하십시오. 색상이 경고처럼 읽히는지 같은, 진짜 판단인 부분에만 모델을 남겨 두십시오.

score를 사용한 산술

score 출력(예: 기댓값과 확률)을 사용해 기준의 두 레벨 사이에 있는 숫자의 정확한 크기를 계산하지 마십시오. 기댓값을 사용해 특정 임계값을 넘는지 확인할 수는 있지만, jev-1.13의 score 레벨은 수치 캘리브레이션이 약합니다. 가장 가까운 두 레벨 사이를 보간하여 정확한 숫자를 복원하는 데는 도움이 되지 못합니다.

날짜와 시간 비교

jev-1.13는 날짜를 정렬된 양이 아니라 텍스트로 읽습니다. 두 날짜 중 어느 것이 먼저인지, 얼마나 떨어져 있는지, 또는 하나가 어떤 창 안에 들어가는지를 묻는 것은 신뢰할 수 없습니다. 형식이 섞이거나, 상대적 참조와 분기·결산 창·경과 기간 같은 도메인 경계가 있으면 더 나빠집니다.

대신: 작업을 나누십시오. 추출은 판단이므로 모델에 맡기십시오. 산술은 판단이 아니므로 코드에 두십시오.

날짜의 모든 부분은 작은 닫힌 집합입니다. 열두 달, 서른하루의 가능한 날, 유한한 범위의 연도입니다. 이는 추출을 자유 형식 파싱이 아니라 열거된 선택지에 대한 Choice로 바꾸어 주며, 빠진 부분을 추측하는 대신 보고하도록 명시적인 “명시되지 않음” 선택지를 넣을 자리를 줍니다. 코드가 그 부분들을 실제 날짜로 조립하고 그 이후의 모든 것, 즉 순서, 기간, 오프셋, 요일을 담당합니다.

날짜 추출 쿡북에 상대 날짜와 신뢰도 게이팅을 포함한 완성된 버전이 있습니다.

간접 참조

이중 부정이나 복잡한 간접 참조를 담은 지침은 덜 안정적으로 답변됩니다. 속성의 속성에 관한 질문이나 여러 추론 홉을 요구하는 것은 정확도를 떨어뜨립니다.

대신: 지침을 가능한 한 직접적으로 쓰십시오. 가능하면 상태의 관련 부분을 이름으로 식별하십시오.

무관한 세부로 가득한 큰 상태

결정과 무관한 내용으로 상태가 커질수록 정확도가 떨어집니다. 무관한 세부는 방해 요소로 작용하며, 상태가 크면 어느 입력 부분이 잘못된 답변을 낳았는지 판별하기 어려워집니다.

대신: 먼저 코드에서 검색하고 필터링하여 질문에 필요한 필드만 보내십시오. 상태에서 필터링할 수 없을 때는 Noul을 사용해 관련성을 걸러낼 수 있습니다. RAG 구절 분류 쿡북에 완성된 예가 있습니다.

적대적 콘텐츠

상태는 데이터이며, jev-1.13는 이를 기본적으로 적대적인 것으로 취급하지 않습니다. 주입된 지침이든, 의도적으로 오도하는 프레이밍이든, 자기 분류를 주장하는 텍스트든, 모델을 적대적으로 조종하려고 작성된 콘텐츠는 답변을 움직일 수 있습니다. 저희는 향후 이를 개선할 계획입니다.

대신: 기준에서 명시적으로 쓰십시오. 많은 사용자에게 배포하기 전에 통합을 철저히 테스트하십시오.

모순되는 지침과 기준

instructions와 criteria가 서로 다른 것을 요구하면 jev-1.13가 혼란스러워할 수 있습니다. 최고의 성능은 명확한 표현에서 나옵니다. 예를 들어 true가 no에, false가 yes에 매핑되는 Noul은 성능이 더 나쁩니다. 평범한 사람이 읽고 이해하기 쉬운 지침을 목표로 하십시오.

대신: 기준을 지침의 확장으로 취급하십시오. 명확하고 정밀한 언어로 둘을 정렬하십시오.

Choice 선택지 순서

경우에 따라 Choice의 선택지 순서가 답변에 영향을 줄 수 있으며, jev-1.13는 앞에 오는 선택지에 쏠리는 경향이 있음을 관찰했습니다.

대신: 선택지 순서를 바꾸어 답변이 일관되게 유지되는지 확인하십시오.

생성

jev-1.13는 텍스트를 생성하도록 훈련되지 않았습니다. 선택지를 연결해 억지로 생성하게 할 수는 있지만, 잘 작동하지 않고 매우 느립니다. 데이터 추출에는 정규식이나 생성형 모델로 가능한 선택지를 뽑아낸 뒤 jev-1.13가 올바른 추출을 고르게 하는 편이 낫습니다.

대신: 답변 공간이 유한할 때는 값 자체를 요청하는 대신 추출을 선택지에 대한 Choice로 바꾸십시오. 정말로 텍스트를 생성해야 한다면… 그 일을 위한 다른 모델들이 있습니다.