According to Baseten's official customer case, EliseAI converts conversations into business fields in scenarios such as housing services, and uses smaller models to perform fine-tuning. The case emphasizes training data quality and continuous iteration. This article studies it as enterprise model deployment data; the public materials do not provide the complete FDE personnel arrangement for the project described in this article, and the on-site team cannot be fabricated based on this.
The meaning of business fields needs to be determined before training.
The following is ChinaOPC simulation: The tenant first said that he hoped to move in as soon as possible, and then said that it would be more convenient in the middle of next month. Should the system retain the newer time intention, or prompt staff to continue confirming? If a customer asks whether a certain apartment type has a balcony, does it count as expressing a preference that a balcony must be provided? These judgments first belong to business rules.
If two annotators give different answers to the same conversation, there is a disagreement before the model is trained. The service team can hand over disputed samples to the business leader for adjudication, and record the adopted rules, scope of application and effective version. You cannot just compare the model output to an unchecked table and declare that the accuracy is achieved.
Retain the unknown instead of filling in the gaps with certain facts
Structured results should accommodate omissions, ambiguities, and inconsistencies. When the user doesn't say a budget, leaving the field empty often preserves factual boundaries better than guessing based on similar customers. The interface also needs to distinguish between "no such information" and "explicitly reject this option", otherwise subsequent screening may classify different situations into one category.
The test collection can cover initial expression, supplementary conditions, corrections, negation and multiple rounds of corrections. Each sample retains the source of the conversation, allowed scope of use, expected fields, and manual adjudication instructions; materials used for acceptance should be separated from training materials to avoid mistaking remembering old answers for being able to handle new business.
Make error repair into a small loop that can be handed over
After discovering the error, first locate whether the original dialogue lacks information, has incorrect annotations, conflicts in field definitions, or the model does not follow the rules. Different reasons correspond to different changes: fixing a problem, correcting a label, or changing a model cannot be mixed into the same category of "continue training". Each round of changes only records the actual revised content, and reruns relevant historical samples.
Deployment should also leave a recovery path for customers. How the old rules are paired with the old model, who can approve the launch, and how to handover to a person in case of exceptions should all be written in the handover materials. The speed and effect published by Baseten are supplier case statements. ChinaOPC has not retested them and does not use them as guaranteed indicators for local projects.
Extended reading: FDE model replacement acceptance. A truly take-over delivery is not just a model file after training, but also a set of business judgments that customers can interpret, modify, and continue to maintain.