O Upstage Solar Decide é um modelo de decisão estruturada construído sobre o Solar Mini 4. Lê um estado fornecido e perguntas tipadas e, em seguida, devolve uma decisão para cada pergunta com informação de probabilidade calibrada. O fabricante descreve um processo de decisão numa única passagem para a frente pela rede, que não gera prosa. As aplicações a que se destina incluem encaminhamento, classificação e verificações de políticas, sendo a compreensão do coreano pelo modelo destacada como parte da sua base Solar Mini 4.
Prepare o estado como uma cadeia de texto ou JSON estruturado que descreva os factos a avaliar. A interface do fabricante serializa os valores JSON no prompt. Um esquema de perguntas define separadamente o que decidir, que opções são permitidas e como deve ser interpretada uma avaliação ordenada. Utilize nomes estáveis para as perguntas: as respostas são devolvidas sob os mesmos nomes, o que facilita a associação do resultado à condição original do fluxo de trabalho. Mantenha o estado factual separado das instruções e dos critérios que definem a decisão.
Os três tipos de pergunta têm saídas diferentes. Uma pergunta choice devolve a opção selecionada, as probabilidades das alternativas com nome e um valor de confiança. Uma pergunta noul devolve a probabilidade de verdadeiro para uma condição de sim/não. Uma pergunta score devolve uma pontuação ponderada por probabilidades, uma legenda indexada, probabilidades e confiança. Uma pontuação ordenada pode ser fracionária, porque reflete a distribuição pelos critérios. Preserve estes campos, em vez de reduzir todos os resultados a um simples rótulo ou de tratar a confiança como uma frase explicativa.
Para o encaminhamento de pedidos de suporte, forneça a mensagem efetiva e o histórico relevante e, depois, faça perguntas separadas sobre a intenção, a urgência e uma condição definida, como se a mensagem exprime insatisfação. Descreva as categorias pelo seu significado e dê à escala de urgência uma ordem deliberada. Um esquema de exemplo pode distinguir um pedido sobre o estado de uma entrega, um problema de acesso à conta e um assunto não relacionado, enquanto os critérios de urgência vão de nenhuma ação imediata a revisão imediata. O resultado observável é uma avaliação tipada dessas escolhas, e não uma resposta redigida para o cliente.
Para verificações de políticas, inclua no estado a regra relevante e os factos do registo em conjunto. Defina cada condição de forma suficientemente restrita para que a sua resposta possa ser inspecionada. Um fluxo de trabalho documental pode perguntar se a informação obrigatória está presente, que categoria de revisão se aplica e em que medida o registo cumpre uma norma ordenada de completude. Uma pontuação ou probabilidade não verifica de forma independente os factos do registo. Se faltar informação decisiva, a aplicação precisa de um tratamento deliberado dessa incerteza, em vez de interpretar uma opção selecionada como prova conclusiva.
O fabricante especifica uma janela de contexto de 512K tokens para o Solar Decide. Prepare os documentos grandes como o texto ou o estado estruturado de que a decisão precisa; um contexto grande não implica a análise automática de um ficheiro arbitrário. Preserve os limites das fontes e as passagens relevantes para os critérios. Utilize perguntas focadas, em vez de esperar um resumo aberto do documento. A saída do modelo continua delimitada pelos tipos de pergunta e pelas opções, independentemente da quantidade de material incluída no estado.
Uma pergunta choice aceita de duas a 26 opções na interface documentada do produtor. O fabricante explica que esta via lê as decisões a partir de rótulos de um único token, de A a Z, pelo que mais de 26 candidatos têm de ser reduzidos ou divididos em várias perguntas. Este limite aplica-se às opções de choice, e não é um limite geral ao comprimento do documento nem um limite copiado de outra família de modelos de decisão. Defina as descrições dos candidatos de modo que os seus significados sejam distintos e utilize uma decisão hierárquica apenas quando essa hierarquia corresponder ao fluxo de trabalho real.
Em registos em língua coreana, mantenha intactos o significado da fonte, os nomes e os identificadores e descreva claramente os critérios de decisão. O resultado tipado pode utilizar rótulos estáveis da aplicação ao avaliar evidência em linguagem natural. Quando um registo mistura línguas ou utiliza terminologia de um domínio, mantenha as definições relevantes no estado. Uma interpretação fluente de um termo não basta para estabelecer que os critérios de classificação correspondem à regra de negócio, pelo que deve inspecionar casos ambíguos representativos, bem como casos simples.
Utilize as probabilidades e a confiança devolvidas de acordo com a política de decisão do fluxo de trabalho. Preserve a distribuição e a legenda ordenada quando uma avaliação se situa entre categorias. Defina o tratamento dos resultados incertos a partir de exemplos de tarefas revistos, em vez de inventar um limiar de probabilidade universal. A aplicação executa qualquer ação resultante de encaminhamento, escalamento ou revisão e regista o respetivo resultado. O Solar Decide fornece a avaliação delimitada do modelo utilizada para ponderar essa ação; selecionar uma via não demonstra que uma ação posterior foi executada.
O artefacto final útil é o objeto answers, juntamente com o estado e as definições das perguntas que o produziram. Estes registos permitem inspecionar uma classificação inesperada, distinguir evidência em falta de critérios ambíguos e comparar a avaliação com um caso revisto. Se um utilizador precisar de uma explicação escrita ou de uma resposta conversacional, a decisão e o material de origem podem alimentar uma etapa de redação separada. O papel específico do Solar Decide é produzir decisões tipadas, apoiadas em probabilidades, a partir do texto fornecido, e não gerar ele próprio essa explicação.
", "aboutText": "O Upstage Solar Decide é um modelo de decisão estruturada construído sobre o Solar Mini 4. Lê um estado fornecido e perguntas tipadas e, em seguida, devolve uma decisão para cada pergunta com informação de probabilidade calibrada. O fabricante descreve um processo de decisão numa única passagem para a frente pela rede, que não gera prosa. As aplicações a que se destina incluem encaminhamento, classificação e verificações de políticas, sendo a compreensão do coreano pelo modelo destacada como parte da sua base Solar Mini 4.\n\nPrepare o estado como uma cadeia de texto ou JSON estruturado que descreva os factos a avaliar. A interface do fabricante serializa os valores JSON no prompt. Um esquema de perguntas define separadamente o que decidir, que opções são permitidas e como deve ser interpretada uma avaliação ordenada. Utilize nomes estáveis para as perguntas: as respostas são devolvidas sob os mesmos nomes, o que facilita a associação do resultado à condição original do fluxo de trabalho. Mantenha o estado factual separado das instruções e dos critérios que definem a decisão.\n\nOs três tipos de pergunta têm saídas diferentes. Uma pergunta choice devolve a opção selecionada, as probabilidades das alternativas com nome e um valor de confiança. Uma pergunta noul devolve a probabilidade de verdadeiro para uma condição de sim/não. Uma pergunta score devolve uma pontuação ponderada por probabilidades, uma legenda indexada, probabilidades e confiança. Uma pontuação ordenada pode ser fracionária, porque reflete a distribuição pelos critérios. Preserve estes campos, em vez de reduzir todos os resultados a um simples rótulo ou de tratar a confiança como uma frase explicativa.\n\nPara o encaminhamento de pedidos de suporte, forneça a mensagem efetiva e o histórico relevante e, depois, faça perguntas separadas sobre a intenção, a urgência e uma condição definida, como se a mensagem exprime insatisfação. Descreva as categorias pelo seu significado e dê à escala de urgência uma ordem deliberada. Um esquema de exemplo pode distinguir um pedido sobre o estado de uma entrega, um problema de acesso à conta e um assunto não relacionado, enquanto os critérios de urgência vão de nenhuma ação imediata a revisão imediata. O resultado observável é uma avaliação tipada dessas escolhas, e não uma resposta redigida para o cliente.\n\nPara verificações de políticas, inclua no estado a regra relevante e os factos do registo em conjunto. Defina cada condição de forma suficientemente restrita para que a sua resposta possa ser inspecionada. Um fluxo de trabalho documental pode perguntar se a informação obrigatória está presente, que categoria de revisão se aplica e em que medida o registo cumpre uma norma ordenada de completude. Uma pontuação ou probabilidade não verifica de forma independente os factos do registo. Se faltar informação decisiva, a aplicação precisa de um tratamento deliberado dessa incerteza, em vez de interpretar uma opção selecionada como prova conclusiva.\n\nO fabricante especifica uma janela de contexto de 512K tokens para o Solar Decide. Prepare os documentos grandes como o texto ou o estado estruturado de que a decisão precisa; um contexto grande não implica a análise automática de um ficheiro arbitrário. Preserve os limites das fontes e as passagens relevantes para os critérios. Utilize perguntas focadas, em vez de esperar um resumo aberto do documento. A saída do modelo continua delimitada pelos tipos de pergunta e pelas opções, independentemente da quantidade de material incluída no estado.\n\nUma pergunta choice aceita de duas a 26 opções na interface documentada do produtor. O fabricante explica que esta via lê as decisões a partir de rótulos de um único token, de A a Z, pelo que mais de 26 candidatos têm de ser reduzidos ou divididos em várias perguntas. Este limite aplica-se às opções de choice, e não é um limite geral ao comprimento do documento nem um limite copiado de outra família de modelos de decisão. Defina as descrições dos candidatos de modo que os seus significados sejam distintos e utilize uma decisão hierárquica apenas quando essa hierarquia corresponder ao fluxo de trabalho real.\n\nEm registos em língua coreana, mantenha intactos o significado da fonte, os nomes e os identificadores e descreva claramente os critérios de decisão. O resultado tipado pode utilizar rótulos estáveis da aplicação ao avaliar evidência em linguagem natural. Quando um registo mistura línguas ou utiliza terminologia de um domínio, mantenha as definições relevantes no estado. Uma interpretação fluente de um termo não basta para estabelecer que os critérios de classificação correspondem à regra de negócio, pelo que deve inspecionar casos ambíguos representativos, bem como casos simples.\n\nUtilize as probabilidades e a confiança devolvidas de acordo com a política de decisão do fluxo de trabalho. Preserve a distribuição e a legenda ordenada quando uma avaliação se situa entre categorias. Defina o tratamento dos resultados incertos a partir de exemplos de tarefas revistos, em vez de inventar um limiar de probabilidade universal. A aplicação executa qualquer ação resultante de encaminhamento, escalamento ou revisão e regista o respetivo resultado. O Solar Decide fornece a avaliação delimitada do modelo utilizada para ponderar essa ação; selecionar uma via não demonstra que uma ação posterior foi executada.\n\nO artefacto final útil é o objeto answers, juntamente com o estado e as definições das perguntas que o produziram. Estes registos permitem inspecionar uma classificação inesperada, distinguir evidência em falta de critérios ambíguos e comparar a avaliação com um caso revisto. Se um utilizador precisar de uma explicação escrita ou de uma resposta conversacional, a decisão e o material de origem podem alimentar uma etapa de redação separada. O papel específico do Solar Decide é produzir decisões tipadas, apoiadas em probabilidades, a partir do texto fornecido, e não gerar ele próprio essa explicação.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "f5220f3915d83d288791281351431724dcf1ddac52ed084073664d5827dbf612", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "pt-pt", "methods": [ { "html": "upstage/solar-decideO Upstage Solar Decide é um modelo de decisão sobre texto construído sobre o Solar Mini 4. Avalia um estado fornecido e perguntas tipadas, devolvendo escolhas com nome, probabilidades de verdadeiro ou pontuações ponderadas com informação de probabilidade. A sua saída delimitada suporta classificação, encaminhamento e verificações de políticas, em vez de prosa gerada.
Esta descrição apresenta as capacidades do modelo. As entradas, saídas e opções disponíveis no Ailoot para o método selecionado estão indicadas abaixo.
O Upstage Solar Decide é um modelo de decisão estruturada construído sobre o Solar Mini 4. Lê um estado fornecido e perguntas tipadas e, em seguida, devolve uma decisão para cada pergunta com informação de probabilidade calibrada. O fabricante descreve um processo de decisão numa única passagem para a frente pela rede, que não gera prosa. As aplicações a que se destina incluem encaminhamento, classificação e verificações de políticas, sendo a compreensão do coreano pelo modelo destacada como parte da sua base Solar Mini 4.
Prepare o estado como uma cadeia de texto ou JSON estruturado que descreva os factos a avaliar. A interface do fabricante serializa os valores JSON no prompt. Um esquema de perguntas define separadamente o que decidir, que opções são permitidas e como deve ser interpretada uma avaliação ordenada. Utilize nomes estáveis para as perguntas: as respostas são devolvidas sob os mesmos nomes, o que facilita a associação do resultado à condição original do fluxo de trabalho. Mantenha o estado factual separado das instruções e dos critérios que definem a decisão.
Os três tipos de pergunta têm saídas diferentes. Uma pergunta choice devolve a opção selecionada, as probabilidades das alternativas com nome e um valor de confiança. Uma pergunta noul devolve a probabilidade de verdadeiro para uma condição de sim/não. Uma pergunta score devolve uma pontuação ponderada por probabilidades, uma legenda indexada, probabilidades e confiança. Uma pontuação ordenada pode ser fracionária, porque reflete a distribuição pelos critérios. Preserve estes campos, em vez de reduzir todos os resultados a um simples rótulo ou de tratar a confiança como uma frase explicativa.
Para o encaminhamento de pedidos de suporte, forneça a mensagem efetiva e o histórico relevante e, depois, faça perguntas separadas sobre a intenção, a urgência e uma condição definida, como se a mensagem exprime insatisfação. Descreva as categorias pelo seu significado e dê à escala de urgência uma ordem deliberada. Um esquema de exemplo pode distinguir um pedido sobre o estado de uma entrega, um problema de acesso à conta e um assunto não relacionado, enquanto os critérios de urgência vão de nenhuma ação imediata a revisão imediata. O resultado observável é uma avaliação tipada dessas escolhas, e não uma resposta redigida para o cliente.
Para verificações de políticas, inclua no estado a regra relevante e os factos do registo em conjunto. Defina cada condição de forma suficientemente restrita para que a sua resposta possa ser inspecionada. Um fluxo de trabalho documental pode perguntar se a informação obrigatória está presente, que categoria de revisão se aplica e em que medida o registo cumpre uma norma ordenada de completude. Uma pontuação ou probabilidade não verifica de forma independente os factos do registo. Se faltar informação decisiva, a aplicação precisa de um tratamento deliberado dessa incerteza, em vez de interpretar uma opção selecionada como prova conclusiva.
O fabricante especifica uma janela de contexto de 512K tokens para o Solar Decide. Prepare os documentos grandes como o texto ou o estado estruturado de que a decisão precisa; um contexto grande não implica a análise automática de um ficheiro arbitrário. Preserve os limites das fontes e as passagens relevantes para os critérios. Utilize perguntas focadas, em vez de esperar um resumo aberto do documento. A saída do modelo continua delimitada pelos tipos de pergunta e pelas opções, independentemente da quantidade de material incluída no estado.
Uma pergunta choice aceita de duas a 26 opções na interface documentada do produtor. O fabricante explica que esta via lê as decisões a partir de rótulos de um único token, de A a Z, pelo que mais de 26 candidatos têm de ser reduzidos ou divididos em várias perguntas. Este limite aplica-se às opções de choice, e não é um limite geral ao comprimento do documento nem um limite copiado de outra família de modelos de decisão. Defina as descrições dos candidatos de modo que os seus significados sejam distintos e utilize uma decisão hierárquica apenas quando essa hierarquia corresponder ao fluxo de trabalho real.
Em registos em língua coreana, mantenha intactos o significado da fonte, os nomes e os identificadores e descreva claramente os critérios de decisão. O resultado tipado pode utilizar rótulos estáveis da aplicação ao avaliar evidência em linguagem natural. Quando um registo mistura línguas ou utiliza terminologia de um domínio, mantenha as definições relevantes no estado. Uma interpretação fluente de um termo não basta para estabelecer que os critérios de classificação correspondem à regra de negócio, pelo que deve inspecionar casos ambíguos representativos, bem como casos simples.
Utilize as probabilidades e a confiança devolvidas de acordo com a política de decisão do fluxo de trabalho. Preserve a distribuição e a legenda ordenada quando uma avaliação se situa entre categorias. Defina o tratamento dos resultados incertos a partir de exemplos de tarefas revistos, em vez de inventar um limiar de probabilidade universal. A aplicação executa qualquer ação resultante de encaminhamento, escalamento ou revisão e regista o respetivo resultado. O Solar Decide fornece a avaliação delimitada do modelo utilizada para ponderar essa ação; selecionar uma via não demonstra que uma ação posterior foi executada.
O artefacto final útil é o objeto answers, juntamente com o estado e as definições das perguntas que o produziram. Estes registos permitem inspecionar uma classificação inesperada, distinguir evidência em falta de critérios ambíguos e comparar a avaliação com um caso revisto. Se um utilizador precisar de uma explicação escrita ou de uma resposta conversacional, a decisão e o material de origem podem alimentar uma etapa de redação separada. O papel específico do Solar Decide é produzir decisões tipadas, apoiadas em probabilidades, a partir do texto fornecido, e não gerar ele próprio essa explicação.
POST /v1/systemonetextdecisions| Campo | Tipo | Requisito | Valores e limites | Predefinição |
|---|---|---|---|---|
Campomodel | Tipostring | RequisitoObrigatório | Valores e limites upstage/solar-decide | Predefinição— |
Campoprovider | Tiposchema | RequisitoOpcional | Valores e limites | Predefinição— |
Campoquestions | Tipoobject | RequisitoObrigatório | Valores e limites | Predefinição— |
Camposession_id | Tipostring | RequisitoOpcional | Valores e limites | Predefinição— |
Campostate | Tiposchema | RequisitoObrigatório | Valores e limites | Predefinição— |
Campotrace | Tiposchema | RequisitoOpcional | Valores e limites | Predefinição— |
Campouser | Tipostring | RequisitoOpcional | Valores e limites | Predefinição— |
Campoquestions.<id>.type | Tipostring | RequisitoObrigatório | Valores e limites noul, choice, score | Predefinição— |
Campoquestions.<id>.instructions | Tipostring|object|array | RequisitoObrigatório | Valores e limites | Predefinição— |
Campoquestions.<id>.criteria | Tipoobject|array | RequisitoOpcional | Valores e limites Condições: choice/score: obrigatório; noul: opcional. Os critérios de choice são um objeto; score é uma matriz com minItems1. | Predefinição— |
Campoquestions.<id>.criteria.true | Tipostring|object|array | RequisitoObrigatório | Valores e limites Aplica-se quando: Objeto de critérios noul fornecido | Predefinição— |
Campoquestions.<id>.criteria.false | Tipostring|object|array | RequisitoObrigatório | Valores e limites Aplica-se quando: Objeto de critérios noul fornecido | Predefinição— |
noul · Obrigatório: state, questions.<id>.type=noul, questions.<id>.instructions
choice · Obrigatório: state, questions.<id>.type=choice, questions.<id>.instructions, criteria object
score · Obrigatório: state, questions.<id>.type=score, questions.<id>.instructions, criteria array with minItems1
| Parâmetro | Contrato |
|---|---|
Parâmetrocontent_type | Contratoapplication/json |
Parâmetrorequired | Contratomodel, state, questions |
Parâmetromaterial_types | Contratotext |
Parâmetrooptional_controls | Contratoprovider, session_id, trace, user |
Parâmetromultimodal_input_binding | Contratonull |
Ciclo de vida: synchronous
Envie o ID exato do modelo e conserve a resposta nativa completa.
As referências tarifárias não acrescentam opções ao pedido. Os parâmetros suportados constam do método selecionado.
Associe cada custo às condições apresentadas. Use uma única tarifa para cada conjunto de configurações alternativas.
| Configuração | Tabela de tarifas | Tokens de contexto, mais de | Tokens de contexto, até ao limite inclusive | Custo |
|---|---|---|---|---|
| ConfiguraçãoTarifas base dos tokens | Tabela de tarifasTarifa base | Tokens de contexto, mais de— | Tokens de contexto, até ao limite inclusiveSem limite superior | Custo Entrada · Tokens de entrada $0.0002 / 1K tokens Saída · Tokens de saída $0 / 1K tokens Entrada · Leitura da cache $0.0002 / 1K tokens Entrada · Escrita na cache — / 1K tokens Entrada · Escrita na cache, 1 hora — / 1K tokens |
| ConfiguraçãoEscalão 1 por comprimento do pedido | Tabela de tarifas— | Tokens de contexto, mais de0 | Tokens de contexto, até ao limite inclusiveSem limite superior | Custo Entrada · Tokens de entrada $0.0002 / 1K tokens Saída · Tokens de saída $0 / 1K tokens Entrada · Leitura da cache $0.0002 / 1K tokens Entrada · Escrita na cache — / 1K tokens Entrada · Escrita na cache, 1 hora — / 1K tokens |
O Ailoot reserva um montante estimado antes de um pedido. Após o resultado, liquida o custo final com base na utilização medida. No streaming, a liquidação usa o registo final de utilização. Como funcionam a reserva e a liquidação →
{\n "model": "upstage/solar-decide",\n "questions": {\n "is_bug": {\n "criteria": {\n "false": "The customer is asking a question or requesting a feature.",\n "true": "The customer describes broken or unexpected product behavior."\n },\n "instructions": "Is the customer reporting a software defect?",\n "type": "noul"\n },\n "team": {\n "criteria": {\n "account": "Login, permissions, or profile issues.",\n "frontend": "Rendering, layout, or browser compatibility issues.",\n "payments": "Checkout, billing, or payment processing issues."\n },\n "instructions": "Which team should own this ticket?",\n "type": "choice"\n },\n "urgency": {\n "criteria": [\n "Can wait for the next release",\n "Should be fixed this week",\n "Blocking revenue right now"\n ],\n "instructions": "How urgent is this ticket?",\n "type": "score"\n }\n },\n "state": {\n "customer_tier": "enterprise",\n "ticket": "My checkout page shows a blank screen after I click Pay. I have tried two browsers."\n }\n}set -eu\n: "${AILOOT_API_KEY:?Set your Ailoot API key}"\n: "${AILOOT_REQUEST_FILE:?Set your actual JSON request file}"\nexport AILOOT_REQUEST_FILE\npython3 - <<'PY_REQUEST'\nimport json,os\nfrom pathlib import Path\np=json.loads(Path(os.environ['AILOOT_REQUEST_FILE']).read_text(encoding='utf-8'))\nif not isinstance(p,dict): raise SystemExit('Request must be a JSON object')\np['model']='upstage/solar-decide'\nPath('request.json').write_text(json.dumps(p,ensure_ascii=False),encoding='utf-8')\nPY_REQUEST\ncurl --fail-with-body --silent --show-error https://api.ailoot.ai/v1/systemone \\\n -H "Authorization: Bearer $AILOOT_API_KEY" -H 'Content-Type: application/json' \\\n --data-binary @request.json -D response-headers.txt -o result.json\npython3 - <<'PY_RESULT'\nimport json\nfrom pathlib import Path\nprint(json.dumps(json.loads(Path('result.json').read_text()),ensure_ascii=False,indent=2))\nPY_RESULT\njson
Guarde cada resposta, ficheiro e parte de conteúdo devolvidos na íntegra.
É conservada cada resposta fornecida a um ID de pergunta, com o respetivo tipo exato, valor noul/choice/score, confiança, probabilidades e legenda. O JSON original completo é armazenado e devolvido apenas após a liquidação.
Conserve a operação original e a resposta completa/parcial; não repita o POST.
| Campo | Tipo |
|---|---|
Campomodel | Tipostring |
Campoid | Tipostring |
Campoprovider | Tipostring |
Campoanswers.<id>.type | Tipostring |
Campoanswers.<id>.noul | Tiponumber |
Campoanswers.<id>.choice | Tipostring |
Campoanswers.<id>.score | Tiponumber |
Campoanswers.<id>.confidence | Tiponumber |
Campoanswers.<id>.probabilities | Tipoobject |
Campoanswers.<id>.legend | Tipoobject |
Campousage.input_tokens | Tipointeger |
Campousage.output_tokens | Tipointeger |
Campousage.cost | Tiponumber |
| Resposta | Condição | Passo seguinte |
|---|---|---|
Resposta400 · invalid_request_error | CondiçãoCampo obrigatório, representação ou valor inválido | Passo seguinteCorrija o campo indicado no pedido. |
Ailoot Ultra upstage/solar-decide
Use os caminhos dos métodos indicados acima.