Build with TypeSafe
TypeSafe는 AI 지능의 단위를 프로그래밍 기본 요소처럼 사용할 수 있게 만듭니다. 즉, 더 큰 기능으로 구성할 수 있는 작은 판단입니다. System One 모델은 소프트웨어가 직접 사용할 수 있는 빠르고 집중된 판단을 반환합니다. Jev는 TypeSafe의 대표 모델이자 최초의 System One 모델입니다. 자연어를 이해하고 텍스트나 추론 설명을 생성하는 대신, 타입이 지정된 답변과 확률을 반환합니다. 코드가 워크플로를 소유하며, 모델은 일반 코드에 의미론적 이해가 필요한 부분에서 프로그래밍 가능한 상식을 제공합니다.
실시간 문서 읽기
실시간 TypeSafe 문서가 진실의 원천입니다. 작업의 일부로 문서를 읽으십시오. 이 스킬은 방향을 제시하며, 문서에는 현재 개념, 프롬프팅 가이드, API 계약, SDK 사용법, 모델, 제한 사항 및 작업 예제가 포함되어 있습니다.
- 문서 인덱스로 시작하여 관련 페이지와 쿡북을 찾으십시오. 전체 사이트를 로드하는 대신, 목적에 맞게 읽으십시오.
- Mintlify는 페이지 경로에
.md를 추가하여 Markdown을 제공합니다. 예를 들어 TypeSafe로 빌드하는 방법이 있습니다. 인덱스의 링크를 따르고, 확장자가 없는 문서 페이지 링크를 유용할 때.md로 변환하십시오. 상대 링크는https://docs.typesafe.ai를 기준으로 해석하십시오. - 통합을 작성하기 전에, 현재 API 또는 선택한 SDK 페이지와 설계와 관련된 질문 가이드를 읽으십시오. 새로운 워크플로의 경우, 가장 가까운 쿡북도 검토하십시오. 종종 일반적인 분류기보다 더 나은 분해를 보여줍니다.
- 인덱스를 사용할 수 없는 경우, 아래의 직접 링크 또는 사이트 탐색을 사용하십시오. Markdown 가져오기가 실패하면 일반 페이지를 시도하십시오. 실시간 액세스가 불가능하면 사용 가능한 로컬 문서나 설치된 SDK 유형을 사용하고, 해당 제한 사항을 명시하며, 버전 종속 세부 사항을 임의로 만들지 마십시오.
| 작업 | 여기서 시작하고 관련 세부 사항을 따르십시오 |
|---|---|
| 프로그래밍 모델 이해 | System One, 빌드 가이드 |
| 무엇을 빌드할지 탐색 | 사용 사례 맵, 그 다음 인덱스의 관련 쿡북 |
| 입력 및 질문 준비 | 상태, 프리미티브, 그 다음 선택한 프리미티브의 페이지 |
| 불확실성 처리 방법 결정 | 신뢰도 |
| API 코드 작성 | HTTP API, Python SDK, 또는 JavaScript SDK |
| 기존 통합 업데이트 | 마이그레이션 가이드 및 설치된 SDK의 현재 참조 |
유용한 형태 찾기
사용자가 원하는 동작에서 시작하십시오: 애플리케이션이 무엇을 보여주고, 선택하고, 변경하거나, 넘겨줄 것인가? 필요한 판단으로 거꾸로 작업하십시오. 알려진 규칙, 계산, 정확한 조회 및 실행은 코드에 유지하십시오. 사용자의 선택한 스택과 범위를 유지하고, 의미론적 이해가 필요한 곳에 TypeSafe를 추가하십시오.
아키텍처를 브레인스토밍하거나 선택할 때는 분류 이상을 고려하십시오. 아래 패턴은 시작점입니다: 사용자 목표에 맞게 프리미티브를 결합하되, 정해진 레시피에 맞지 않는 아이디어도 포함하십시오.
- 알려진 인자를 라우팅하고 채웁니다. 요청은 핸들러와 타입이 지정된 매개변수를 선택할 수 있습니다. 유용한 분기별 질문을 미리 하고 관련 답변만 사용하십시오. 함수 호출 및 추측성 팬아웃을 탐색하십시오.
- 생성 대신 선택합니다. 코드에서 후보 값이나 소스 범위를 찾고, 판단을 사용하여 의도된 것을 선택한 다음, 복사하거나 정규화하십시오. 코드는 소스 텍스트를 형식화된 문서나 읽기 가이드로 조합할 수도 있습니다. 값 추출 및 구조 복구를 탐색하십시오.
- 증거를 찾고 판단합니다. 후보를 검색하고, 쿼리와의 관련성을 비교한 다음, 유용한 컨텍스트를 선택하십시오. 재순위화 및 계층적 분류를 탐색하십시오.
- 판단을 재사용 가능한 데이터로 전환합니다. 한 번에 차원을 점수화한 다음, 코드나 사용자 제어가 가중치, 임계값, 순위 및 보기를 변경할 수 있게 하십시오. 레이블이 지정된 결과를 통해 해당 신호는 고전적인 ML 기능이 될 수 있습니다. 복합 점수화 및 기능 발견을 탐색하십시오.
- 검증하고 에스컬레이션합니다. 특정 주장이나 필드를 증거와 비교하여 확인하고, 불확실하거나 실패하는 경우는 사람이나 추론 모델에 보내십시오. 인용 확인 및 추출 캐스케이드를 탐색하십시오.
- 변경되는 상태에 응답합니다. 코드는 목표와 관찰 내용을 유지하면서 새로운 판단이 다음 단계를 안내할 수 있습니다. 추론된 상태와 관찰된 사실을 구분하고, 변경된 상황에 결과를 적용하기 전에 신선도를 확인하십시오.
개방형 요청의 경우, 사용자 목표에 가장 잘 부합하는 몇 가지 방향을 제시하고 시작점을 추천하십시오. 구체적인 요청의 경우, 관련 패턴을 선택하고 빌드하십시오. 브레인스토밍이 의무적인 우회는 아닙니다.
판단 설계
답변의 의미에 따라 선택한 다음, 관련 프리미티브 페이지를 읽으십시오:
| 필요 | 프리미티브 | 중요한 차이점 |
|---|---|---|
| 정의된 세트 중 하나 | Choice | 하나의 옵션을 선택하며, 분포는 경쟁 옵션을 비교합니다 |
| 조건이 성립하는지 여부 | Noul | '예'의 확률; 별도의 신뢰도 없음; 여러 레이블이 적용될 수 있을 때 레이블당 하나 사용 |
| 설명된 차원을 따른 정도 | Score | 순서가 있는 수준의 확률 가중 위치; 등급 순위화를 위해 항목별로 비교 가능한 Scores 사용 |
각 질문에 답변하는 데 충분한 관련 상태를 제공하십시오: 소스 텍스트, 신원, 관계, 정책 및 현재 사실. 컨텍스트에 여러 부분이 있을 때는 명명된 JSON 필드를 선호하십시오. 판단을 지시사항에 넣고 가능한 답변을 기준에 정의하십시오. 질문 ID는 코드용이며 모델에 전송되지 않습니다. 질문에 완전한 의미를 포함하십시오. 중첩된 상태는 ticket.messages[0].text와 같은 백틱 경로로 참조하십시오.
질문당 하나의 좁고 일관된 판단을 요청하십시오. 독립적으로 유용한 차원을 분할하되, 판단되는 관계를 파괴하지 마십시오. 제한된 동작 선택이나 맥락적 해석도 유효합니다. 원자적이라는 것은 문자 그대로의 사실 추출이나 한 문장 제한을 의미하지 않습니다. 간단한 질문에는 문자열이 작동합니다. 정의, 대조, 제외 또는 예제가 지시사항이나 기준을 명확히 할 때는 구조화된 객체나 배열을 사용하십시오. Score 수준은 구체적인 상황을 설명하고 독립적으로 이해 가능해야 합니다.
필요한 답변을 사용할 수 있도록 유지하십시오. 아무것도 맞지 않을 때는 결과 없음(no-match) 결과를 포함하십시오. 독립적으로 유용할 때는 별도의 존재 판단을 사용하십시오. 소스 값 선택의 경우, 후보 범위를 확인하십시오: 모델은 생략된 값을 선택할 수 없습니다.
구성 및 검증
동일한 상태에 대해 독립적인 질문을 함께 요청하십시오. 여기에는 유용한 추측성 질문도 포함됩니다. 이들은 병렬로 실행되며 서로의 답변을 볼 수 없습니다. 각 추측성 전제를 명시적으로 명시하십시오; 코드는 적용 가능한 답변을 사용합니다. 이전 답변이 증거를 가져오거나, 새로운 상태를 구성하거나, 다음 옵션을 결정하는 데 필요할 때는 두 번째 요청이 정당화됩니다. 추가 질문은 여전히 토큰을 사용합니다. 실제 요청 예산, 비용 및 종단 간 지연 시간을 측정하십시오.
확률과 신뢰도를 사용하여 동작을 안내하고, 사용자 데이터와 결과에 따라 임계값을 평가하십시오. Choice/Score 신뢰도는 분포 집중도를 요약하며, 전체 워크플로 정확성이나 행동 허가를 의미하지 않습니다. 0.5에 가까운 Noul은 '예'와 '아니오'의 확률이 비슷함을 의미하며, 중간 강도를 의미하지 않습니다. 여러 수용 가능한 대안도 확률을 분산시킬 수 있습니다. 낮은 신뢰도가 무해한 선호도 선택을 무효화할 필요는 없습니다. 사용되지 않는 분기의 불확실성은 무시하십시오.
정책을 명시적으로 유지하고 원시 판단을 재사용 가능하게 유지하십시오. 가중치가 적용된 점수는 보상적 선호도에 적합합니다. "심각한 위반" 규칙은 별도의 조건이 필요합니다. 증거와 질문 의미가 변경되지 않은 경우, 가중치나 표시 필터를 변경하기 위해 추론을 다시 실행할 필요가 없습니다. 타입이 지정된 출력은 인터페이스를 보장하지만 진실을 보장하지는 않습니다. System One 모델은 보정된 결정을 위해 훈련됩니다. 대상 도메인에서 성능을 검증하십시오.
대표적인 사례와 결과 애플리케이션 동작을 테스트하십시오. 실패의 경우, 정확한 상태, 질문, 후보, 답변, 구성 및 관찰된 결과를 검사하십시오. 증거 누락, 모델 오류, 코드 오류 및 서비스 오류를 분리하십시오. 쿡북 임계값과 데모 결과는 평가할 예시로 취급하고, 보편적인 규칙이나 영구적인 모델 제한으로 취급하지 마십시오. 웹 앱에서는 API 자격 증명을 서버 측에 유지하십시오.