AI Systems
User Feedback — Building the Data Flywheel
Collecting feedback closes the loop across every other pattern in this domain: feedback improves the eval set, better evals identify what to fine-tune, fine-tuning improves output, improved output generates more positive feedback. Without this loop, a system ships at a fixed quality level and slowly degrades as the world around it changes. With it, the system compounds.
- What it is
- Systematically capturing signal about output quality from real usage, and feeding it back into evaluation and fine-tuning.
- Mental model
- A flywheel: each turn (interaction → feedback → curation → retrain) costs effort to start, but a system that closes the loop compounds instead of plateauing.
- Key numbers
- Explicit feedback participation is typically only 1–5% of interactions and skews toward the very satisfied or very frustrated — implicit signals have far higher volume but need calibration against explicit signal before being trusted alone.
- Reach for it when
- A system is live and quality has plateaued, or before it plateaus — this is a pattern to design in from day one, not bolt on once growth stalls.
Explicit feedback
Direct user signals: thumbs up or down, star ratings, free-text corrections. Clean and unambiguous, but participation is typically only 1 to 5 percent of interactions and skews toward users who are either very satisfied or very frustrated — a J-curve that biases naive aggregate scores. Maximize participation with low-friction, contextual prompts (one tap, asked immediately after the interaction) and specific questions rather than generic satisfaction surveys.
Implicit feedback
Behavioral signals inferred from actions: regeneration requests, copy or paste events, edit distance on a suggested draft, task completion rate, session abandonment. Volume is far higher than explicit feedback and captures users who never click a rating button, but the signal is noisier — a regeneration might mean the user was exploring alternatives, not that the first answer was bad. Calibrate implicit signals against a sample of explicit feedback before trusting them as a standalone quality metric.
Correction capture
The highest-value feedback type: logging the specific corrected version when a user fixes a bad output. An edited draft, a corrected code snippet, a modified query — each (original, corrected) pair is effectively free, in-distribution fine-tuning data. Building correction capture into the product itself — edit-in-place interfaces, explicit submit-corrected-version flows — is one of the highest-ROI investments in the whole flywheel. The constraint is privacy: corrections often contain sensitive content and require appropriate consent and anonymization before entering a training pipeline.
Productionizing this pattern
- Guard against feedback loops that reinforce existing bias — fine-tuning only on corrections from the most engaged users increasingly optimizes for that subgroup's preferences.
- Separate the feedback collection pipeline from the training pipeline with a manual or automated curation and deduplication step in between. Raw feedback should never flow directly into training without a quality filter.
- Address the cold-start problem explicitly — before enough production feedback exists, seed the eval set and initial fine-tune data from synthetic examples, red-teaming sessions, or a small paid annotation batch.
- Track feedback-loop latency (time from a user correction to that correction influencing the live model) as an explicit metric.
Real-world applications
- Writing assistants — edited drafts feed directly back into (original, corrected) fine-tuning pairs.
- Code assistants — accepted vs. rejected suggestions, and the edits made after acceptance, are exceptionally high-signal implicit feedback.
- Support chatbots — escalation-to-human rate is a strong implicit quality signal that needs no explicit rating at all.
- Recommendation-adjacent LLM features — regeneration and dismissal rates calibrate directly against explicit thumbs feedback.
Embedded applications
- Field telemetry as implicit feedback — a fleet of deployed devices already generates enormous implicit signal — fault-code recurrence, a technician overriding an AI-suggested diagnosis, a retry loop on an automated action — without needing a thumbs-up button anywhere; this is the embedded analogue of "implicit feedback has far higher volume but needs calibration against explicit signal."
- OTA-delivered model updates close the loop physically — the "retrain/tune" step of the flywheel, once it produces an improved checkpoint, still has to reach the device — that's exactly the atomic-update-and-rollback machinery already covered in Ubuntu Core and kernel patching. Feedback-loop latency for an embedded fleet includes OTA rollout time, not just retraining time.
- Correction capture needs a physical interface — on a device with no keyboard, "correction capture" might mean a technician's field-service tool logging what action they actually took after overriding an AI suggestion, or a simple accept/reject button on a small display — the UX constraint is real hardware, not a web form, and shapes what's even possible to collect.
- Bandwidth-aware feedback upload — for devices on metered or intermittent connectivity, feedback collection itself needs the same store-and-forward thinking as any other constrained telemetry pipeline — batch and compress corrections locally, upload opportunistically, exactly the pattern already used for sensor logging over MQTT.
Gotchas
- A flywheel that only samples from your most vocal or most engaged users will faithfully optimize toward that group's preferences, and away from everyone else's — this is a bias problem, not a data-volume problem, and more data doesn't fix it.
- Raw, uncurated feedback flowing directly into a training pipeline is how label noise and outright bad examples silently degrade a fine-tune — the curation step is not bureaucracy, it's where quality control actually lives.
- A cold-start plan is not optional — a system with zero feedback yet still needs an eval set on day one, seeded from synthetic examples or a small annotation batch, or there's no way to tell if the first version even works.