AIGC Detection Principles and Text Rewriting Engineering: A Practical Guide

1. Clarifying the Problem: What Does an “AI Score” Actually Mean

Before discussing how to lower an “AI rate,” accept one premise: AIGC detection produces a probabilistic judgment, not a factual verdict.

Mainstream detection methods fall into three broad categories:

• Statistical feature methods: built around perplexity and burstiness. When a language model generates text, the conditional probability at each position tends to be relatively smooth, and sentence length and structure vary little. Human writing tends to be uneven, alternating between short and long sentences with occasional unconventional phrasing.
• Discriminative model methods: a classifier learns distribution differences between real and machine-generated text and outputs a “looks more machine-generated” confidence score.
• Provenance and watermarking methods: they rely on detectable markers embedded on the model side and stop working once you move outside that specific model.

Understanding these three categories explains a common puzzle: why a paragraph typed out character by character can still be flagged as having a high AI rate.

The main sources of misjudgment include:

• Templated characteristics inherent to academic writing: research background, methods descriptions, and conclusion sections are highly formulaic.
• Non-native authors’ conservative and formal word choices.
• Mixed Chinese-English text and terminology-dense paragraphs.
• Formula derivations and definition paragraphs.
• Text that is too short: within a few hundred words, statistical features are unstable and scores fluctuate dramatically.

In addition, the detection models themselves are iterating, so the same text produces inconsistent results across different points in time and different model versions.

Therefore, “pushing some score below some number” has never been an engineering goal. The real goal is this: text that expresses ideas clearly, uses terminology accurately, is logically coherent, and shows improvement in a way that is measurable and reproducible.

2. Comparing Technical Approaches to Text Rewriting

Approach	Principle	Main risks	Suitable scenarios
Rule/synonym replacement	Vocabulary mapping, sentence templates	Semantic drift, incorrect collocations, broken terminology	Barely applicable; light polishing only
Neural sequence rewriting	Encoder-decoder generation directly	Factual hallucination, loss of control on long sentences, format loss	When strong post-verification is available
Retrieval-augmented rewriting	References real writing corpora, controls distribution	Corpus quality and domain match determine the ceiling	Academic text; balanced quality and stability
Controllable/constrained rewriting	Generation + multi-constraint filtering + best-candidate selection	High engineering complexity, high compute cost	Recommended for production environments

The key conclusion: a rewriting system cannot optimize only for “does the output look human-written.” It must simultaneously optimize “did it change anything it should not have.” Semantic preservation, terminology consistency, and citation completeness are hard constraints; style distribution is a soft objective. If the soft objective is weighted too heavily, semantic distortion is inevitable.

3. An Implementable Engineering Pipeline

A complete processing pipeline usually has six stages: document parsing, protected-span identification, terminology and entity extraction, candidate rewrite generation, constraint validation and selection, and layout write-back.

# Illustrative rewriting pipeline (pseudo-code: describes flow and constraints only, no specific APIs)
PROTECTED_PATTERNS = [
    r'\$[^$]+\$',             # inline formulas
    r'\\begin\{equation\}',   # standalone equation environments
    r'\[\d+(?:[-,]\d+)*\]',   # citation markers
    r'^[A-Z][A-Za-z ]{2,}$',  # abbreviations and proper nouns
    r'^\s*(?:表|图|Table|Figure)\s*\d+',  # table and figure captions
]
def rewrite_document(doc, cfg):
    blocks   = parse_blocks(doc, keep_layout=True)   # paragraphs / tables / footnotes / formulas
    glossary = extract_glossary(doc, blocks)         # glossary; mapping must be globally unique
    result   = []
    for block in blocks:
        if block.kind in {"reference", "formula", "code", "caption"}:
            result.append(block.raw)                 # hard protection: never rewritten
            continue
        spans = mask(block.text, PROTECTED_PATTERNS) # mask before rewriting
        cands = generator.generate_batch(spans.masked, n=cfg.n_best)
        best = select_best(cands, glossary, weights=cfg.weights,
                           min_semantic_sim=cfg.min_semantic_sim,
                           max_sent_len=cfg.max_sent_len)
        if best is None:
            result.append(block.raw)                 # fall back to source when no acceptable candidate
        else:
            result.append(restore(best, spans))      # restore the masked spans
    return render(result, layout=doc.layout)

Three design points deserve emphasis:

1. Fallback mechanism. When any constraint is not satisfied, return the original text rather than forcing an output. This is the last line of defense for “never change what is wrong.”
2. Global terminology consistency. The same term must have only one rendering or expression across the whole document; otherwise one concept acquires multiple names, which is a clear defect in academic text.
3. Structure awareness. Table cells, footnotes, numbered lists, and references must be handled as structured blocks. Treating them as plain text directly causes layout collapse.

4. Serving on the Cloud: Assembling It from General-Purpose Building Blocks

This type of workload is typically long-running, batch-oriented, and marked by clear peaks and valleys. It can be built entirely from general-purpose cloud product categories, with no proprietary components required:

• Object storage: stores source documents, intermediate artifacts, and results of each version, with lifecycle policies for archiving.
• Message queue: decouples upload tasks from inference tasks, enabling asynchronous consumption, retry on failure, and peak shaving.
• Container platform + GPU inference resources: scales elastically with queue length and scales down when idle to control cost.
• Logging and monitoring with alerting: collects task success rate, end-to-end latency, semantic similarity distribution, and the manual spot-check rejection rate, with threshold-based alerts.
• Canary release: a new rewriting strategy is first validated on a small traffic share and rolled out fully only after its metrics pass.

5. Evaluating Effectiveness: How to Prove the Rewrite Is “Good”

Evaluating only with detector scores amounts to measuring a system with a ruler the system itself controls. A multi-dimensional metric system is recommended:

• Semantic preservation: sentence-embedding similarity and keyword coverage, with a lower-bound threshold; anything below the threshold is immediately judged unacceptable.
• Terminology consistency: glossary hit rate and the number of synonyms used for the same term.
• Format fidelity: the difference from the source in paragraph count, table cell count, formula count, and citation count should be 0.
• Readability: average sentence length, share of over-long sentences, and connective usage density.
• Blind human review: scored on three dimensions, “terminology accuracy, logical coherence, and no loss of information,” submitted under double-blind conditions.
• Detector change: used only as a reference item, never as the primary metric.

For experiment design, samples must be stratified by genre (abstract, methods, experiments, review, formula-dense sections), with at least a hundred items per stratum, and a control group of “no rewriting” must be retained; otherwise it is impossible to separate changes caused by rewriting from the detector’s own fluctuation.

6. Common Pitfalls and a Risk Checklist

• Score-driven rewriting: sacrificing accuracy to push down a score leads to factual errors and lost citations, which is not worth it.
• Format collapse: after rewriting, tables become misaligned, footnotes are lost, and formulas turn into garbled text. The rework cost far exceeds the benefit.
• Privacy risk: uploading unpublished work to third-party services of unknown provenance may expose results and create data compliance problems. Prefer solutions that can be deployed privately or that retain no data.
• Cost traps: so-called “permanently free” tiers usually come with quota limits, queue times, and reduced format capabilities. When evaluating, focus on cost per document and concurrency capacity rather than the advertised price.
• Boundaries of responsibility: a rewriting tool can only improve expression; it cannot replace the author’s own research and writing. Authorship responsibility, citation norms, and the AI-use disclosure rules of one’s institution and journals remain the author’s responsibility. Using such a tool to cover up ghostwritten work is academic misconduct, and no technical measure provides an exemption.

7. Practical Checklist

1. First self-check the sources of misjudgment: is the text too short, is terminology too dense, is Chinese-English mixed text present?
2. Before rewriting, build a glossary and a list of protected spans to make the “do not touch” scope explicit.
3. Enforce the fallback mechanism: better to under-rewrite than to rewrite something wrong.
4. Establish a multi-dimensional evaluation and blind human review process to avoid being driven by a single metric.
5. Version both the source and the rewritten results, keeping traceable records.
6. Clarify data provenance and compliance boundaries before deciding on the deployment model.