Online İntihal Araçlarının Veritabanı Yapısı

Online intihal tespit araçlarının gerçek gücü, yalnızca kullandıkları benzerlik algoritmalarında değil; veriyi nasıl depoladıkları, ilişkilendirdikleri ve ölçeklendirdiklerinde yatar. Arka planda; milyarlarca cümle/şingle, yüz milyonlarca görsel parmak izi, milyonlarca kaynak URL, çokdilli metinler, sürüm geçmişleri, telif ve KVKK/GDPR gibi düzenleyici kısıtlar ile çok katmanlı bir veritabanı mimarisi etkileşim hâlindedir. Bu yazı, online intihal araçlarının veritabanı yapısını uçtan uca ele alır: kavramsal veri modelinden fiziksel saklamaya, LSH/minhash ve vektör indekslerinden boilerplate sözlüklerine, çokdillilikten çok-kiracılı (multi-tenant) SaaS mimarisine, hukuki/etik zorunluluklardan maliyet izleme ve felaket kurtarmaya kadar ayrıntılı bir yol haritası sunar.

Amaç, “benzerlik yüzdesi” veren bir kara kutu tasarlamak değil; kanıta dayalı, açıklanabilir, güvenli ve ölçeklenebilirbir veritabanı omurgası kurmaktır.

1) Mantıksal Model: Varlık–İlişki Çekirdeği

Bir intihal tespit platformunda tipik ana varlıklar:

Document: Belgenin mantıksal kimliği (title, source_type, language, license, canonical_url).
DocumentVersion: Her yükleme/düzeltme bir sürümdür (hash, size, ingest_time, parser_type).
Passage/Segment: Paragraf, cümle ya da slayt maddesi gibi karşılaştırma birimi (offset, length, normalized_text).
Fingerprint: Shingle/minhash/winnowing imzaları (k, window, signature[]) ve Vector: semantik embedding (model_id, dim, vector_blob).
MediaAsset: Görsel/şema/tablo (phash/dhash, ocr_text, bbox’lar).
Source: URL, DOI, arşiv ID; erişim tarihi ve durum kodları.
Evidence: Eşleşme kanıtı (passage_id_source, passage_id_target, score’lar, snippet).
Policy/Consent: KVKK/GDPR rıza, saklama süresi, maskeleme kuralları.
Tenant: Çok-kiracılı SaaS’ta müşteri izolasyonu, kota ve anahtarlar.

Bu varlıklar referans bütünlüğü ve denormalizasyon dengesi gözetilerek ayrıştırılır: okuma-yoğun senaryolar için kritik alanlar (fingerprint, vector) ayrı indeks tabanlarında tutulur.

2) İçeri Aktarım (Ingestion) Boru Hattı ve Durum İzleme

Veri, LMS’ler, arşivler, pazaryerleri, web tarama veya doğrudan yüklemeden gelebilir. Tipik adımlar:

Kabul & Virüs taraması
Format saptama (PDF/Docx/PPTX/HTML)
Metin çıkarma & OCR (görsel üstü metinler)
Normalizasyon (Unicode, boşluk, tırnak, tire)
Segmentasyon (cümle/paragraf/slayt)
Dil tespiti & transliteration
Shingle/Winnowing & MinHash
Embedding çıkarımı (Sentence/Bi-Encoder)
Indeksleme (LSH kovaları, vektör grafı, ters indeks)
Kalite metrikleri (boilerplate oranı, token coverage, OCR güven puanı)

Her adım IngestJob tablosunda (job_id, stage, status, error, duration) izlenir. Bu, görülebilirlik ve tekrar-çalıştırma(replay) için zorunludur.

3) Normalizasyon ve Dil Tabakası

İntihal tespitinin adaleti, normalizasyona dayanır:

Unicode normalizasyonu (NFKC), görünmez karakter temizliği.
Case-folding, diakritik işaretlerin eşitlemesi (örn. “İ/i” Türkçe özel durumu).
Stop-phrase/Boilerplate sözlükleri: “Giriş”, “Sonuç”, “Bu makaledeki görüşler…” gibi şablonlar.
Dil & betik tespiti (TR-Latn, RU-Cyrl); transliteration (Kiril→Latin) gerektiğinde ayrı alan olarak saklanır.
Tokenizasyon profilleri dil bazlıdır; her profil sürüm numarasıyla ModelRegistry’de tutulur (model_id, lang, version, checksum).

4) Shingle/MinHash/LSH Depolama Desenleri

Yüzeysel benzerlik için üç katman:

Shingle Store: shingle_id (hash64), k, lang, df, last_seen – df (document frequency) sık görülen kalıpları boilerplate olarak işaretlemeye yarar.
MinHash Signatures: doc_version_id, band_no, bucket_key, signature[] – LSH bant/tablo stratejisiyle yakın komşu adaylarını getirir.
Overlap Index: doc_version_id, shingle_id, positions[] – kanıt üretiminde pasaj sınırlarını net çıkarır.

Bu katmanlar sıkıştırma (VarInt, RoaringBitmap) ve kolonlu depolama (Parquet/ORC) ile soğuk katmanda tutulurken, sıcak katmanda key-value (RocksDB/LevelDB veya bulut KV) kullanılabilir.

5) Vektör Veritabanı: Semantik Komşuluk

Paraphrasing/çeviri-intihali için embedding’ler:

VectorStore: vector_id, doc_version_id, passage_id, model_id, dim, vector_blob
ANN Index: HNSW/IVF-PQ/ScaNN — büyük hacimde düşük gecikme için bölümlenmiş (partitioned) dizinler.
Multi-Model Destek: Farklı diller/alanlar için çoklu model; ensembl skor için meta-tablo: vector_match (v1, v2, cosine, model_id, ts).

Vektörler quantization (8-bit/FP16) ve product quantization ile depolama maliyeti azaltılarak saklanır. Annoy/HNSWgraf parametreleri (M, efConstruction, efSearch) tuning tablosunda tutulur.

6) Ters İndeks (Inverted Index) ve Karma Aramalar

Doğrudan alıntı ve anahtar deyimler için:

TermIndex: term, doc_freq, posting_list(doc_version_id, tf, positions[])
PhraseIndex: kısa kalıp ve n-gram eşleşmeleri.
Hybrid Query Planner: “terim + vektör + LSH” kombinasyonlarını maliyet temelli planlar; önce daraltır (LSH → 10k aday), sonra zenginleştirir (vektör → 1k), en sonda kanıt üretimi için overlap.

7) Görsel/Tablo Eşleşmesi: pHash, OCR, Şema İndeksi

ImageHash: asset_id, phash64, dhash64, ahash64, width, height, mime
OCRSegment: asset_id, text, bbox, conf (slayt ve ekran görüntülerinde kritik)
TableSchema: başlıklar, birimler, kolon tipleri – şema benzerliği için Jaccard/EMD (Earth Mover’s Distance) gibi ölçüler saklanır.

Böylece “görsel üstü metin” ve “tablo kopyası” vakaları, metinle aynı kanıt panelinde birleştirilir.

8) Çokdillilik ve Çapraz-Dilli Eşleşme

LangMap: doc_version_id → (primary_lang, detected_langs[], confidence[])
CrossLingualMap: passage_id → (pivot_translation, back_translation, score)
TermLexicon: alan-özgü terim sözlükleri (TR-EN-DE), karşılıkları ve ağırlık düzeltmeleri.

Çapraz dilde eşleşme bulguları kanıt olarak yan yana pasaj görselleştirmesiyle raporlanır.

9) Boilerplate, Şablon ve Beyaz Liste Yönetimi

BoilerplateRules: regex/kural setleri, hit_count ve cohort bilgisi (hangi kiracıda sık?).
Whitelist: Kurumsal şablonlar, yasal metinler, lisans koşulları.
Skorlama motoru, bu alanları skor dışı bırakır veya ağırlığını düşürür; ancak raporda görünür tutar (bağlam kaybını önlemek için).

10) Kanıt Üretimi ve Açıklanabilirlik Veri Modeli

MatchSet: query_dv_id, candidate_dv_id, score_surface, score_semantic, score_structure, score_media, final_score
EvidenceChunk: matchset_id, src_offset, tgt_offset, length, shingle_overlap[], top_k_neighbors[], highlighted_text_src/tgt
Justification: eşik/ansambl kuralları (hangi sinyal kararı tetikledi?) – denetim (audit) için saklanır.

Bu şema, yanlış pozitif itirazlarında şeffaflığı sağlar.

11) Güvenlik, Gizlilik ve KVKK/GDPR

PII Masking: Kişisel veri tanıyıcıları (ad, e-posta, tcno) için data masking kuralları; masking view’ları veritabanı düzeyinde (örn. row-level security + column masking).
RetentionPolicy: tenant_id, data_class, retention_days, auto_purge – otomatik silme işlerine bağlı.
Consent & Purpose: Hangi amaçla işlendi? Purpose-binding alanı (örn. ödev kontrolü vs. kurumsal denetim).
Encryption: At-rest şifreleme (KMS) ve transit TLS; key rotation ve HSM kaydı.
AccessLog: Kim, neyi, ne zaman gördü? Ayrı WORM (Write Once Read Many) depoya yazılır.

12) Çok-Kiracılı (Multi-Tenant) Mimaride Veri İzolasyonu

SaaS dağıtımında iki model:

Fiziksel izolasyon: Her kiracı için ayrı veritabanı/kümeler – en yüksek izolasyon, daha yüksek maliyet.
Mantıksal izolasyon: tenant_id ile satır düzeyi güvenlik (RLS); paylaşılan indekslerde namespace’ler.

Hibrit yaklaşım sık görülür: vektör ve LSH indeksleri ortak; kanıt ve orijinal metin kiracıya özel depoda.

13) Ölçeklenebilirlik: Bölümleme, Sharding ve Sıcak-Soğuk Katmanlar

Bölümleme (Partitioning): Tarih (ingest_ts), dil, kiracı, belge türü gibi doğal anahtarlarla.
Sharding: LSH kovaları ve vektör grafı düğümleri, shard-key ile dağıtılır (örn. bucket_key % N).
Tiered Storage: Sık erişilen fingerprint/vector sıcak SSD katmanında; eski sürümler soğuk obje depoda (S3/GCS) Parquet olarak.
Cache: Sorgu → aday listesi → kanıt üretimi zincirinde ResultCache (LRU) ve BloomFilter ile “yok” sonuçları da önbelleğe alınır.

14) Sorgu Planlayıcı ve Maliyet Modeli

Hibrid aramada hangi indeks önce? sorusu için:

Heuristics: Kısa soru → vektör öncelik; uzun pasaj → LSH ön filtre.
Stats: shingle df istatistikleri, vektör yoğunluğu, dil uyumu.
Cost Table: Her operatör için ortalama gecikme ve kanditat daraltma oranı saklanır; planlayıcı en ucuz yolu seçer.

15) Performans Gözlemi ve Telemetri

QueryMetrics: p50/p95 gecikme, aday sayısı, kanıt üretim süresi.
IndexHealth: LSH kovalarının doluluk oranı, HNSW bağlantı dağılımları.
DataDrift: Yeni dil/alan dağılımları; boilerplate artışları.
CostTracker: Depolama GB-ay, sorgu başına CPU-ms, model GPU-dakika.

Bu metrikler otomatik ölçeklendirme ve MLOps döngülerini besler.

16) Yedeklilik, Yedekleme ve Felaket Kurtarma

İşlem günlüğü (WAL) sürekli yedeklenir, point-in-time recovery desteklenir.
Snapshot: Günlük/haftalık veritabanı anlık görüntüleri, cross-region kopyalar.
Runbook: DR testi için oyun kitapları; RPO/RTO hedefleri ve chaos drills.

17) Maliyet Optimizasyonu: Sıkıştırma, Yaşlandırma, Önbellek

Sıkıştırma: Parquet+ZSTD, vektör PQ; kanıt metinleri için shared-substring sıkıştırma (dedup).
Yaşlandırma (Lifecycle): Eski sürümler glacier tip soğuk depoya; erişimde rehydrate stratejisi.
Önbellek & Hot-set pinning: En çok kullanılan 1–5% vektörün RAM’e pinlenmesi.

18) Deneysel Ortam ve Yapay Veri (Synthetic Data)

Gerçek metinleri taşımadan test için:

Sentetik belge üreteçleri (şablon + varyasyon + hata modelleri).
Adversarial setler: Unicode hileleri, görünmez karakterler, paraphrase yoğunlukları.
Benchmark: Precision/Recall/F1 yanında kanıt üretim süresi, inceleme başına tıklama gibi operasyonel metrikler.

19) Vaka Çalışması A: Üniversite LMS Entegrasyonu

Bağlam: 60k ödev/yıl, TR-EN karışık.
Mimari: LSH (20 bant), HNSW (M=32, ef=200), boilerplate sözlüğü 4k kalıp.
Sonuç: p95 sorgu 1.6 sn; yanlış pozitif %1.8; öğrenci itirazlarında EvidenceChunk görselleriyle ortalama çözüm 14 dk.

20) Vaka Çalışması B: Kurumsal İçerik Denetimi

Bağlam: Çok kiracılı SaaS; 300 şirket, 120M belge parçası.
Mimari: Mantıksal izolasyon (RLS) + ortak vektör indeks; tenant-aware cache.
Sonuç: Maliyet/ay %23 düştü (tiered storage + PQ); DataDrift alarmı ile boilerplate artışı tespit edilip kurallar güncellendi.

21) Erişim Desenleri ve API Tasarımı

/ingest: çok parçalı yükleme, idempotent anahtar, geriye job_id.
/search: metin, dosya, URL; param: mode={surface, semantic, hybrid}, top_k, lang_hint.
/evidence: match_id ile kanıt paketini getir.
/policy: retention/consent okuma-yazma.
/tenant: kota, anahtar rotasyonu, denetim kayıtları.

API yanıtlarında explain alanı (hangi sinyaller, hangi eşikler) mutlaka bulunur.

22) Güvenliğin İncelikleri: Yan Kanal ve Model Sızıntısı

Sorgu oran sınırlama (rate limit), scraping ve rekabet casusluğunu engeller.
Model sızıntısı: Embedding vektörlerinin ham verilmesini engelle; yalnız distance döndür.
Yan kanal: Zamanlama/hatadan kaynaklı bilgi sızması için sabit zamanlı hata yanıtları.

23) İnsan-Halka: Etiketleme, İtiraz ve Düzeltme Akışları

LabelTask: İnceleyicinin verdiği kararı veri tabanına işler; ground-truth oluşur.
Appeal: Kullanıcının itirazı, kanıt/grup notlarıyla birlikte saklanır.
FeedbackLoop: Model ve eşik kalibrasyonuna giden zincir (hangi kararlar düzeltilmiş?).

24) Gelecek Yönelimleri: Multimodal ve Watermark

Multimodal vektör: Metin + görsel + layout birleşik embedding.
Watermark/su-izi: YZ çıktılarındaki istatistiksel işaretler için WatermarkIndex; politika bazlı işaretleme.

Sonuç

Online intihal araçlarının veritabanı yapısı, basit bir belge-indeksi olmaktan çok uzaktır. Yüzeysel (shingle/LSH), semantik (vektör/ANN) ve yapısal (akış/şema) katmanları, görsel-tablo eşleşmesiyle birlikte, kanıt üretimi ve açıklanabilirlik odaklı bir ansambl mimaride birleşir. Çokdilli normalizasyon, boilerplate/beyaz liste yönetimi ve çapraz-dilli haritalama; adil skorlamanın ön şartıdır. SaaS bağlamında kiracı izolasyonu, KVKK/GDPR uyumu, PII maskeleme, erişim denetimi ve denetim günlükleri ise güven ve meşruiyetin temelidir.

Ölçeklenebilirlik için bölümleme-sharding, sıcak-soğuk katmanlama, vektör kuantizasyonu ve hibrit sorgu planlama gerekir. Maliyet, yalnız donanım değil; kanıt üretim gecikmesi, inceleme iş yükü ve yanlış pozitif/negatifle de ölçülmelidir. En önemlisi, veritabanı mimarisi yalnız bir depolama değil; etik, hukuk, pedagojik amaç ve açıklanabilirliği birlikte taşıyan kurumsal bir sinir sistemidir. Bu omurgayı doğru kuranlar, “yüzde kaç benzer?” sorusunu kanıtın nasıl, nerede ve neden üretildiğiyle birlikte yanıtlayabilir—ve böylece intihal tespitini cezalandırıcı bir filtreden, öğretici ve güvenilir bir karar destek sistemine dönüştürür.

Öğrencilerin sıkça karşılaştığı zorluklardan biri olan intihal sorununa çözüm sunan platformumuz, öğrencilere güvenilir ve etkili bir destek sunuyor. İntihal raporu alma, kontrol etme ve oranını azaltma gibi hizmetlerimizle, öğrencilerin akademik başarılarını artırmak ve etik sorumluluklarını yerine getirmelerine yardımcı oluyoruz. Özgün ödevler üretme konusunda sunduğumuz çözümlerle, öğrencilerin potansiyellerini en üst seviyede kullanmalarını sağlıyoruz. Siz de akademik başarınızı güvence altına almak ve etik çerçevede hareket etmek için hemen bizimle iletişime geçin ve avantajlarımızdan yararlanın!

Akademik hayatınızda intihal sorununu bir kenara bırakın ve başarıya odaklanın. İntihal raporu yaptırma adında sunduğumuz hizmetlerimizle, ödevlerinizde güvenilirliği ve özgünlüğü garanti altına alıyoruz. Size özgün çözümler sunarak akademik kariyerinizde önemli adımlar atmanızı sağlıyoruz. Profesyonel ekibimiz ve teknolojik altyapımızla intihal sorununu geride bırakın ve başarıya giden yolculuğunuzda bize katılın!

Öğrencilik hayatınızı kolaylaştıran çözümlerle tanışın! İntihal raporu alma ve kontrol etme gibi hizmetlerimizle, ödevlerinizdeki intihal riskini minimuma indiriyoruz. Aynı zamanda özgün ödev üretme konusunda size destek oluyor ve akademik başarınızı artırmak için gereken adımları atmanıza yardımcı oluyoruz. Hemen bizimle iletişime geçin ve akademik hayatınızı güvence altına almak için adım atın!

Turnitin Oranı

Biyografinin Tamamını Gör