Log backflow converts SLS (Simple Log Service) inference logs into structured datasets that can be used for model fine-tuning or evaluation.
Feature overview
The log backflow feature backflows inference log data from SLS (Simple Log Service) to the Bailian platform, formats it, and generates structured datasets (in JSONL format) that can be used for model fine-tuning or model evaluation. The backflow produces structured data, rather than a direct copy of the raw logs.
Scope
Log backflow supports creating the following two types of datasets:
-
Training set: The training scenario is text generation, and the training methods support SFT (Supervised Fine-Tuning), DPO (Direct Preference Optimization), and CPT (Continued Pre-Training).
-
Evaluation set: Supports the text generation scenario.
Log backflow is currently available only in the China (Beijing) and Singapore regions. The log backflow entry is not displayed in other regions. The upper limit of a single backflow is 100,000 entries, and you can backflow multiple times to different versions of the same dataset to accumulate more data.
Log backflow supports two storage methods: Platform Storage (default) and object storage OSS Mount (requires additional authorization). For the differences between the storage methods and selection guidance, see Create a log backflow dataset.
The datasets generated by backflow can be directly used for downstream tasks: training sets can be used for model tuning, and evaluation sets can be used for model evaluation. The data also supports subsequent data cleansing.
Enable and authorize related services
Before using log backflow, confirm that the current region is China (Beijing) or Singapore (the log backflow entry is not displayed in other regions), and complete the following service activation and permission authorization on the Model monitoring page. After all steps are completed, the authorization configuration drawer automatically closes and you enter the log backflow form.
Enable audit logs and inference logs
Audit logs and inference logs each require three steps to be completed. You can use log backflow only after all six conditions are met. Audit logs are a prerequisite for inference logs, so you must complete all audit log steps first.
Audit logs
-
Authorize the SLS service-linked role: Click Authorize Now to authorize the AliyunServiceRoleForSFMAccessSLS role. When not authorized, a red Not Authorized label is displayed.
-
Activate SLS Log Service: When not activated, a Not Activated status and a redirect link are displayed. Click the link to go to the SLS console and complete activation.
-
Enable audit logs: Click Create and Enable Audit Logs, and the system creates a LogStore instance and polls until it is ready (up to 60 seconds).
Inference logs
-
Authorize the SLS service-linked role for inference logs.
-
Confirm that SLS Log Service is activated.
-
Enable inference logs: When audit logs are not enabled, this button is grayed out. You must enable audit logs first.
Enabling must follow this order: audit logs first, then inference logs. Disabling must follow the reverse order: disable inference logs first, then audit logs. After logs are disabled, existing data cannot be restored. Confirm that you no longer need the log data before performing this operation. Once inference logs are enabled, SLS continuously incurs storage and read/write charges. Disable them when no longer needed.
OSS multi-role authorization (OSS Mount mode only)
When you select the OSS Mount storage method, you must additionally complete the following authorization:
-
In the authorization pop-up, select the data access authorization agreement.
-
Click One-click authorization, and the system automatically authorizes the following two service-linked roles:
-
AliyunServiceRoleForAccessCusOss (OSS write role)
-
AliyunServiceRoleForSFMDataHubOSSImport (DataHub import role)
-
The following table summarizes the service-linked roles involved in log backflow.
|
Role name |
Purpose |
Authorization timing |
|
AliyunServiceRoleForSFMAccessSLS |
Bailian accesses SLS log data |
Authorized once for audit logs and once for inference logs |
|
AliyunServiceRoleForAccessCusOss |
OSS data write |
When OSS Mount storage is selected |
|
AliyunServiceRoleForSFMDataHubOSSImport |
DataHub data import |
When OSS Mount storage is selected |
Create a log backflow dataset
Log backflow provides three entry points, all of which lead to the configuration form to create a dataset:
Model monitoring list page
At the top of the Monitoring list page, click Log Ingestion. For first-time use, complete the authorization configuration first. After authorization is passed, the log backflow form is displayed automatically.
Model monitoring detail page
In the time selector area of the model monitoring detail page, click Log Ingestion. When entering from this entry point, the form automatically pre-fills the time range, API Key, and model of the current page, and the model cannot be modified.
Data management page
When creating a new dataset on the Data management page, select Log Backflow as the import method. This option is visible only for training sets (text generation + SFT) or evaluation sets (text generation).
Configure backflow parameters
After entering the log backflow form, configure the following parameters from top to bottom. Some parameters have prerequisites: API Key filtering requires a time range to be selected first, and model selection requires both a time range and an API Key to be selected first. Modifying the time range, data type, training scenario, or training method will cascade-reset other parameters, so it is recommended to fill in the form strictly in order. The parameter values are described in the table below.
Estimated backflow data: The system displays the estimated number of backflow data entries based on the filter conditions. When the number exceeds 100,000, a red warning is displayed, and the excess will not be backflowed. When the query results are too many, the OK button is disabled, and you need to narrow the filter range.
Form cascade-reset rules: Modifying the time range resets the API Key (back to All) and model selection (cleared); modifying the data type, training scenario, or training method resets the storage location and import method.
The storage method, data type, and training method cannot be changed after creation. Confirm carefully before selecting.
|
Parameter |
Description |
Required |
Value description |
|
Backflow location |
Dataset storage method |
Yes |
Platform storage (default) or OSS Mount. OSS Mount is disabled for evaluation sets. Cannot be changed after creation |
|
Dataset name |
Display name of the dataset in the list |
Yes |
Chinese, English, digits, underscores, slashes, and hyphens, up to 50 characters. Recommended naming format: function_scenario_model_name_time. Cannot be modified after creation |
|
Dataset description |
Supplementary description of the dataset purpose |
No |
Up to 200 characters |
|
Type and format |
Dataset purpose type |
Yes |
Training set or evaluation set. When evaluation set is selected, training scenario and training method are hidden. Cannot be changed after creation |
|
Training scenario |
Training scenario type (displayed only for training sets) |
Yes |
Currently only text generation is supported |
|
Training method |
Fine-tuning method (displayed only for training sets) |
Yes |
SFT, DPO, CPT; options are dynamically displayed by the system. Locked after creation |
|
Time range |
Time period of the backflow logs |
Yes |
Last 30 days (including today), precise to hours, minutes, and seconds. Modifying resets the API Key and model selection |
|
API Key filter |
Filter log data by API Key |
Yes |
All (no filter), Other (excludes listed Keys), or select specific Keys (multi-select) |
|
Model selection |
Target models for backflow |
Yes |
Up to 10. Models that do not match the capability type filter are grayed out |
|
OSS data path |
Target directory for data storage (displayed only in OSS Mount mode) |
Yes |
The Bucket must be in the same region |
View backflow results
After submitting a log backflow task, view the dataset and import progress on the Data management list page.
List page display
Datasets created by log backflow display the import method as Log Ingestion on the list page, and the storage location is displayed as Platform Storage or OSS Mount based on the selection at creation.
You can view the import status of the task on the list page. When a task fails, you can view the specific failure reason returned by the system.
Under platform storage mode, the system automatically publishes the dataset version after import is complete, requiring no manual operation.
Detail page information
The information displayed on the dataset detail page varies depending on the storage method:
-
OSS Mount: Displays release status, data volume, creation time, FileID, data type, import status, and OSS mount address.
-
Platform storage (OSS import): Displays release status, data volume, creation time, FileID, data type, import status, and OSS import address.
-
Other cases: Display release status, data volume, creation time, FileID, data type, and import status.
Append log backflow data
On the Data management page, you can append a new batch of log backflow data to an existing dataset in the following two ways:
Import data page
Enter the Import data page of an existing dataset and select Log Backflow as the import method. The form parameters are the same as those in the creation flow. For details, see Create a log backflow dataset. This method additionally supports filtering by workspace.
This method is applicable to all storage types of datasets, including OSS Mount datasets.
Add version dialog
On the dataset detail page, click New Version, and select the log backflow import method in the dialog. This method is available only for platform storage datasets.
OSS Mount datasets do not support the New Version operation; the button is grayed out. Use the Import data page to append data.
Incremental backflow best practices
It is recommended to backflow in batches, targeting different time periods or different models separately, and gradually accumulating high-quality training sets. Each batch can precisely select models with good performance and data from business peak hours, ensuring data quality superior to a single large backflow.