TypeSafe로 구축하기
TypeSafe는 AI 지능의 단위를 프로그래밍 기본 요소처럼 사용할 수 있게 합니다. 즉, 더 큰 기능으로 조합할 수 있는 작은 판단입니다. System One 모델은 소프트웨어가 직접 소비할 수 있는 빠르고 집중된 판단을 반환합니다. Jev는 TypeSafe의 대표적인 첫 번째 System One 모델입니다. 자연어를 이해하고 텍스트 생성이나 추론 설명 대신 타입이 지정된 답변과 확률을 반환합니다. 코드가 워크플로를 소유하고, 모델은 일반 코드에 의미론적 이해가 필요한 곳에서 프로그래밍 가능한 상식을 제공합니다.
OpenRouter를 통해 Jev 호출하기
이 스킬의 변형은 TypeSafe 자체 API가 아닌 OpenRouter를 통해 Jev를 호출합니다. TypeSafe 문서는 개념과 질문 설계에 대한 참고 자료로 남아 있습니다. 액세스, 모델 ID 및 청구 방식만 다릅니다.
- 자격 증명: OpenRouter API 키이며 OpenRouter 계정에 청구됩니다. TypeSafe 계정은 필요하지 않습니다. 환경 변수(
OPENROUTER_API_KEY또는TYPESAFE_API_KEY를 OpenRouter 키로 설정)에서 읽습니다. 코드에 하드코딩하지 말고 웹 앱에서는 서버 측에 보관하십시오. - System One API (기본):
Authorization: Bearer <OpenRouter 키>헤더와 함께POST https://openrouter.ai/api/v1/systemone을 사용합니다. TypeSafe의 요청 및 응답 형식을 구현하고 응답에id,provider및usage.cost를 추가합니다. - TypeSafe SDK (
@typesafe-ai/sdk,typesafe_sdk):baseURL/base_url또는TYPESAFE_BASE_URL을 통해 기본 URL을https://openrouter.ai/api로 설정하고(SDK가/v1/systemone을 추가합니다),apiKey/api_key또는TYPESAFE_API_KEY를 통해 OpenRouter 키를 전달합니다. 다른 모든 것은 TypeSafe SDK 문서를 따릅니다. - SDK의 모델 목록을 호출하지 마십시오 (
client.models.list()): OpenRouter에서는 OpenRouter의 Models API를 호출하며, SDK가 해당 응답 형식을 거부합니다. - 모델 ID:
jev-1.14(현재),jev-1.13또는jev-latest; 기본 ID는typesafe/jev-…및~typesafe/jev-latest에 매핑됩니다. 재현 가능한 임계값을 위해 버전을 고정하십시오. 현재 버전, 가격 및 컨텍스트 길이는 OpenRouter의 TypeSafe 모델을 확인하십시오. 응답의model필드는 요청을 처리한 정확한 버전을 나타냅니다. - Box (
state의 이미지에서 설명된 대상을 찾음)는jev-1.14이상이 필요합니다. 1.13은 400 오류와 함께 거부합니다. Box는 항상 모서리(edges)를 반환하므로, 대상이 없을 수 있는 경우 Noul과 함께 사용하십시오. - 대체 표면: OpenRouter 자체 Decisions API (
POST https://openrouter.ai/api/alpha/decisions) 및 해당 TypeScript, Python, Go SDK. 프로젝트에서 이미 OpenRouter SDK를 사용하는 경우에만 선호하십시오. - Jev의 타입 API가 아님:
typesafe/jev-router는 Jev를 사용하여 다른 LLM을 선택하는 채팅 완성 라우터입니다. 타입이 지정된 답변이 아닌 생성된 텍스트를 반환하므로 이 스킬의 패턴에 적합하지 않습니다. - 클라우드 및 샌드박스 세션: 네트워크 허용 목록에
openrouter.ai가 포함되어야 합니다. 키를 일반 환경 변수가 아닌 비밀로 저장하십시오.
OpenRouter 문서: OpenRouter의 Jev, OpenRouter의 TypeSafe SDK, Jev 튜토리얼 및 문서 인덱스("Jev"를 검색하여 쿡북을 찾으십시오). OpenRouter와 TypeSafe 문서가 액세스, 엔드포인트, 모델 ID 또는 가격에 대해 일치하지 않는 경우, 이 설정에서는 OpenRouter 문서가 우선합니다.
실시간 문서 읽기
실시간 TypeSafe 문서가 진리값의 원천입니다. 작업의 일부로 읽으십시오. 이 스킬은 방향을 제시합니다. 문서는 현재 개념, 프롬프팅 지침, API 계약, SDK 사용법, 모델, 제한 사항 및 실제 예제를 제공합니다.
- 문서 인덱스에서 시작하여 관련 페이지와 쿡북을 찾으십시오. 전체 사이트를 로드하는 대신 대상 읽기를 사용하십시오.
- Mintlify는 페이지 경로에
.md를 추가하여 마크다운을 제공합니다. 예를 들어 TypeSafe로 구축하는 방법이 있습니다. 인덱스의 링크를 따르십시오. 유용한 경우 확장자가 없는 문서 페이지 링크를.md로 변환하십시오. 상대 링크는https://docs.typesafe.ai를 기준으로 확인하십시오. - 통합을 작성하기 전에 현재 API 또는 선택한 SDK 페이지와 설계와 관련된 질문 안내를 읽으십시오. 새 워크플로의 경우 가장 가까운 쿡북도 검사하십시오. 일반적인 분류기보다 더 나은 분해를 보여주는 경우가 많습니다.
- 인덱스를 사용할 수 없는 경우 아래의 직접 링크나 사이트 탐색을 사용하십시오. 마크다운 가져오기가 실패하면 일반 페이지를 시도하십시오. 실시간 액세스를 사용할 수 없는 경우 사용 가능한 로컬 문서나 설치된 SDK 유형을 사용하고 해당 제한 사항을 명시한 다음, 버전 종속적인 세부 사항을 발명하지 마십시오.
| 작업 | 여기서 시작하십시오. 관련 세부 사항을 따르십시오 |
|---|---|
| 프로그래밍 모델 이해 | System One, 구축 가이드 |
| 구축할 항목 탐색 | 사용 사례 맵, 그런 다음 인덱스의 관련 쿡북 |
| 입력 및 질문 준비 | 상태, 기본 요소, 그런 다음 선택한 기본 요소 페이지 |
| 불확실성 처리 방법 결정 | 신뢰도 |
| API 코드 작성 | 먼저 OpenRouter의 TypeSafe SDK, 그런 다음 요청 형식에 대한 HTTP API, Python SDK 또는 JavaScript SDK (OpenRouter의 기본 URL 및 키 사용) |
| OpenRouter 쿡북 찾기 | 도구 호출 게이팅, 검증된 캐스케이드, 대규모 분류, 권한 프롬프트 자동 승인 |
| 이전 통합 업데이트 | 마이그레이션 가이드 및 설치된 SDK의 현재 참조 |
유용한 형태 찾기
사용자가 원하는 동작, 즉 애플리케이션이 표시, 선택, 변경 또는 전달할 내용에서 시작하십시오. 필요한 판단으로 거꾸로 작업하십시오. 알려진 규칙, 계산, 정확한 조회 및 실행은 코드에 유지하십시오. 사용자가 선택한 스택과 범위를 유지하고 의미론적 이해가 필요한 곳에 TypeSafe를 추가하십시오.
아키텍처를 브레인스토밍하거나 선택할 때는 분류 이상을 고려하십시오. 아래 패턴은 시작점입니다. 사용자의 목표에 맞게 기본 요소를 결합하고, 확립된 레시피에 맞지 않는 아이디어도 포함하십시오.
- 알려진 인수를 라우팅하고 채웁니다. 요청은 핸들러와 해당 타입 매개변수를 선택할 수 있습니다. 유용한 분기별 질문을 미리 하고 관련 답변만 소비하십시오. 함수 호출 및 추측 팬아웃을 탐색하십시오.
- 생성 대신 선택합니다. 코드에서 후보 값 또는 소스 범위를 찾고, 판단을 사용하여 의도된 값을 선택한 다음 복사하거나 정규화하십시오. 코드는 소스 텍스트를 서식이 지정된 문서 또는 읽기 가이드로 조합할 수도 있습니다. 값 추출 및 구조 복구를 탐색하십시오.
- 증거를 찾고 판단합니다. 후보를 검색하고 쿼리와의 관련성을 비교한 다음 유용한 컨텍스트를 선택하십시오. 재순위 지정 및 계층적 분류를 탐색하십시오.
- 판단을 재사용 가능한 데이터로 전환합니다. 한 번에 차원에 점수를 매긴 다음 코드나 사용자 제어가 가중치, 임계값, 순위 및 보기를 변경할 수 있도록 하십시오. 레이블이 지정된 결과를 사용하면 해당 신호가 고전적인 ML 기능이 될 수 있습니다. 복합 점수 매기기 및 기능 발견을 탐색하십시오.
- 확인 및 에스컬레이션합니다. 특정 주장이나 필드를 해당 증거와 비교하여 확인하고, 불확실하거나 실패하는 경우를 사람이나 추론 모델에 보내십시오. 인용 확인 및 추출 캐스케이드를 탐색하십시오.
- 변경되는 상태에 응답합니다. 코드는 목표와 관찰을 유지하면서 새로운 판단이 다음 제한된 단계를 안내하도록 할 수 있습니다. 추론된 상태를 관찰된 사실과 구별하고, 결과를 변경된 상황에 적용하기 전에 최신 상태인지 확인하십시오.
개방형 요청의 경우 사용자의 목표에 가장 잘 부합하는 몇 가지 방향을 제시하고 시작점을 권장하십시오. 구체적인 요청의 경우 관련 패턴을 선택하고 구축하십시오. 브레인스토밍은 필수 우회가 아닙니다.
판단 설계하기
답변의 의미에 따라 선택한 다음 관련 기본 요소 페이지를 읽으십시오.
| 필요 | 기본 요소 | 중요한 차이점 |
|---|---|---|
| 정의된 집합 중 하나 | Choice | 하나의 옵션을 선택합니다. 분포는 경쟁 옵션을 비교합니다 |
| 조건이 유지되는지 여부 | Noul | 예일 확률; 별도의 신뢰도 없음; 여러 개가 적용될 수 있는 경우 레이블당 하나 사용 |
| 설명된 차원을 따른 정도 | Score | 순서가 지정된 수준의 확률 가중 위치; 등급 순위 지정을 위해 항목당 비교 가능한 점수 사용 |
| 이미지에서 설명된 대상의 위치 | Box | Jev 1.14+ 전용; 기준 없음; 항상 모서리를 반환하므로 존재 여부는 Noul에 요청 |
각 질문에 답변하는 데 충분한 관련 상태(소스 텍스트, ID, 관계, 정책 및 현재 사실)를 제공하십시오. 컨텍스트에 여러 부분이 있는 경우 명명된 JSON 필드를 선호하십시오. 판단을 지침에 넣고 가능한 답변을 기준에 정의하십시오. 질문 ID는 코드용이며 모델에 전송되지 않습니다. 질문에 완전한 의미를 포함하십시오. 중첩된 상태는 ticket.messages[0].text와 같이 백틱으로 묶인 경로로 참조하십시오.
질문당 하나의 좁고 일관된 판단을 요청하십시오. 독립적으로 유용한 차원을 분할하되, 판단되는 관계를 파괴하지 마십시오. 제한된 작업 선택 또는 맥락적 해석이 유효합니다. 원자적이라는 것은 문자 그대로의 사실 추출이나 한 문장 제한을 의미하지 않습니다. 간단한 질문에는 문자열이 작동합니다. 정의, 대조, 제외 또는 예제가 지침이나 기준을 명확히 하는 경우 구조화된 객체나 배열을 사용하십시오. 점수 수준은 구체적인 상황을 설명하고 독립적으로 이해될 수 있어야 합니다.
필요한 답변을 사용할 수 있도록 유지하십시오. 아무것도 맞지 않을 수 있는 경우 일치하지 않는 결과를 포함하고, 독립적으로 유용한 경우 별도의 존재 여부 판단을 사용하십시오. 소스 값 선택의 경우 후보 적용 범위를 확인하십시오. 모델은 생략된 값을 선택할 수 없습니다.
구성 및 확인
동일한 상태에 대해 독립적인 질문을 함께 요청하고 유용한 추측 질문을 포함하십시오. 이들은 병렬로 실행되며 서로의 답변을 볼 수 없습니다. 각 추측 전제를 명시적으로 명시하십시오. 코드는 적용 가능한 답변을 소비합니다. 이전 답변이 증거를 가져오거나, 새 상태를 구성하거나, 다음 옵션을 결정하는 데 필요한 경우 두 번째 요청이 정당화됩니다. 추가 질문은 여전히 토큰을 사용합니다. 실제 요청 예산, 비용 및 종단 간 지연 시간을 측정하십시오.
확률과 신뢰도를 사용하여 동작을 안내하고, 사용자 데이터와 결과에 대해 평가된 임계값을 사용하십시오. Choice/Score 신뢰도는 분포 집중도를 요약하며, 전체 워크플로 정확성이나 실행 권한이 아닙니다. 0.5에 가까운 Noul은 예와 아니오에 대해 유사한 확률을 의미하며, 중간 강도가 아닙니다. 여러 허용 가능한 대안도 확률을 분산시킬 수 있습니다. 낮은 신뢰도가 무해한 선호도 선택을 무효화할 필요는 없습니다. 사용되지 않은 분기에 대한 불확실성은 무시하십시오.
정책을 명시적으로 유지하고 원시 판단을 재사용 가능하게 유지하십시오. 가중 점수는 보상 선호도에 적합합니다. "심각한 위반" 규칙은 별도의 조건이 필요합니다. 증거와 질문 의미가 변경되지 않은 경우 가중치 또는 표시 필터를 변경하기 위해 추론을 다시 실행할 필요가 없습니다. 타입이 지정된 출력은 인터페이스를 보장하며, 진리를 보장하지 않습니다. System One 모델은 보정된 결정을 위해 훈련되었습니다. 대상 도메인에서 성능을 검증하십시오.
대표적인 경우와 결과 애플리케이션 동작을 테스트하십시오. 실패의 경우 정확한 상태, 질문, 후보, 답변, 구성 및 관찰된 결과를 검사하십시오. 누락된 증거, 모델 오류, 코드 오류 및 서비스 실패를 구분하십시오. 쿡북 임계값 및 데모 결과를 평가할 예시로 취급하고, 보편적인 규칙이나 영구적인 모델 제한으로 취급하지 마십시오. 웹 앱에서 API 자격 증명을 서버 측에 유지하십시오.