Production GenAI for User Safety and Enhanced Matching Experience

tinder · Tech · year n/a · source Agentic: no · promotional bias: low · source-backed · extracted with prompt 0.5.6 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Consumer dating safety and recommendation explanation

Tinder needed production GenAI systems that could detect off-platform username handles with extremely high recall/precision and generate personalized match explanations for tens of millions of multilingual users.

Constraints:

• The safety classifier must work across 47 languages and adversarially changing user bios.
• False positives can punish legitimate users, so high precision is mandatory.
• Match explanations must be personalized, authentic, policy-aligned, and not cheesy or hallucinatory.
• Serving open-source LLMs at consumer scale requires low latency, controlled cost, warm GPU capacity, and robust monitoring.

Architecture

Tinder runs two fine-tuned open-source LLM systems. Username detection fine-tunes Mistral 7B with LoRA on curated/reviewed bios and serves multiple adapters for profile fields through Lorax on a shared base model. Match explanations fine-tune Llama 3.1 8B with LoRA, SFT, and DPO using iterative LLM-generated samples, manual rewrites, and product/content feedback. Self-hosted serving, GPU benchmarking, warm pools, autoscaling, post-processing checks, LLM judges, and monitoring support production reliability.

Diagram confidence: reconstructed (reconstructed from prose).

flowchart LR
  profile-text-inputs["Profile text inputs"] --> username-detection-adapters["Username detection adapters"]
  profile-text-inputs["Profile text inputs"] --> match-explanation-prompt-builder["Match explanation prompt builder"]
  username-detection-adapters["Username detection adapters"] --> shared-mistral-7b-base["Shared Mistral 7B base"]
  username-detection-adapters["Username detection adapters"] --> lorax-serving-layer["Lorax serving layer"]
  username-detection-adapters["Username detection adapters"] --> safety-flag-output["Safety flag output"]
  lorax-serving-layer["Lorax serving layer"] --> gpu-serving-pool["GPU serving pool"]
  safety-flag-output["Safety flag output"] --> monitoring-and-feedback["Monitoring and feedback"]
  match-explanation-prompt-builder["Match explanation prompt builder"] --> fine-tuned-llama-3-1-8b["Fine-tuned Llama 3.1 8B"]
  fine-tuned-llama-3-1-8b["Fine-tuned Llama 3.1 8B"] --> post-processing-checks["Post-processing checks"]
  fine-tuned-llama-3-1-8b["Fine-tuned Llama 3.1 8B"] --> gpu-serving-pool["GPU serving pool"]
  post-processing-checks["Post-processing checks"] --> monitoring-and-feedback["Monitoring and feedback"]
  monitoring-and-feedback["Monitoring and feedback"] --> fine-tuning-loop["Fine-tuning loop"]
  fine-tuning-loop["Fine-tuning loop"] --> username-detection-adapters["Username detection adapters"]
  fine-tuning-loop["Fine-tuning loop"] --> fine-tuned-llama-3-1-8b["Fine-tuned Llama 3.1 8B"]

Components

Data flow

For username detection, user profile fields such as bio, job, and name flow through field-specific LoRA adapters on a shared Mistral base model, producing safety flags at high precision. For match explanations, profile attributes are formatted into a prompt, a fine-tuned Llama model generates a short explanation, and post-processing/monitoring checks policy, formatting, token repetition, and output size. Iterative fine-tuning loops feed samples, rewrites, product/content feedback, and judge scores back into model updates.

Why this architecture

Tinder self-hosted and fine-tuned open-source models to protect user data, control iteration, and manage cost at high traffic. LoRA adapters share base models while adapting to profile fields/use cases, and GPU benchmarking/warm pools handle low-latency serving demands.

Models used: Mistral 7B · Llama 3.1 8B · LoRA adapters · Lorax · Predibase Lorax · LLM judges

Scale

• Tinder serves 47 million monthly active users across 47 languages.
  “serving 47 million monthly active users across 47 languages.”summary, stated
• The initial username training set used 2,000 manually curated flagged bios.
  “The initial training dataset consisted of 2,000 manually curated flagged bios”summary, stated
• The fine-tuned username detector reached nearly 100% recall at high precision, up from 33% recall at 98% precision for the prior rule system.
  “Their previous rule-based system achieved only 33% recall at 98% precision, while off-the-shelf models improved recall to 84-88%.”summary, stated
• The username detector processes roughly 2 million predictions daily and flags more than 260,000 profiles.
  “The username detection system processes approximately 2 million predictions daily and flags over 260,000 profiles”summary, stated
• Match explanations use about 300 input tokens and 100 output tokens per request.
  “approximately 300 input tokens and 100 output tokens per request.”summary, stated
• L40S serving achieved 2.1-second P50 latency and about 3.5K dollars daily cost for 600 QPS.
  “achieving 2.1-second P50 latency and daily costs of $3.5K for 600 QPS requirements”summary, stated
• Predibase enterprise Lorax produced a 2x cost and latency reduction.
  “Tinder also evaluated Predibase's enterprise Lorax solution, achieving 2x cost and latency reduction compared to open-source Lorax”summary, stated

Alternatives considered (roads not taken)

Rule-based username detection

Rejected because: It had only 33% recall at 98% precision, far below the fine-tuned model.

Off-the-shelf models without domain tuning

Rejected because: They improved recall but were still behind fine-tuned Mistral and had higher hallucination in match explanations.

External API-only serving

Rejected because: User-data privacy, iteration control, and cost pushed Tinder toward self-hosted open-source models.

A100 GPUs for match explanation serving

Rejected because: L40S GPUs had the best cost-latency tradeoff for the workload.

Patterns

fine-tuning-adaptation (modeling)

Both safety and match explanation systems rely on LoRA fine-tuning of open-source models.

model-routing (serving)

Multiple LoRA adapters specialize one base model for different profile components.

eval-driven-development (evaluation)

Iterations combine generated samples, manual rewrites, LLM judges, and traditional evaluation.

llm-as-judge (evaluation)

LLMs judge generated outputs alongside industry-standard metrics.

latency-optimization (serving)

GPU benchmarking, Lorax, TurboLoRA, quantization, warm pools, and autoscaling reduce latency/cost.

observability-tracing (operations)

Post-processing and monitoring track repetition, formatting, size, and user feedback.

Tradeoffs

Model hosting

Chose Self-hosted open-source LLMs over External proprietary API-only inference.

Rationale: Privacy, iteration control, and inference cost were critical with user data and large traffic.

Adapter serving

Chose Multiple LoRA adapters on one base model over Separate full model deployments per profile field.

Rationale: Adapters can be served concurrently and dynamically loaded without full redeployment.

GPU selection

Chose L40S for match explanations over A100 for this workload.

Rationale: Benchmarking showed lower cost/latency for 600 QPS requirements.

Gotchas (what bit them)

Rule-based safety detection missed adversarial bios.

Root cause: Bad actors adapt handles across languages/character sets, making static rules low-recall.

Resolution: Fine-tune Mistral with LoRA on curated and manually reviewed examples.

Subjective style was hard to evaluate and tune.

Root cause: Requirements like fun, engaging, authentic, policy-aligned, and not cheesy are nuanced.

Resolution: Use iterative fine-tuning with content/product feedback and LLM judges.

LLM serving has cold-start and autoscaling challenges.

Root cause: Heavy models and GPU workloads behave differently from CPU services.

Resolution: Use fixed warm pools, pre-warming, benchmarking, and sometimes over-provisioning.

Evaluation

Tinder evaluates with manual curation/review, LLM judges, traditional metrics, iterative 500-sample generation cycles, hallucination/coherence metrics, production monitoring, and user feedback.

Metrics: precision · recall · hallucination rate · coherence · P50 latency · QPS · daily cost · token repetition · formatting checks

Outcomes

• Username detection improved from 33% recall at 98% precision to nearly 100% recall while maintaining high precision.
• Match explanation hallucination fell to about 1% after multiple iterations.
• Enterprise Lorax produced 2x cost and latency reduction versus open-source Lorax.

Tinder reports 47M monthly active users across 47 languages, 2M username predictions/day, 260K+ profiles flagged, 600 QPS match explanation requirements, 2.1s P50 latency, and 3.5K dollars/day serving cost.