Relatórios de Ciência da Computação e detecção de IA: código, pseudocódigo e a prosa entre eles

A posição publicada da Turnitin sobre código é curta e específica: o modelo "does not reliably detect AI-generated text in the form of non-prose, or code" (não detecta de forma confiável texto gerado por IA na forma de texto não narrativo ou código), e o FAQ acrescenta que a Turnitin está "not pursuing ChatGPT code detection at this time." (não buscando detecção de código do ChatGPT neste momento). Então suas listagens, seus blocos de pseudocódigo e suas transcrições de terminal não são o assunto do percentual de IA. O assunto são os parágrafos entre eles, que num relatório de CC significam a justificativa de projeto, o passo a passo do algoritmo, a análise de complexidade e a discussão de avaliação. Esses parágrafos também são a escrita mais uniforme do documento, porque boa escrita técnica deve ser uniforme.

À parte tudo isso: o que seu departamento permite que você gere é definido pela política de integridade acadêmica dele, não pelo que um detector mede. Responder uma dessas perguntas não responde a outra, e tratar as duas como a mesma pergunta é assim que as pessoas acabam numa reunião.

Duas frases sustentam tudo. A primeira está na definição do FAQ sobre o que é analisado:

"The model does not reliably detect AI-generated text in the form of non-prose, or code, nor does it detect short-form/unconventional writing such as bullet points (short non-sentence structures)." (O modelo não detecta de forma confiável texto gerado por IA na forma de texto não narrativo ou código, e tampouco detecta escrita curta ou não convencional, como listas com marcadores: estruturas curtas que não são frases.)

Leia mais uma linha, porque é ali que isso fica útil:

"This means that a document containing several different writing types would result in a disparity between the percentage and the highlights." (Isso significa que um documento com vários tipos diferentes de escrita pode gerar uma disparidade entre o percentual e os destaques.)

Um relatório de CC é, por construção, um documento com vários tipos diferentes de escrita, então essa disparidade é o estado normal desse gênero, não uma anomalia. O guia do relatório enuncia a mesma exclusão com uma lista mais longa, citando poesia e roteiros ao lado de código, e acrescentando tabelas e bibliografias anotadas ao lado da escrita curta.

A segunda frase costuma circular sem o contexto em volta, então vale dizer onde ela mora. É a última linha da resposta a "Why is AI detection not being added to Gradescope?" (Por que a detecção de IA não está sendo adicionada ao Gradescope?), e essa resposta diz: a Turnitin "not currently have plans to add these capabilities to Gradescope, since the primary use case for Gradescope is handwritten text while for AI detection we're focusing on typed text" (não tem planos atuais de adicionar esses recursos ao Gradescope, já que o uso principal do Gradescope é texto manuscrito, enquanto na detecção de IA estamos focando em texto digitado), e depois, "In addition, we are not pursuing ChatGPT code detection at this time." (Além disso, não estamos buscando detecção de código do ChatGPT neste momento.)

Isso importa mais para ciência da computação do que para qualquer outra disciplina, porque o Gradescope é onde muita tarefa de programação é entregue. Se a sua implementação vai para um corretor automático e o seu relatório escrito vai para uma atividade no Turnitin, são dois fluxos com funções diferentes, e o percentual de escrita por IA que você vê no fim foi calculado no segundo. Qual produto da Turnitin tem detecção de IA cobre o lado de licenciamento dessa divisão.

A definição está no guia do relatório, e os exemplos dela merecem atenção:

"Qualifying text (prose sentences contained in long-form writing format) means individual sentences contained in paragraphs that make up a longer piece of written work, such as an essay, a dissertation, or an article, etc." (Texto elegível, ou seja, frases de prosa contidas num formato de escrita longa, significa as frases individuais contidas nos parágrafos que compõem um trabalho escrito mais longo, como uma redação, uma dissertação ou um artigo, etc.)

Uma redação, uma dissertação, um artigo. Um relatório de projeto escrito no registro de uma referência de API não é nenhum dos três, e a Turnitin não publica um parecer sobre isso. O que ela publica é o teste da frase, então aqui está esse teste aplicado elemento por elemento. Este é o nosso mapeamento, não o do fornecedor.

Dessa tabela saem duas consequências. O seu denominador é pequeno, então o percentual é uma afirmação sobre uma fatia do arquivo, não sobre o arquivo, e o FAQ diz isso com todas as letras: "This percentage is not necessarily the percentage of the entire submission. If text within the submission is not considered long-form prose text, it will not be included." (Este percentual não é necessariamente o percentual de toda a submissão. Se um texto dentro da submissão não for considerado prosa longa, ele não será incluído.) E se o relatório tem muitas listagens, a prosa elegível pode cair o suficiente para que o comportamento tudo ou nada de documentos curtos se torne relevante. Os requisitos de arquivo dizem que uma submissão precisa de "at least 300 words of prose text in a long-form writing format" (pelo menos 300 palavras de texto em prosa em formato de escrita longa) antes que qualquer relatório seja produzido.

A Turnitin publica uma descrição do que os seus falsos positivos costumam ter em comum:

"Sometimes false positives (incorrectly flagging human-written text as AI-generated), can include content without a lot of structural variation, text that literally repeats itself, or text that has been paraphrased without developing new ideas." (Às vezes os falsos positivos, ou seja, marcar incorretamente texto escrito por humano como gerado por IA, podem incluir conteúdo sem muita variação estrutural, texto que se repete literalmente ou texto parafraseado sem desenvolver ideias novas.)

E a frase seguinte, que é dirigida a quem vai corrigir, não a você:

"If our indicator shows a higher amount of AI writing in such text, we advise you to take that into consideration when looking at the percentage indicated." (Se o nosso indicador mostrar uma quantidade maior de escrita por IA nesse tipo de texto, recomendamos que você leve isso em consideração ao olhar o percentual indicado.)

Agora leia essas duas propriedades contra um documento técnico bem escrito. A variação estrutural é justamente o que uma seção de referência remove de propósito: toda função recebe o mesmo molde, nome, depois parâmetros, depois valor de retorno, depois modos de falha, para que um leitor que aprendeu o molde uma vez possa passar o olho no resto. Dizer a mesma coisa do mesmo jeito duas vezes é exatamente como você avisa ao leitor que dois componentes se comportam igual. Um guia de estilo que mandasse você variar a forma de cada entrada seria um guia de estilo ruim.

A mesma forma aparece no passo a passo do algoritmo, por um motivo diferente. Essa seção normalmente reformula em inglês o que a listagem acima dela já diz. Reformular algo não tem para onde ir do ponto de vista estilístico. Todo passo começa com o passo, toda frase tem o mesmo sujeito, e o parágrafo é uma transcrição do fluxo de controle.

Dois limites honestos aqui. A Turnitin não dá frequência para essas propriedades, só uma lista do que os falsos positivos "podem incluir", então ninguém pode dizer quanto desse efeito isso explica. E o comportamento do modelo não é um manual do qual você possa raciocinar de trás para a frente: o FAQ diz "Our model is not explicitly programmed to evaluate specific signals such as 'burstiness,' 'perplexity,' or other individual metrics sometimes referenced in public discussions." (O nosso modelo não é programado explicitamente para avaliar sinais específicos como 'burstiness,' 'perplexity,' ou outras métricas individuais às vezes citadas em discussões públicas.) O mito da perplexidade e da burstiness traz a versão mais completa, incluindo a frase que está em outro ponto da mesma página e que impede você de ler demais essa daqui.

Aqui está a assimetria que faz os relatórios de CC diferentes de redações. O conteúdo excluído da medição não é pano de fundo inerte. É a parte do documento em que um único caractere alterado deixa o documento errado, e uma revisão lê isso, haja ou não alguém pontuando.

Existe uma segunda falha, mais difícil de ver, porque o resultado lê perfeitamente bem. Um documento técnico dá um nome a cada conceito. Se uma revisão deixa `hash map` na seção 3 e `dictionary` na seção 4 para o mesmo objeto, ou alterna entre `worker` e `thread`, o documento deixou de dizer ao leitor se aquilo é uma coisa ou duas, e quem corrige não consegue resolver isso sem ler o seu código. Isso é dano ao documento, e nenhuma pontuação entra nessa história. Vale explicitar, porque isso vai contra um hábito que serve a você em todo outro lugar: na maior parte da escrita um termo definido é uma escolha de palavra, e neste gênero ele está mais perto de um identificador.

Nenhuma delas precisa de ferramenta que você já não tenha aberta.

• Copie todos os comandos do documento e rode num diretório de testes. Instruções de configuração são as primeiras a apodrecer e as últimas que alguém relê.
• Liste os identificadores que o seu código define e procure cada um no documento. Tudo o que está no código e falta no documento é uma renomeação que aconteceu sem você.
• Escolha os seus cinco termos de conceito mais importantes e procure cada um. Um nome por conceito, em todo lugar, ou corrija agora.
• Leia cada afirmação de complexidade contra a função que ela descreve. `O(n log n)` e "eficiente" não são intercambiáveis, e só um dos dois é pontuável.
• Compare tudo que está entre aspas com uma execução real. Linhas de log e mensagens de erro são citações.

Se o bloco marcado é o seu passo a passo do algoritmo, existe uma pergunta que vale fazer antes de mexer nas frases: essa seção está fazendo algo que a listagem acima dela já não faz? Um passo a passo que só renomeia as variáveis e acrescenta "depois" entre os passos é conteúdo duplicado num relatório, diga o detector o que disser. A versão que merece o seu lugar explica por que o laço está estruturado assim, qual era a alternativa e onde ele quebra.

É também onde a sua escrita tem para onde ir. Justificativa de projeto, alternativas rejeitadas, o bug que levou dois dias, o que o benchmark não mede, a limitação que você corrigiria com mais uma semana. Esses parágrafos variam de forma porque o pensamento neles varia. Seções estilo referência não variam, e não deveriam.

Vale ser direto sobre os limites desse conselho: estou descrevendo o que torna um relatório melhor de ler e melhor de corrigir. Ninguém, nós incluídos, pode dizer o que isso faz com um número. A Turnitin não publica a função de agrupamento nem o tamanho do segmento, e avisa que o próprio modelo "may not always be accurate (it may misidentify human-written, AI-generated, and AI-paraphrased text), so it should not be used as the sole basis for adverse actions against a student." (pode nem sempre ser preciso, pois pode identificar mal texto escrito por humano, gerado por IA e parafraseado por IA, por isso não deve ser usado como única base para medidas desfavoráveis a um estudante.)

O que torna um relatório de CC lento de revisar tem pouco a ver com frases. Um parágrafo reescrito pode carregar quatro identificadores, uma flag e um número de versão, e cada um deles precisa ser conferido contra o código antes de você poder confiar no parágrafo. Conte o custo em parágrafos mexidos.

É por isso que A ferramenta HumanPen faz você definir o escopo primeiro. Envie o documento e depois marque as passagens ou importe um relatório de IA da Turnitin ou do iThenticate e deixe que as passagens marcadas por ele definam o limite. Tudo fora disso fica intocado, o que neste gênero significa que as suas listagens e os seus blocos de comando não entram na revisão, a menos que você os coloque lá. O motor não trabalha com menos de um parágrafo, então uma seleção que termina no meio de um parágrafo é ampliada para cobri-lo inteiro e mostrada para você confirmar antes, e os créditos contam as palavras efetivamente reescritas. A terminologia está na lista de coisas que ele busca preservar, ao lado de estrutura, citações e layout. As passagens que ainda ficarem marcadas depois podem ser reescritas novamente sem custo, quando as condições para isso forem atendidas.

Há uma linha no FAQ dele sobre revisar documentos complexos depois do download. Para um relatório cheio de identificadores, isso significa o checklist da seção anterior, não uma leitura corrida. A versão em nível de documento do que quebra numa ida e volta, incluindo campos e referências cruzadas, está em Campos do Word, sumários e referências cruzadas.

A Turnitin detecta código gerado por IA? A Turnitin diz que o seu modelo não detecta de forma confiável texto gerado por IA na forma de texto não narrativo ou código, e o FAQ diz que não está buscando detecção de código do ChatGPT neste momento. Isso é uma afirmação sobre o que este relatório mede. Não é uma afirmação sobre o que a sua instituição permite, que é um documento separado que você deve ler.

O meu bloco de pseudocódigo é pontuado? A regra publicada é que o modelo analisa frases de prosa dentro de parágrafos, e lista estruturas curtas e estruturas que não são frases como coisas que ele não detecta. Um bloco de pseudocódigo é estruturado em linhas, não em frases. O parágrafo que o apresenta é prosa.

Por que os destaques ficam tão concentrados numa seção? Em parte é aritmética. Se a maior parte do seu arquivo está excluída, os destaques só podem aparecer no que sobrou. A Turnitin também descreve pontuar segmentos sobrepostos e agrupar os valores, então trechos uniformes de texto tendem a produzir resultados uniformes, em vez de uma dispersão.

A minha seção de análise de complexidade voltou marcada e eu escrevi cada palavra dela. Isso acontece, e o parágrafo do FAQ sobre falsos positivos é o que você deve colocar na frente de quem corrige, especialmente a frase final, que os aconselha a levar em conta a característica do texto ao ler o percentual. O que ele não faz é resolver a autoria, em nenhum dos dois sentidos.

O meu relatório é quase só listagens e nenhum relatório de IA foi gerado. Verifique o piso antes de assumir que algo falhou. Os requisitos de arquivo dizem que uma submissão precisa de pelo menos 300 palavras de texto em prosa em formato de escrita longa, e um relatório com muitas listagens pode ficar abaixo disso mesmo quando a contagem de páginas parece saudável. A lista geral de exclusões está em que conteúdo a IA da Turnitin ignora.