Verificador de plágio open source.
O único verificador de plágio com camada em nuvem para produção e motor totalmente open source. O mesmo código que roda em noplag.com está disponível no GitHub em github.com/NoplagLabs/noplag-engine — audite, faça fork, ou faça a autohospedagem.
O mesmo commit de noplag.com é o commit no GitHub.
Sem ambiguidades sobre open source. Não é apenas um repositório de SDK com o motor em código fechado. O chunker, fingerprinter, cascata de recuperação e montador de relatórios estão todos no mesmo repositório Apache 2.0 que gera nosso container de produção.
Engine de detecção de plágio que alimenta o noplag.com — chunking, winnowing fingerprints, cascade de busca, alinhamento e montagem de relatórios. Apache 2.0.
- LINGUAGEM
- Python · Rust
- LICENÇA
- Apache 2.0
- CONTRIBUIDORES
- 38
- COMMITS
- 2.847
- ÚLTIMO RELEASE
- v0.4.2 · há 3 dias
- CI
- passando · 412 testes
Código fechado era bug, não feature.
Todo verificador de plágio antes de nós pedia para confiar numa caixa preta. Confiar no score. Confiar numa metodologia invisível. Confiar que o algoritmo não foi ajustado para marcar seu estilo de escrita. Nós escolhemos a aposta oposta.
O que você não vê, você não confia
Um score de similaridade é só um número sem origem clara. Foi um match de sentenças, um chute de paráfrase, uma alucinação de detector de IA? O sistema considerou seu perfil de escrita de ESL? Checadores fechados nunca respondem — porque o poder deles É você não poder perguntar. Não aceitamos isso como custo da detecção de plágio.
Produto open source, não apenas marketing open source
O repositório Apache 2.0 em github.com/NoplagLabs/noplag-engine não é um SDK de cliente limitado com o algoritmo de comparação fechado. O chunker, o fingerprinter winnowing, a cascata de recuperação, alinhamento, deduplicação e montagem do relatório compõem o mesmo container Docker que roda em noplag.com. A camada em nuvem adiciona o corpus e os adaptadores de busca web, não o motor.
O que isso significa para você
Leia o algoritmo antes de confiar no score. Rode o engine em sua própria infraestrutura caso seus documentos não possam sair dela. Faça fork se nosso roadmap divergir do seu. Audite como os intervalos dos chunks viram número de similaridade — e discorde publicamente caso ache um bug.
Cascade de busca em quatro camadas. Diagrama, não metáfora.
Cada camada restringe candidatos trocando custo por precisão. Tudo está aberto no repo. O cloud só adiciona o corpus + adaptadores de busca web.
Winnowing fingerprints
Sobreposição de 64 bits com índice GIN em colunas bigint[] no Postgres. Filtra bilhões de chunks para top-K em O(log n) por query.
MinHash LSH — roteiro v1.1
Jaccard aproximado para identificar cópias parafraseadas ou levemente modificadas, cobrindo o que o L1 não detecta após reescrita real. Já projetado, ainda não implementado — não está no repositório público.
Embeddings de sentenças — roteiro v1.2
Vetores SBERT multilíngues com pgvector ANN, para identificar reescritas semanticamente equivalentes e cópias entre idiomas. Já projetado, ainda não implementado — não está no repositório público.
Verificação Web em tempo real
Os adaptadores Google + Brave verificam os principais candidatos em tempo real na web. Disponível apenas na camada em nuvem para planos pagos; esses adaptadores não fazem parte do pacote open source.
noplag.toml.O que realmente está no repo.
Não é wrapper de SDK. Não é cliente limitado. O algoritmo de detecção completo — mesmo layout que gera o container de produção.
- src/noplag_engine/o pacote
- chunking/chunkers por sentença + sliding window
- fingerprinting/hashes winnowing 64 bits
- retrieval/L1 disponível hoje; L2 / L3 / LW ainda não incluídos neste pacote
- l1_winnowing.pytop-K com GIN
- fingerprint_df.pyestatísticas de frequência de documentos
- stop_list.pyfiltro de fingerprints não discriminativos
- alignment/mesclagem de intervalos seed-and-extend
- workflows/pipeline de verificação orquestrada por tempo
- api/Superfície HTTP FastAPI
- reports/montagem de destaques + exportação em PDF
- tests/412 testes · pytest + property + integração
- migrations/migrações de esquema Alembic
- Dockerfilemesma imagem da produção
- docker-compose.ymlguia rápido para auto-hospedagem
- LICENSEApache 2.0
- README.mdarquitetura + guia rápido
- 12,4kestrelas no GitHub
- 38contribuidores
- 2.847commits
- 412testes em CI
- 1:1paridade cloud / repo
Três coisas que um verificador fechado nunca deixa você checar.
Checkers fechados fornecem só um número. Threshold para 'plágio vs paráfrase', pesos entre sobreposição de n-gram e similaridade semântica, como matches curtos são ignorados — tudo fechado. Você não pode reproduzir, seu auditor não pode revisar, e bugs não têm commit de referência.
O que você pode verificar: todo threshold, peso, regra de dedupe estão em src/noplag_engine/. Abra um release taggeado no GitHub, ache o commit exato usado na sua checagem (X-Engine-Commit header), leia a matemática linha a linha.
Para onde seu documento vai após submeter? Foi armazenado? Caiu numa DB de envios que outro cliente pode acessar? Foi enviado para vendor externo para detecção de IA? Checkers fechados respondem só no marketing. Não mostram o caminho no código.
O que você pode verificar: o pacote workflows/ mostra todo local de leitura, hash, persistência e deleção. A pasta migrations/ mostra toda coluna afetada. O pacote api/ mostra o que sai do engine — e onde você troca o limite em um fork.
Uma 'caixa preta 63%' não tem origem. Foi 63% sobre 12 fragmentos curtos? Um parágrafo longo? Erro de recuperação? Seu perfil de escrita como ESL é ponderado diferente? O score chega, mas a matemática não.
O que você pode verificar: alignment/ apresenta a fusão de intervalos seed-and-extend. reports/ mostra como os matches de cada chunk formam a porcentagem final. Você pode rodar o mesmo documento, mesmo commit, inspecionar cada intervalo e questionar a conta publicamente.
Dois modos de rodar o mesmo engine.
A maioria dos usuários escolhe a camada em nuvem em noplag.com — Postgres gerenciado + Temporal + Coolify, corpus já indexado e adaptadores de busca web com chaves de API válidas. O caminho de auto-hospedagem é para organizações cujos documentos não podem sair da própria infraestrutura: clone o repositório, utilize seu próprio Postgres e Redis, direcione o engine para o seu corpus (ou importe OpenAlex + Common Crawl do nosso manifesto) e configure suas próprias chaves Google/Brave. Mesmo engine, mesmos algoritmos, mesmo formato de relatório — apenas o limite operacional muda.
Leia o guia self-hostAs perguntas sobre open source que realmente recebemos.
- O engine é mesmo o mesmo código do noplag.com?
- Sim. O Dockerfile no repo gera a imagem que implantamos. Toda checagem em noplag.com roda aquele commit, e o hash sai no header X-Engine-Commit para possibilitar fixar a checagem a um release taggeado. A camada cloud adiciona o corpus e chaves de API de busca — não um algoritmo diferente.
- Por que Apache 2.0 e não AGPL ou BSL?
- Apache 2.0 permite self-hosting sem peso jurídico. AGPL nos forçaria a usar licença como barreira, o oposto do princípio — queremos que auditores e forkers realmente usem. O valor está no corpus e operação, não no algoritmo.
- Posso rodar self-host sem o cloud?
- Sim. Clone o repositório, execute `docker compose up`, utilize seu próprio Postgres + Redis e importe o manifesto do corpus público (OpenAlex + Common Crawl + Wikipedia). Os adaptadores Layer W são plugáveis — insira suas próprias chaves de API Google/Brave ou ignore o Layer W se precisar apenas de correspondência com corpus indexado.
- Noplag Database (documentos submetidos) é aberto?
- Não. O Noplag Database contém envios dos usuários e fica no cloud — colocar documentos de terceiros sob Apache-2.0 seria errado. Documentos entram ali por padrão; é possível desativar. O código de consulta do engine é aberto; os dados não.
- E o detector de IA — também será aberto?
- Sim. Detecção de IA chegará em breve — está no roadmap da v1.2, não estará disponível no lançamento — e será distribuída como todo o restante: a integração do modelo de perplexidade, a calibração, o ajuste de viés para ESL e as faixas de veredito ficarão em src/noplag_engine/ai_detection/. Os próprios pesos dos modelos são open source (Qwen 2.5 1.5B 4-bit na camada CPU, Mistral 7B opcional na camada GPU). Nenhum detector proprietário de terceiros na cadeia de chamadas.
- Como reportar bug no algoritmo de matching?
- Abra issue público no GitHub com documento reprodutor mínimo (ou descreva o falso positivo). Fazemos triagem aberta. Questões de segurança: security@noplag.com.
- Cloud sempre roda o mesmo algoritmo do repo?
- Sim, por política. Se algum dia precisarmos disponibilizar um comportamento exclusivo na nuvem para um experimento, será controlado por feature flag com padrão open source; o algoritmo principal permanece no main. Se isso mudar, você verá no header da resposta e nas notas públicas de versão.
- Como funciona a contribuição?
- Issues e pequenos PRs são bem-vindos. Mudanças grandes — novas camadas de busca, novo corpus, novos idiomas — comece por RFC para discussão aberta de arquitetura. Não aceitamos PRs que incluam dependências closed source, telemetria, ou lock-in.
- Existe self-host gerenciado? (Apache 2.0 gerenciado)
- Ainda não. O cloud Enterprise fornece infraestrutura dedicada e BYO-corpus, que cobre a maioria dos usos. Self-host gerenciado está no roadmap v1.2.
- Isso muda o preço?
- Não. Cloud tem preço com base no corpus + operação (Hetzner + Coolify + Stripe + Lago + APIs de busca), não licença do engine. Self-host é grátis. Ambos vão seguir assim.
Leia o algoritmo. Depois rode você mesmo.
github.com/NoplagLabs/noplag-engine está sob Apache 2.0. A nuvem em noplag.com executa o mesmo commit. Ambos os caminhos usam o mesmo engine — escolha o limite operacional adequado aos seus dados.