Preparing a dataset for fine-tuning: quality and privacy

Why think about quality and privacy up front

Fine-tuning differs from training from scratch: you don’t build a model anew, you adapt existing behavior to your tasks and style. Because of that, data often has a stronger impact than it seems: a few thousand incorrect or “noisy” examples can noticeably shift outputs, even if the base model was strong.

Errors in data almost always turn into model errors. Inconsistent annotation leads to different answers for identical queries. Template wording makes responses monotonous. Outdated rules or terms cause the model to confidently give incorrect recommendations.

Quality and privacy should be checked together, not one after the other. The most “suspicious” fragments (numbers, addresses, full names, internal IDs) often appear in the most valuable examples—real conversations and requests. If you annotate first and then clean, you can easily break meaning, context and labels. If you clean first without clear rules, you may remove important signals and create bias.

Problems usually surface after deployment when fixes are expensive: the model unexpectedly exposes personal or internal data, responses drift toward one team or region, the number of confident but wrong recommendations rises, and repetitions from the dataset create a sense of “memorized” phrases.

Preparing a dataset for fine-tuning is not a formality. It’s protection against reputational and legal risks and against gradual quality degradation.

Clarify the goal and dataset requirements

Before collecting and labeling data, specify what the model should do. The same corpus of texts can work well for classification but fail in a chat setting: different examples, structure and checks are needed.

Start with a short one-paragraph task description: who the user is, what they ask, and what the model should return. Then define the task type: classification (assign a label), extraction (pull fields), generation (write a response), search and ranking (find the best fragment). After that, set format requirements: what comes in (string, dialog, table, document) and what counts as correct output (label, JSON fields, templated text, reference to a source in the document).

Write success criteria in advance. For classification this is usually precision and recall; for extraction—the share of correctly filled fields. For chat responses, a checklist is convenient: usefulness, no hallucinations, correct tone and stability on similar queries.

Also set restrictions to avoid collecting a “forbidden” dataset: which sources are allowed by rights and contracts, which categories of data must not be used (personal, medical, financial), which internal documents are excluded, permissible retention periods and who can access the data.

In regulated organizations and public procurement contexts (including system integrators) this requirements document is often more important than the first dataset: it protects the project from rework and risky leaks.

Data collection and verifying usage rights

Training data usually already exists within a company, but it’s scattered across systems: support tickets, email threads, internal documents, event logs, survey responses and forms. Before export, identify which sources provide useful examples for your task and where privacy risks are highest.

Next—usage rights. Data always has an owner: a client, employee, contractor or the organization itself. Files on a corporate drive don’t automatically mean they can be used for training. Check for consent or contractual basis allowing machine learning and whether there are restrictions on transferring data to contractors or the cloud. For government, finance and healthcare this is often critical—sometimes work must stay inside the perimeter.

Separately define retention periods and access rules: who can view raw data, who sees only anonymized versions, where and how it’s stored, and how exports are logged. A good practice is to allocate a separate storage for the dataset and appoint a responsible person who approves access.

To avoid later confusion about where each record came from, keep a short dataset description and update it when things change: source and system, period and selection criteria, owner and legal basis, access and transfer limits, known risks (personal data, trade secrets).

Annotation process: rules, examples, unified approach

Annotation usually breaks down not because of “bad annotators” but because of fuzzy rules. Before starting, fix what exactly you are labeling: classes (e.g., request type), fields (topic, product), entities (organization, device model), sentiment or root causes. This is the basic step because the model learns exactly what you named and showed.

A short instruction that people actually read

The instruction should be short and practical: 1–2 pages, minimal theory, more examples.

Describe each label in simple words and add boundaries: what fits and what doesn’t. Provide 3–5 examples per label, including “similar but wrong” cases. Add a rule for uncertain cases (where to put borderline examples), clarify the field formats and how to handle empty values. List prohibitions explicitly: what cannot be annotated or copied, including personal data.

Example for support: agree in advance what counts as “server issue,” “PC issue,” “access/accounts” and what goes into “other.” Provide a counterexample: “computer is slow” is not “network,” even if Wi‑Fi is mentioned.

Ambiguous cases and a single position

Disputed categories are inevitable. A practical rule: the annotator assigns a label and marks the record as “uncertain,” and the team lead reviews such records daily and records the decision.

Keep instruction versions (v1, v2, v3) and a separate decision log: date, question, adopted rule, and a pair of examples. This prevents retraining people from scratch and lets you explain annotation logic to legal, security or audit teams.

Annotation quality control without heavy statistics

Annotation quality often matters more than dataset size. Even a small share of wrong labels can train the model to fail on the business-critical cases.

A practical method is double annotation on a subset. Take 5–10% of records and have two annotators label them independently. Then compare discrepancies and focus not on who’s right, but on which rules are ambiguous and where examples are too few or too similar.

Where disagreements usually arise

Annotators disagree most on borderline cases: mixed intentions, incomplete messages, sarcasm, abbreviations, mixed languages in one text. In support tickets, one message can be both “not working” and “needs configuration.” Without a specified rule, the model will later err on real complex requests.

Acceptance threshold and regular audits

Decide in advance which errors are acceptable and which block dataset release. It’s useful to split errors into critical and non-critical and set a threshold: if critical errors on the control sample exceed the agreed level, return the annotation for correction.

A steady rhythm helps: spot audits per batch, review common errors, provide short feedback to annotators. After each round update the instruction with examples from real disputes. This usually improves quality faster than trying to tighten controls.

Duplicate control and similar records

Duplicates are not only exact copies. Near-identical records and template replies that differ only by ticket number, date or name are common. This is one of the fastest ways to accidentally spoil training.

Duplicates inflate the dataset and give a false sense of quality. The model starts memorizing recurring wording, and validation metrics grow simply because training and test contain very similar records. In practice this shows as uniform answers and low robustness to new formulations.

How to find duplicates in practice

Combine several simple checks: detect exact matches (normalize text and compare hashes), find near-identical records (similarity thresholds using n‑grams or your tool’s metric), detect templates (remove variable parts like IDs and dates and compare), and cluster similar records for batch review.

Example: “PC won’t turn on, urgent” and “PC does not turn on, urgent” are nearly the same for a model. Dozens of such repeats skew training.

What to do with duplicates

Choose a strategy: delete extra copies, merge records if different fields matter, or mark as “frequent template” and control their share in training.

The key rule: identical or near-identical records must not be in training and validation simultaneously. This is a common cause of “beautiful” metrics but poor real-world performance.

Removing sensitive data and protecting privacy

If the data contains personal information or secrets, the model can memorize and later leak them. Therefore privacy decisions come before debates about dataset size.

Sensitive data typically includes IIN, phone numbers, addresses, birth dates, medical data, salary and debt information, document numbers, account numbers and payment details. Secrets in text are also risky: passwords, API keys, tokens, internal client or device identifiers. Even if not personal, such leaks can lead to breaches.

Choose an approach based on the task. Sometimes it’s better to remove fragments entirely. Sometimes masking (replace IIN with "[IIN]") or tokenization ("[PHONE_1]") is enough to preserve structure. For analytics, generalization helps: city instead of full address, age group instead of birth date.

Example: support requests about servers and workstations may contain an engineer’s phone number, IP, serial number and a screenshot with an account. Decide in advance what to keep (device type, symptom, outcome) and what to replace with markers.

Before training run quick checks: pattern scans (IIN, phones, emails, keywords like "password"), a manual sample of 50–100 records from different sources, inspect attachments (scans, images, CRM exports), search for rare strings (unique long numbers and tokens) and re-check after cleaning.

Proper splitting: how to avoid leakage

Even a well-collected dataset will produce “too-good” metrics if split incorrectly. The main mistake is letting very similar records appear in both training and validation. Then the model memorizes instead of learning and performance drops after release.

A robust principle is to split by sources or groups so similar texts don't cross sets. Common variants: by time (train on past, validate on new), by users, by organizations or branches, by cases or ticket threads (keep an entire conversation in one set).

Leakage often hides in templates and quotations. Operators copy identical replies and users forward previous emails. If part of a thread goes to train and part to test, the test is no longer honest. Before splitting normalize texts (remove signatures, auto-responses, long quotes) and group similar records by simple rules (topic, ticket number, close text).

Document splitting rules: which key you use for grouping, how you pick time boundaries and allowed exceptions. Save lists of identifiers assigned to each set.

Checking bias and representativeness

Bias appears when the dataset strongly reflects one case type and barely contains others. A common example is too many examples of one class (80% "password resets" and 5% "payment failures"). Another is bias by source: data only from one channel or one period (seasonal spikes).

Detect problems without heavy stats: produce simple summaries and review them. Useful views are class and source frequencies, top topics and keywords per class, text length distribution, share of "other", and manual checks on rare classes.

If bias exists, three approaches help: collect more missing examples, narrow or broaden classes, or re-annotate disputed cases if rules were unclear. In dataset preparation for fine-tuning, decide which errors hurt production most and strengthen those areas.

Don’t “improve metrics” at the cost of real-world quality. Artificially balancing classes can make the model over-predict rare responses where they rarely occur. Safer approach: keep a separate test reflecting real distribution and validate there that changes didn’t worsen behavior.

Example scenario: fine-tuning on user support requests

Suppose you have accumulated a support ticket database: user messages, operator clarification questions and final responses. For a system integrator with 24/7 support these dialogues flow continuously, and you want to fine-tune a model to suggest draft replies for operators.

Three typical problems appear quickly: copy-pasted content (template replies and repeated tickets about the same outage), “empty” messages like “ok”, “noted”, “thanks” that bloat the dataset, and personal data (full names, phones, addresses, IIN, contract numbers, serial numbers, sometimes payment details and logins).

To preserve meaning while removing noise, filter before annotation: drop messages shorter than 2–3 words if they contain no signal; merge short confirmations with the prior substantive turn if context matters; keep context (at least 1–2 previous messages); mask sensitive fields with consistent tokens like [PHONE], [IIN], [CONTRACT]; and remove duplicates and near-duplicates keeping the best example.

Design a test set separately. It should reflect the production stream, not only “nice” examples. A convenient approach is to hold out recent dialogues (e.g., the last week) and ensure the test contains frequent questions, rare but critical incidents, incomplete descriptions and complex cases where the operator asks clarifying questions.

This way you’ll see if fine-tuning helps operators and whether you degraded the model due to noise, privacy leaks, or bias toward repetitive templates.

Step-by-step plan to prepare a dataset before fine-tuning

Good dataset preparation is almost always cheaper than fixing the model after training.

1. Define the task: what the model should do, how you measure success (answer accuracy, error rates, processing time) and which data cannot be used. Add constraints for language, tone and topics.

2. Collect data and build a source registry: where each batch came from, who owns it, whether consent exists and if data can be used for training. This saves time later when security or legal questions arise.

3. Normalize formats and clean noise: broken records, technical tails, case normalization, extra spaces. At this step also remove sensitive fields (names, phones, IIN, card numbers, addresses, internal IDs). If relations are needed, replace them with stable pseudonyms.

4. Prepare annotation instructions and examples. Run a small pilot annotation, compare disagreements and clarify rules. Several short iterations are better than one large error-prone pass.

5. Check duplicates and splitting. Remove duplicates and near-duplicates. Split into train, validation and test so similar cases don’t appear in different parts (for example, all messages from one client or organization in the same set).

Before training, do a final bias check: are there gaps by region, language or request types, and does one noisy class drown out others? If many template “internet not working” reports exist, the model may start replying uniformly and handle rare but important incidents worse.

Short checklist, common mistakes and next steps

A final check before fine-tuning usually takes an hour or two but can save weeks.

Check three things: duplicates (and near-duplicates) are found and handled; sensitive data is removed or masked consistently across the dataset; and the train/val/test split keeps independence (no overlap by users, cases or documents). Then review bias: which topics, languages, regions or classes are over- or under-represented. Record versions: sources, cleaning scripts, annotation rules, export dates and final set sizes.

If you have annotations, also verify that the instruction is short with examples, disputed cases were audited, a small audit was done (sample review and discrepancy analysis), and rules for new data types are agreed so labels aren’t silently changed later.

Typical mistakes that spoil results: cleaning and filtering test data together with training data; removing personal data only in one part of the dataset; mixing old and new annotation versions; evaluating metrics on data the model already “saw” via duplicates or common templates.

Next, decide how and where to store the dataset (encryption, backups, access logs), who has read/export rights, how you run training and keep artifacts (models, logs, configs). If you need a closed environment and help with infrastructure for training and storage, this can be discussed with GSE.kz—for example, using S200 servers, workstations and system integration services with access control and support.