Datasets and Training in ML Prediction Engine

Where Datasets Live

Each model step in a pipeline owns one dataset, stored as a jsonL file in your data folder, one JSON object per line:

{"input": "refund my order please", "label": "billing"}
{"input": "app crashes on startup", "label": "technical"}
{"input": "do you offer team plans", "label": "sales"}

The admin shows the same rows as a table you can read, add to, and delete from, and the file on disk is yours: readable with any tool, backed up by copying the folder, and diffable when you want to know what changed. Because a step's dataset belongs to the step, switching that step to a different model class keeps every row ready to retrain under the new class.

What Rows Look Like

Text models take a string input, and the engine vectorizes it automatically with tf-idf at training time. Numeric models take a list of numbers, sent as an array or a comma string, "1500, 3, 0.7" works, and the engine scales the values itself. The label is the answer you want back: a category name for classifiers, a number for regressors. Clusterers and anomaly detectors train on inputs alone, so their rows carry just the input, and anomaly detectors give their best results trained on normal data only, so anything different stands out at predict time.

Four Ways to Load Rows

One at a time in the admin. The row editor on each pipeline page, best while you are curating and correcting.

One at a time through the API. dataset/add appends a row, with an optional train: "1" to retrain immediately after. This is how apps feed the engine as real examples arrive, a solved ticket becomes a training row the moment it closes.

In bulk through the API. dataset/set replaces a step's whole dataset with jsonL text you send, the right tool for first loads and scheduled rebuilds from your own database:

curl -X POST http://localhost:8080/api.php/dataset/set \
  -H "Content-Type: application/json" \
  -H "X-API-Key: YOUR_KEY" \
  -d '{"pipelineID": 1, "modelIndex": 0, "filecontent": "{\"input\": \"refund my order\", \"label\": \"billing\"}\n{\"input\": \"app crashes\", \"label\": \"technical\"}"}'

Automatically from traffic. Live training appends each prediction to the dataset and retrains on a schedule, the engine feeding itself.

Rounding out the set, dataset/rows lists a step's rows and dataset/clear empties it, so external tools can inspect and manage data with the same API they use for everything else, all detailed in the API reference.

How Training Works

Training is one click in the admin or one train call, and it always rebuilds the model from the complete dataset. That design keeps the mental model honest: the dataset is the whole truth, every training run is reproducible from the file, and editing or deleting rows genuinely changes what the next model knows. The response tells you how many rows it learned from, and the trained model is stored as a file in your data folder next to its dataset.

The admin's test box completes the loop: type an input, see the prediction and each step's output instantly. Add rows, retrain, test again, the cycle takes seconds, which is what makes actually improving a model practical instead of theoretical.

Dataset Habits That Pay Off

• Feed it real inputs. Train on the messages, numbers, and phrasing your system actually receives, real tickets beat invented examples every time.
• Balance your labels. A classifier fed 500 billing rows and 20 technical rows will favor billing. Keep label counts within the same neighborhood.
• Start small, grow with mistakes. Twenty or thirty rows per label is a real starting point. Then make every wrong prediction a new training row with the right label, correction-driven data is the highest value data you can add.
• Prune as you learn. The visible table means bad rows are findable, mislabeled examples and stale phrasing come right out.
• Back up the folder. Datasets and models are plain files, one folder copy protects everything.