AI portraits: same selfie, different face every run—in 2026, random variation or seed locking?

Opening conclusion: In AI portrait mini-programs, running the same selfie multiple times often gives a different face each time. In 2026, the common main cause is not that the model is not new enough, but that the random seed, identity weight, and beauty filter strength are not fixed, and the upload gate does not block substandard inputs. First fix parameters and seed for comparison, then separate identity preservation and beauty filters, and only then evaluate whether to change the face model. Most projects that handle it in this order see less rework.

Why “a different version every time” is often misdiagnosed as a model problem

AI portraits, face swaps, and retouching are not a single filter but a pipeline linking face detection, keypoints, identity preservation, stylization, beauty filters, super-resolution, and moderation. If any step on the pipeline involves random sampling, parameters are not versioned, or multiple faces are not locked to a target, repeated generation from the same base image will drift. What users feel is “not looking like themselves”; in engineering terms, it often first shows up as inconsistency.

• Skin texture and face width differ each time: Check more whether beauty filters and super-resolution include random terms, and whether parameters change when styles are switched.
• Overall facial feature shift: Eye distance and nose shape change with a different pose—check more on identity preservation weight, keypoints, and reference image combinations.
• For the same user, some images are good and some are poor: Check more on the input gate. Backlighting, occlusion, and group photos without a specified target face all amplify drift.

Attributing “not looking alike” directly to the model makes it easiest to overlook business-layer parameters and input materials. The value of a portrait product lies in identity recognition. Users are willing to pay and share usually because the result is both good-looking and still like themselves; once repeated generation from the same base image shows obvious differences, refund inquiries and negative reviews tend to cluster.

How to tell whether it is random fluctuation, identity not locked, or unqualified materials

Diagnosis should be broken down by observable metrics, not by feel. A common approach is to prepare a validation set of 30 to 50 real user selfies, covering front lighting, backlighting, glasses, side profiles, and group photos, then repeatedly generate multiple rounds under fixed seed and fixed parameters to see which layer the differences come from.

• Same seed, multiple rounds: Run the same base image and same parameters for two to three rounds. If differences remain large, there are unfixed random terms in the pipeline or parameters vary per request.
• Lower beauty filter to see changes: If uniformly lowering beauty filter strength clearly improves “looking like the person,” the problem is business-layer weight allocation, not the model.
• Review input materials: Blur, low light, masks, and multiple faces without a specified target all worsen later model performance. The system should prompt a retake or change of reference image before generation.
• Acceptance criteria: Similarity scores are only for initial screening. Final judgment should be based on manual blind tests, negative review keywords, and a drop in complaint rate; thresholds are mostly calibrated according to the model documentation in use. A typical range is to take the middle segment first, then backtest.

Nameable framework: The four-layer pipeline for AI portrait consistency

The purpose of breaking AI portraits, face swaps, and retouching into four layers is to make “different every time” attributable and regression-testable, rather than repeatedly trying one switch.

1. Capability layer: Face detection, keypoints, generative models, beauty filters and super-resolution, and content moderation. Image style, character consistency, and text orchestration often require a combination of multiple models; it is not advisable to expect a single model to handle every stage.
2. Business layer: Identity preservation weight, beauty filter strength, style presets, multiple face selection, random seed and parameter versioning, retries and fallbacks. Make beauty filters and identity preservation two independent parameters to avoid “good-looking” overriding “looking like the person.”
3. Carrier: Mini-program, H5, APP, or website. Package size, upload compression, share cards, and payment paths directly affect input quality and conversion.
4. Data and risk control: Face authorization, liveness verification, storage duration, encryption, moderation logs, and sampling inspection. Face data should not be retained indefinitely, and moderation should be placed at both ends before and after generation.

The framework is not meant to make every project heavy, but to first locate which layer the problem is in. Low-frequency internal trials can simplify the carrier and data layers, but identity preservation and authorization disclosures cannot be omitted.

Delivery scene: What to do first for a two-to-three-week launch when inputs are mostly phone selfies

A common constraint is limited budget, a two-to-three-week launch cycle, and user inputs that are basically phone selfies, mixed with backlighting, glasses, and group photos. The project approach is to reverse the order: first add an upload quality gate, then split beauty filter strength and identity preservation into two parameters and record them in the version number, fix the seed and log parameters during generation, run similarity initial screening before manual sampling, and cache results for high-frequency styles. The cost is a few extra front-end prompts and a parameter table that needs human maintenance, but generation failures and post-hoc revisions drop noticeably.

If you only change the model from the start, common sticking points are: the new model’s style changes but beauty parameters are not adjusted accordingly, and users still say it looks like a fake person; group photos take the first face by detection order, causing complaints about swapping the wrong person; the seed is not fixed, so A/B conclusions cannot be reproduced; without caching, repeated generation for the same user drives up API call costs. In terms of experience ranges, fixing only parameters and seed commonly takes one to five days of development; model change integration commonly takes a few days to two weeks; private deployment usually starts at the tens of thousands of RMB level, with timelines commonly weeks to months.

Three paths compared: fixing parameters, changing models, and private self-hosting

• Fix parameters and seed, add input gate: Cost is mainly development and regression testing; a typical experience range is one to five days. Risk: once parameters change, all users are affected, so gray release is needed.
• Change models or add model routing: Cost is mostly API usage and integration time; a typical experience range is a few days to two weeks. Risk: style and moderation criteria change, requiring rebuilding of the validation set.
• Private self-hosting: Includes servers, operations and maintenance, and model updates; a typical experience range starts at tens of thousands of RMB and rises with concurrency. Suitable for teams whose face data cannot leave their domain and whose call volume is stable.

When making a verifiable comparison, it is advisable to score across five dimensions: identity preservation, output consistency, moderation pass rate, cost per image, and launch cycle—rather than only looking at whether a particular image looks good.

Applicable scenarios and inapplicable boundaries

Applicable: consumer-facing portrait mini-programs, H5, APP, social avatars, e-commerce model outfit swaps, lightweight ID photo retouching, and other scenarios aimed at output efficiency and share conversion; teams with clear face authorization, storage duration, and moderation capabilities are better suited for long-term operation. Not applicable: judicial face comparison, financial remote account opening, medical diagnosis, and other high-accuracy or heavily regulated scenarios. Generative AI is only suitable as an aid and should not be the sole basis for judgment; without lawful authorization and privacy protection capabilities, user face data should not be collected or stored long-term. If it is only a low-frequency internal trial, using API calls first is sufficient; private deployment is not necessary.

Frequently asked questions

Is it normal for the same selfie to produce different results when generated repeatedly?

Mild differences are common, but obvious drift in facial features and face shape is usually not normal. First check whether the random seed is fixed, whether parameters are versioned, and whether a target face is specified for multiple faces.

After locking the seed, it still does not look like the person—what should be changed first?

First separate beauty filter strength and identity preservation into two parameters, and lower the beauty filter for comparison. If improvement is obvious, it is a business-layer problem; if it still does not look alike, then consider changing models or adjusting the reference image combination.

In group photos, swapping the wrong person usually gets stuck at which step?

Commonly, the front end does not let users select a face, and the back end takes the first face by detection order. The approach is to let users specify the target face and retain the correspondence between face boxes and IDs.

For a portrait mini-program in 2026, should you start with API calls or private deployment first?

First use APIs to validate demand and output quality. Once call volume is stable, face data cannot leave your domain, or the bill is consistently higher than self-hosting, then evaluate private deployment.

Should moderation be before or after generation?

Both ends are needed. Before generation, do face authorization, liveness verification, and input quality assessment; after generation, do content compliance, face comparison, and sampling inspection. Missing either end easily leads to rework after launch.

If you plan to launch AI portrait, face swap, or retouching features in 2026, first use a small validation set to run through both the identity preservation and beauty filter pipelines under fixed parameters, then decide whether to change models or go private. For high-accuracy scenarios such as judicial and financial real-name verification, generative AI is suitable as an aid and should not be the sole basis for judgment; without authorization and privacy protection capabilities, do not store face data long-term.