3 pontos por alfadur 3 시간 전 | Ainda não há comentários. | Compartilhar no WhatsApp
  • Recentemente, o conceito de "Software Factory" vem ganhando grande destaque no setor de software. Trata-se de um novo paradigma em que agentes de IA executam por conta própria várias etapas de trabalho de acordo com um objetivo definido e ficam responsáveis por escrever o código-fonte, enquanto os desenvolvedores se concentram em construir e evoluir o sistema, ou seja, a "fábrica", para produzir esse código de forma estável.
  • Dru Knox, da Tessl, empresa de ferramentas de desenvolvimento com IA, chamou essa nova disciplina de desenvolvimento de Harness Engineering.
  • Harness, como o arreio colocado em um cavalo, significa todo o framework que controla e coloca os agentes de IA em funcionamento, e no centro desse framework existem três loops (Loop, um ciclo que repete o mesmo procedimento).
  • O que o vídeo aborda: o que é uma software factory e as três métricas que a definem / por que a Tessl proibiu sessões internas de codificação conversacional e o que aconteceu depois / as três camadas chamadas inner, outer e meta loop / por que harness engineering é difícil / como o change review e o verifier da Tessl implementaram isso na prática
  • Vídeo: https://www.youtube.com/watch?v=D_cw-k0F1DM&t=236

Aplicando a mesma estrutura à produção de conhecimento

  • A knowledge factory é um sistema em que agentes de IA escrevem páginas de wiki, e humanos projetam e operam o "sistema de redação" que permite escalar essa produção. O operador não escreve os artigos diretamente; ele gerencia as diretrizes de escrita e os mecanismos automatizados de revisão.
  • A organização interna da fábrica foi inspirada em cinco papéis de uma redação jornalística: repórter, colunista, revisão, desk e editor-chefe.
  • O ponto principal aqui é que nem todos os cinco papéis são "IAs que julgam". A "revisão" não é IA, mas código Python baseado em regras, e o "editor-chefe" é um coordenador que distribui o trabalho. O único lugar em que a IA toma um julgamento avaliativo independente é o "desk".
  • Um projeto de fábrica eficiente não consiste em simplesmente aumentar o número de agentes, mas em definir com clareza onde colocar e de onde excluir a camada de julgamento.

Os três eixos de maturidade, e a confiança

  • A maturidade do sistema é medida em três eixos: autonomia (conclusão da página sem intervenção humana), automação (até que ponto se permite publicar sem revisão humana) e qualidade (nível do conhecimento produzido).
  • Mesmo com alta autonomia, se o operador estiver inseguro e revisar manualmente todas as páginas, o nível de automação continua baixo. O elemento central para fechar essa lacuna é justamente a "confiança".
  • Primeiro se garante a autonomia; depois, a área de automação é expandida na medida em que a confiança se acumula; e, nesse processo, o nível de qualidade é mantido de forma consistente. E o mecanismo que sustenta essa confiança são os "loops".

1. Inner Loop — autoverificação em tempo real

  • O inner loop é um procedimento rápido e leve de verificação que o agente executa repetidamente durante a escrita, antes de entregar o rascunho. Quanto mais sofisticado esse loop, mais o agente de IA corrige seus próprios erros sem intervenção humana e, como resultado, maior é a autonomia.
  • Durante a escrita, ele verifica apenas os documentos que criou usando a ferramenta de inspeção em Python (tools/lint.py), e, se o mesmo erro se repetir duas vezes ou mais, encaminha imediatamente para a próxima etapa para manter a velocidade do processo.

2. Outer Loop — a dupla barreira antes da publicação

  • A 1ª barreira é a revisão. O código Python faz uma inspeção estática de 10 áreas, como links, citações, estrutura do documento e conflitos de dados, com base em regras determinísticas.
  • A 2ª barreira é o desk. Ele faz uma avaliação qualitativa sob a perspectiva de um leitor externo em seis aspectos, como viés, densidade de informação, legibilidade e fluxo argumentativo, e devolve apenas uma lista de melhorias, sem editar diretamente.
  • Isso é idêntico à estrutura de duas etapas da software factory: verifier (1ª barreira) e change review (2ª barreira).
  • Há aqui um princípio de projeto decisivo. Ao desk são entregues apenas o texto finalizado e os critérios de avaliação; a intenção de escrita do autor não é repassada. Como a própria pessoa tende a ser mais indulgente ao revisar seu texto dentro do mesmo contexto, a informação é bloqueada desde o início para evitar esse viés.
  • O verdadeiro diferencial deste sistema não está em quantos agentes foram ativados, mas nesse isolamento de contexto. Se houver três rejeições pelo mesmo motivo, o fluxo automático é interrompido e a decisão é passada a um operador humano.

3. Meta Loop — mecanismo de autoaperfeiçoamento

  • Ele segue o princípio de que "o mesmo erro não deve ser repetido duas vezes; todo erro descoberto deve ser promovido a regra do sistema".
  • Quando o mesmo defeito continua ocorrendo, uma proposta de revisão das diretrizes de escrita é sugerida automaticamente. A proposta passa por uma avaliação comparativa cega, na qual se oculta qual texto foi escrito com a regra revisada, e por testes com novos casos de falha que nunca foram usados na verificação.
  • Ela só é incorporada ao sistema quando a pontuação realmente melhora e somente após a aprovação final de um operador humano.
  • Observações recorrentes são promovidas a hooks em Python ou regras de revisão, consolidando-se em código. Ao transferir julgamentos qualitativos para a área de inspeção por regras, ajuda-se o desk a se concentrar constantemente em problemas de nível mais alto.

4. Reground Loop — o 4º loop necessário apenas para conhecimento

  • O código de software, uma vez compilado e distribuído, tende a permanecer estável até que a especificação mude, mas ativos de conhecimento envelhecem com o tempo, à medida que cresce a distância em relação aos fatos da realidade.
  • Para resolver isso, foi adicionado como quarto loop o reground loop (Reground, no sentido de voltar a se apoiar nas evidências), que realimenta documentos já publicados como entrada da fábrica de produção de conhecimento.
  • Atualização: quando ocorre alguma mudança na fonte original de dados. O colunista reanalisa e atualiza páginas desatualizadas identificadas pela ferramenta de inspeção. (cobertura posterior)
  • Follow-up: quando existe no documento alguma frase com "verificação futura necessária" ou com condição temporal explícita. Quando o prazo chega, o desk e o operador fazem a revalidação. (cobertura de acompanhamento)
  • Correção: quando é detectado conflito de informações entre nossas páginas. O desk relê conjuntos inteiros de documentos no nível de cluster publicado, captando inconsistências que não aparecem ao analisar cada texto isoladamente. (cobertura de correção)

Human-in-the-Loop

  • As situações excepcionais que exigem aprovação humana são definidas e gerenciadas com checklists claros, sem depender de intuição.
  • Atualmente, a operação busca alta autonomia, mas mantém a automação deliberadamente contida. Os agentes escrevem as páginas por conta própria, mas a publicação na Wiki e mudanças nas regras de escrita ainda exigem aprovação final humana.

Texto completo: https://alfadur7.github.io/llm-wiki-newsroom/ko/knowledge-factory/

Ainda não há comentários.

Ainda não há comentários.