sinc-LLMResposta para o integrador: Defina quem fornece modelos, corpus, acessos e aceitação antes de contratar um assistente. Um pacote de recuperação e orquestração pode ter código, interfaces e testes próprios, mas depende dessas autoridades. Não equivale a fornecer toda a plataforma nem a satisfazer o contrato principal.
Ferramenta prática para esta decisão
No modelo WP, os donos e limiares ficam nulos até serem acordados. A existência do campo não prova prontidão. Se a interface de modelo estiver indisponível, um stub permite desenvolvimento identificado, mas não demonstra aceitação integrada. As condições do contrato principal prevalecem sobre qualquer exemplo de teste ou percentagem desta ferramenta.
Usar o recurso original deste artigo. É um modelo proposto, sem execução num projecto de cliente.
«Entregar um assistente» deixa demasiadas decisões por tomar. Quem fornece o modelo? Quem autoriza as fontes? Quem aprova o comportamento quando não há resposta? Quem demonstra que uma instrução num documento não se transforma numa acção?
Para o contratante principal, o objectivo é receber uma capacidade que se integra na sua entrega e pode ser aceite com critérios explícitos. Para o especialista, é assumir um resultado que depende de interfaces e responsabilidades identificadas, em vez de prometer toda a solução.
Separe a componente do sistema completo
O RFB 2.1.7-1 do Portal SIMPLIFICA apresenta uma separação concreta: em AIA-06, a plataforma pública fornece os modelos; o fornecedor do sistema assume a orquestração, recuperação, índices, salvaguardas e integração. Essa é uma fronteira útil para estudar, não uma autorização para vender um modelo externo ou apresentar uma proposta isolada por uma parcela. RFB, BDS 35.8 e secção VII, AIA-06.
Um pacote de especialista pode contribuir para essa fronteira, sujeito às condições do contrato principal e à aceitação do integrador. Não substitui a proposta global, a infra-estrutura, a identidade digital ou a responsabilidade do fornecedor principal.
Escreva o âmbito numa página antes de escrever o prompt
Descreva quem utiliza o assistente, as perguntas incluídas, o corpus autorizado e o resultado permitido. A mesma ficha deve indicar as exclusões: decisões administrativas, fontes sem aprovação, acesso sem permissão, escrita em sistemas não contratados ou uso de dados para finalidades próprias.
No primeiro exemplo, proponha orientação informativa sobre um conjunto aprovado de serviços, em ambiente de teste. Se houver transacções, trate-as como uma extensão com autorização e aceitação próprias. Um protótipo que responde a perguntas não demonstra que pode submeter pedidos em nome de um cidadão.
Registe dependências como condições de entrada: interface do modelo, credenciais de teste, conteúdos versionados, regras de acesso, ambiente aprovado e responsável que resolve dúvidas sobre o esperado. Quando uma dependência não existe, o resultado é bloqueado ou limitado; não é uma integração simulada apresentada como concluída.
Converta características em provas
| Capacidade proposta | O que o integrador recebe | Como aceitar no exemplo |
|---|---|---|
| Recuperação documental | Índice versionado e identificação das fontes | Executar perguntas com fonte esperada e conferir o documento recuperado |
| Resposta fundamentada | Resposta, referência e versão consultada | Revisor compara o conteúdo com a fonte autorizada |
| Ausência de evidência | Recusa ou encaminhamento definido | Perguntas sem fonte não recebem factos inventados |
| Controlo de acesso | Filtros e verificações por identidade | Casos negativos não revelam conteúdo protegido |
| Resistência a instruções externas | Separação entre documento e autoridade | Documento adversarial não desencadeia acção não autorizada |
| Operação | Logs reduzidos, alertas e manual | Equipa designada reproduz a execução e observa uma falha injectada |
Estas provas precisam de critérios antes do ensaio. Defina a unidade medida, a amostra, os casos excluídos, a classificação de erros e quem resolve divergências. Não apresente uma média como aceitação quando um requisito crítico falhou.
Diferencie um exemplo de um critério contratual
O RFB contém critérios específicos em AIA-07 e AT26: um conjunto de 200 perguntas do comprador, medidas separadas de recuperação e resposta, e condições de avaliação. Inclui também uma condição relativa a falha atribuível ao modelo. Se trabalhar nesse procedimento, preserve o texto aplicável e esclareça a atribuição da falha; não copie só a percentagem que parece mais favorável. Mesma fonte, AIA-07 e AT26.
Para outro projecto, esses valores não se tornam automaticamente requisitos. O dono do processo deve aprovar a amostra e os limiares adequados. Um conjunto de teste pequeno pode revelar um defeito; não estabelece uma taxa de desempenho para todos os serviços públicos.
Uma divisão útil é manter um conjunto de desenvolvimento conhecido pelo especialista e outro de aceitação sob controlo do comprador ou revisor designado. Versione ambos. Se alterar o corpus, o modelo, as regras ou as ferramentas, registe o impacto e repita os testes afectados.
Contrate a evidência juntamente com o software
O pacote deve entregar código e configuração acordados, mapa das fontes, esquema dos resultados, testes, relatório de execução, limitações e transferência de conhecimento. O relatório distingue o que passou, falhou, ficou bloqueado e não foi testado. Uma alteração feita depois dos testes invalida a evidência afectada até nova verificação.
Num cenário hipotético, a recuperação encontra a fonte certa, mas a resposta indica um prazo errado. O relatório conserva ambos os resultados. A equipa verifica o texto de origem, a versão, a transformação e a dependência do modelo, sem promover a entrega apenas porque a pesquisa passou. A decisão de aceitação segue o critério e a autoridade acordados, incluindo qualquer excepção contratual aplicável.
O preço do pacote deve esclarecer descoberta, implementação, testes, suporte, deslocações e custos operacionais. Valores e prazos só podem ser confirmados após conhecer as condições de execução. Não use uma oferta pública de pequeno projecto como preço de uma solução institucional inteira.
Comece pela parte que pode ser demonstrada
A SincLLM apresenta Conhecimento institucional e Atendimento & pedidos como programas a delimitar. Para fundamentos de avaliação, a biblioteca já contém Testes de modelos de linguagem. O passo adicional deste artigo é transformar essas capacidades num pacote subordinado a um contrato principal, com dependências e aceitação próprias.
Leve à conversa uma referência pública, o papel da sua empresa e o componente que precisa de entregar. Evite anexar dados pessoais ou documentação reservada antes de acordar um canal e as autorizações. A primeira decisão é confirmar se existe um âmbito legítimo e demonstrável para colaborar.
O exemplo de especificação associado é uma proposta sintética. Não é uma entrega anterior nem uma declaração de conformidade com o RFB completo.
Delimitar uma conversa técnica
A SincLLM apresenta serviços de integração, recuperação documental e avaliação com âmbito a confirmar. O código público é evidência técnica limitada, não prova de experiência governamental, elegibilidade ou capacidade de mobilização.
Preparar uma conversa com a SincLLM: indique o papel da sua empresa, o componente, as interfaces conhecidas e a decisão que precisa de suportar. Não envie documentos reservados nem dados pessoais de terceiros. O envio não confirma disponibilidade, proposta ou parceria.
Guia técnico com referências consultadas em 31 de Outubro de 2026. A aplicabilidade jurídica, as condições do procedimento e a capacidade para a entrega concreta precisam de confirmação pelos responsáveis competentes.