China Telecom Gives Away a Model That Turns Requests Into Form Fields

China Telecom's XingChen lab has released an open model that reads a typed request and returns it as structured JSON, the tidy, labelled format that other software can act on without a human in between. ^[1]

The model is text-only. It expects text or a written conversation as input and the model card describes no audio task, so a spoken command has to be transcribed by a separate speech-to-text system before this model can parse it. ^[1]

The model is called Xing4.0-29B-Intent. The release on Hugging Face, the public hosting site for AI models, bundles the model weights (the learned numbers that make the model work, which anyone can download and run), a companion dataset and a Python software kit, all under an Apache 2.0 licence, which allows commercial use. ^[1] It is built on Xing4.0-29B-A4B, a base model with about 29 billion parameters, the count of those learned numbers and a rough gauge of a model's size. ^[1]

The only performance figures come from the developers themselves.

What the model actually does

People say what they want in loose sentences. Software wants fields. Someone types "find flights from Beijing to Shanghai tomorrow" and a booking system needs four things: the intent (search flights), the origin, the destination and the date.

The model card uses exactly that example. The request becomes a flight-search intent with origin, destination and date filled in. ^[1]

The developer defines what the possible tasks are and what information each needs. That definition is the schema, and it goes into the prompt along with the user's text. The model returns a JSON array of categories and arguments. ^[1] Researchers call the core job intent recognition and slot filling, the slots being the blanks in the form.

The card lists four supported tasks in all: intent recognition and slot filling, named entity recognition (picking out people, places and organisations), relation extraction (how those things connect) and event extraction. It lists Chinese and English use cases. ^[1]

Why developers want it

In a customer-service app, a smart-home hub or a travel service, the language model is often not the product. It is a gate. Its job is to decide which tool to call and with what inputs. A model that does only that, and outputs a reliable structure, is easier to slot into a pipeline than a chatbot that has to be coaxed into formatting its answer.

The card describes the base model as a mixture-of-experts design, with about 29 billion parameters in total and about four billion active for each token, the small chunks of text the model reads. ^[1] In a design like that, the model routes each piece of text through only part of its network. That can make running it cheaper than a conventional model of the same total size.

What it costs to serve in practice, and on what hardware, has not been reported.

The release also includes an SDK, a software development kit, that assembles prompts, sends requests to a model service and parses the structured results. Its documentation describes synchronous calls, which wait for an answer before the program moves on, and asynchronous calls, which run in the background. It also describes multi-turn conversation input, meaning a whole back-and-forth exchange fed to the model as one piece. ^[1]

The Apache 2.0 licence covers the weights, the public data and the code, including the SDK. ^[1]

The numbers, and their limits

The model card reports an evaluation of 6,000 samples drawn from 48 public datasets across the four task types. It gives an overall score of 58 on a 0-100 scale and an intent-understanding score of 81. ^[1]

The two figures sit far apart. The model's strongest number is on the task in its name, and the overall score is well below it. The gap suggests some of the other tasks are harder, though the card's own breakdown is the place to check.

The card is also candid about what the scores are. It says they are not business accuracy rates and warns that prompts, interfaces and inference settings, the options that control how the model generates its answer, can change the results. ^[1]

That is a fair warning, and it matters for a model whose output looks authoritative.

A well-formed JSON object is not proof the model understood the user. It can return a perfectly valid flight search for the wrong city.

No independent testing has been reported. How the model handles ambiguous requests, messy real-world conversations, company-specific schemas that were never in the public datasets, or languages beyond the two listed is not known. Nor is it known how it compares with the general-purpose models developers already use for the same job.

The dataset question

The release points to a companion dataset, published under the XingChen-AGI account on Hugging Face and labelled for Chinese and English text tasks. ^[1][2] The model card gives no count, and the dataset page returned a data-schema error when checked, so the size and composition of the data are unconfirmed. ^[1][2]

That matters more than it might seem. Open weights let anyone run a model. Open data lets others see what it learned from, check for overlap with test sets, and fine-tune it, that is, train it further on a smaller set of examples so it suits a particular job such as their own schemas. If the data is what the early report says, it may prove the more useful half of the release.

Where this leaves things

China Telecom is one of the country's big state-owned telecoms carriers, and a carrier has an obvious reason to care about this layer. Customer calls, service menus and app requests all end up as fields in a database. Publishing the tooling openly, rather than keeping it as an in-house system, invites outside developers to build on it and to find its faults.

That second part is the one to watch. What is still missing is a run on business schemas and real conversations the developers never saw, and a dataset page that loads so its samples can finally be counted.