Verificatore di plagio open source.
L'unico servizio di rilevamento del plagio con un livello cloud in produzione e un motore completamente open source. Lo stesso codice che gira su noplag.com è disponibile su GitHub all'indirizzo github.com/NoplagLabs/noplag-engine — puoi esaminarlo, crearne una copia, eseguirlo in self-hosting.
Lo stesso commit che verifica su noplag.com è il commit su GitHub.
Nessun compromesso "simil open source". Nessun repository solo SDK con il motore a codice chiuso. Il chunker, il fingerprinter, la retrieval cascade e l’assemblatore dei report sono tutti nello stesso repository Apache 2.0 che genera il nostro container di produzione.
Motore per rilevamento plagio alla base di noplag.com — chunking, fingerprint winnowing, retrieval cascade, allineamento, assemblaggio report. Apache 2.0.
- LINGUAGGIO
- Python · Rust
- LICENZA
- Apache 2.0
- CONTRIBUTORI
- 38
- COMMITS
- 2.847
- ULTIMO RILASCIO
- v0.4.2 · 3 giorni fa
- CI
- passing · 412 test
Il codice chiuso era un bug, non una caratteristica.
Ogni rilevatore di plagio prima di noi chiede di fidarsi di una scatola nera. Fidarsi del punteggio. Fidarsi della metodologia che non può vedere. Fidarsi che l’algoritmo non favorisca il suo stile di scrittura. Abbiamo fatto una scelta opposta.
Ciò che non si vede non si può fidare
Un punteggio di similarità è solo un numero, senza avere una provenienza. Era una corrispondenza tra frasi, una parafrasi, o un’ipotesi di IA? Il suo stile di scrittura ESL era calibrato? I rilevatori chiusi non lo dicono — il loro vantaggio È che non si può chiedere. Noi non accettiamo questo come costo per il rilevamento plagio.
Prodotto open source, non solo marketing open source
Il repository Apache 2.0 su github.com/NoplagLabs/noplag-engine non è un semplice SDK client senza l’algoritmo di confronto. Il chunker, il fingerprinter winnowing, la retrieval cascade, l’allineamento, la deduplicazione e la generazione dei report costruiscono tutti lo stesso container Docker che gira su noplag.com. Il livello cloud aggiunge il corpus e gli adattatori per la ricerca web, non il motore.
Cosa significa per Lei
Legga l’algoritmo prima di fidarsi del punteggio. Auto-ospiti il motore sulla propria infrastruttura se i documenti non possono uscire. Biforchi se il nostro percorso diverge dal Suo. Verifichi come gli intervalli a livello di chunk diventano un numero di similarità — e si opponga pubblicamente se trova un bug.
Cascade a quattro livelli. Schema, non una metafora.
Ogni livello restringe il set dei candidati con un compromesso costo-precisione. Tutti i livelli sono nel repository open. Il cloud aggiunge corpus + adattatori web search.
Fingerprinting winnowing
Sovrapposizione 64-bit GIN-indexed su colonne bigint[] in Postgres. Filtra miliardi di chunk candidati ai top-K in O(log n) per query.
MinHash LSH — roadmap v1.1
Jaccard approssimato su testi parafrasati o leggermente modificati, per rilevare ciò che L1 non individua dopo una reale riformulazione. Progettato, non ancora implementato — non è presente nel repository pubblico.
Sentence embeddings — roadmap v1.2
Vettori SBERT multilingue con pgvector ANN, per rilevare riscritture semanticamente equivalenti e copie tra lingue diverse. Progettato, non ancora implementato — non è presente nel repository pubblico.
Controllo web live
Gli adapter Google + Brave verificano in tempo reale i primi N candidati sul web live. Disponibili solo nel livello cloud per i piani a pagamento; gli adapter non sono inclusi nel pacchetto open source.
noplag.toml.Che cosa è veramente nel repo.
Non un wrapper SDK. Non un client limitato. L’algoritmo completo — stesso layout che genera il container di produzione.
- src/noplag_engine/il pacchetto
- chunking/chunker per frasi + sliding-window
- fingerprinting/hash winnowing 64 bit
- retrieval/Solo L1 attualmente; L2 / L3 / LW non ancora inclusi in questo pacchetto
- l1_winnowing.pytop-K GIN-overlap
- fingerprint_df.pystatistiche di frequenza dei documenti
- stop_list.pyfiltro delle impronte non discriminanti
- alignment/fusione di intervalli seed-and-extend
- workflows/Pipeline di verifica orchestrata temporalmente
- api/Interfaccia HTTP FastAPI
- reports/evidenziazione e esportazione PDF
- tests/412 test · pytest + property + integrazione
- migrations/Migrazioni dello schema con Alembic
- Dockerfilestessa immagine della produzione
- docker-compose.ymlguida rapida per il self-host
- LICENSEApache 2.0
- README.mdarchitettura e guida rapida
- 12.4kStelle GitHub
- 38contributori
- 2.847commit
- 412test in CI
- 1:1parità cloud/repo
Tre cose che un rilevatore chiuso non può lasciarLe verificare.
I rivelatori chiusi danno solo un numero. La soglia tra “plagio e parafrasi”, la ponderazione tra n-gram overlap e similarità semantica, la gestione dei match brevi — tutti a codice chiuso. Non può riprodurlo, né un auditor può revisionarlo, e un bug non ha mai un commit pubblico di riferimento.
Verificabile: ogni soglia, peso, regola dedupe è in src/noplag_engine/. Apra una release su GitHub, trova il commit esatto (restituito su X-Engine-Commit header) e legga i calcoli riga per riga.
Dove va il Suo documento dopo l'invio? È stato salvato? Finisce in un DB usato da altri clienti? Inviato a un rilevatore IA di terzi? I sistemi chiusi spiegano tutto nel marketing, non possono mostrare il percorso nel codice.
Verificabile: il pacchetto workflows/ mostra dove una submission è letta, hashata, persiste, purgata. In migrations/ trova ogni colonna toccata. In api/ cosa esce dal motore in rete — e dove può sostituire confine in un fork.
Un opaco “63% simile” è un verdetto senza provenienza. Era il 63% su 12 frammenti? Un paragrafo lungo? Uno sbaglio al recupero? Il peso per stile ESL esiste? Il punteggio arriva, il calcolo no.
Verificabile: alignment/ espone la fusione seed-and-extend. reports/ mostra come i match chunk generano la percentuale. Si può ripetere lo stesso documento sullo stesso commit, ispezionare intervallo per intervallo e contestare i calcoli su GitHub.
Due modi di usare lo stesso motore.
La maggior parte degli utenti sceglie il livello cloud su noplag.com: Postgres gestito + Temporal + Coolify, il corpus è già indicizzato e gli adapter per la ricerca web hanno chiavi API valide incluse. L'opzione self-host è pensata per le organizzazioni che non possono trasferire i propri documenti fuori dalla propria infrastruttura: clona il repository, configura Postgres e Redis, collega il motore al tuo corpus (o importa OpenAlex + Common Crawl dal nostro manifest) e usa le tue chiavi Google/Brave. Stesso motore, stessi algoritmi, stesso formato di report: cambia solo il perimetro operativo.
Legga la guida self-hostLe vere domande che riceviamo sull’open source.
- Il motore è davvero lo stesso codice di noplag.com?
- Sì. Il Dockerfile nel repository crea l’immagine che usiamo in produzione. Ogni check su noplag.com gira su quel commit, e il commit hash torna nell’header X-Engine-Commit per permetterle il pin su release. Il cloud aggiunge corpus e chiavi API web-search — non cambia algoritmo.
- Perché Apache 2.0 invece di AGPL o BSL?
- Apache 2.0 consente alle organizzazioni di auto-ospitare senza costi legali. AGPL ci costringerebbe a difendere la licenza come barriera, che non è la nostra posizione: vogliamo che auditor e forkatori possano davvero usarlo. La parte coperta è il corpus e la gestione, non l’algoritmo.
- Posso auto-ospitare senza usare il cloud?
- Sì. Clona il repository, esegui `docker compose up`, configura Postgres + Redis e importa il manifest dei corpora pubblici (OpenAlex + Common Crawl + Wikipedia). Gli adapter Layer W sono modulari: puoi inserire le tue chiavi API Google/Brave oppure escludere Layer W se ti serve solo il confronto con i corpora indicizzati.
- Il Noplag Database (documenti inviati dagli utenti) è open?
- No. Noplag Database contiene invii utente e resta nel cloud — rilasciare in Apache 2.0 i documenti altrui sarebbe scorretto. I documenti inviati ci entrano di default; può disattivare. Il codice motore che lo interroga è open; i dati no.
- E il rilevamento IA — sarà open?
- Sì. Il rilevamento AI arriverà presto — è previsto nella roadmap v1.2, non sarà disponibile al lancio — e verrà distribuito in modalità open come tutto il resto: la struttura del modello di perplexity, la calibrazione, la regolazione del bias ESL e le fasce di verdetto saranno tutte in src/noplag_engine/ai_detection/. Anche i pesi dei modelli sono open source (Qwen 2.5 1.5B 4-bit sul livello CPU, Mistral 7B opzionale sul livello GPU). Nessun rilevatore di terze parti chiuso nella call graph.
- Come segnalo un bug nell’algoritmo di matching?
- Aprire una issue pubblica GitHub con documento minimale (o descrizione intervallo falso positivo). Il triage è pubblico. Problemi di sicurezza a security@noplag.com.
- Il cloud userà sempre lo stesso algoritmo del repo?
- Sì, per politica. Se mai dovessimo introdurre funzionalità disponibili solo in cloud per un esperimento, sarebbero protette da un feature flag con impostazione predefinita open source; l’algoritmo di riferimento rimane in main. Se dovessimo violare questa regola, lo vedresti nell’header della risposta e nelle note di rilascio pubbliche.
- Che modello di contributo adottate?
- Ok issue e piccoli PR. Per cambi grandi — nuovi layer, corpus, lingue — parta da una issue RFC così la discussione architetturale avviene in pubblico. Non accettiamo PR con dipendenze closed-source, telemetria, vendor lock-in.
- Esiste un self-host gestito? (Apache 2.0 managed)
- Non ancora. Il piano Enterprise sul cloud offre infrastruttura dedicata e BYO-corpus, che copre la maggior parte delle richieste. Un self-host gestito è sulla roadmap v1.2.
- Impatti sui costi?
- Nessuno. Il cloud ha costo corpus + gestione (Hetzner + Coolify + Stripe + Lago + web-search), non per licenza engine. Self-host è gratuito. Rimarrà così.
Legga l’algoritmo. Poi lo esegua personalmente.
github.com/NoplagLabs/noplag-engine è sotto licenza Apache 2.0. Il cloud su noplag.com esegue lo stesso commit. In entrambi i casi hai lo stesso motore — scegli la soluzione operativa che si adatta ai tuoi dati.