@mindstudio-ai/remy 0.1.285 → 0.1.287
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/prompt/skills/jewels.md +24 -10
- package/package.json +1 -1
|
@@ -224,18 +224,32 @@ The wiring itself is two manifest lines on the method's entry:
|
|
|
224
224
|
```
|
|
225
225
|
|
|
226
226
|
`tuning` (optional) is the training recipe for the jewel's own model. Every knob has a
|
|
227
|
-
platform default and most jewels never set any: `
|
|
228
|
-
|
|
229
|
-
|
|
230
|
-
|
|
227
|
+
platform default and most jewels never set any: `base` (which model to train — a slug
|
|
228
|
+
from the platform's small menu; `qwen3.5-4b` is the default, with `qwen3.5-9b` and
|
|
229
|
+
`gpt-oss-20b` as larger alternatives, and the default is the right choice unless a
|
|
230
|
+
report shows it falling short), `windowDays` (how many days of ledger history to train
|
|
231
|
+
on; default all history), `epochs` (1-10, default 3), `rank` (LoRA rank, 4-64, default
|
|
232
|
+
16), `learningRate` (default 5e-5). It requires `jewel`, and it rides the release:
|
|
233
|
+
changing a knob is a commit + deploy before the next training run.
|
|
231
234
|
|
|
232
235
|
Once a method has accumulated graded pairs, train from the prod CLI:
|
|
233
|
-
`mindstudio-prod jewels train <methodId>` (see `--help`).
|
|
234
|
-
|
|
235
|
-
|
|
236
|
-
the
|
|
237
|
-
|
|
238
|
-
|
|
236
|
+
`mindstudio-prod jewels train <methodId>` (see `--help`). It returns immediately with
|
|
237
|
+
a run id and the dataset report; a run takes minutes to tens of minutes, so never use
|
|
238
|
+
`--wait` (that flag is for humans at a terminal — it would block your whole loop).
|
|
239
|
+
Start the run, tell the user it's training, keep working on other things, and check in
|
|
240
|
+
with `mindstudio-prod jewels run <runId>` between tasks — the `progress` field shows
|
|
241
|
+
the live phase and training percent, and `status` goes `complete` or `failed` with the
|
|
242
|
+
full report. The dataset report says whether the ledger is trainable (pairs without an
|
|
243
|
+
attached `trace` don't count), and a run produces a downloadable LoRA adapter plus a
|
|
244
|
+
held-out agreement report: how often the trained model matched your team's decisions
|
|
245
|
+
on pairs it never saw. The adapter and report land in the app's own file store
|
|
246
|
+
(`models/` in the Files dashboard), so the user can download them there. Read
|
|
247
|
+
`report.grading.agreement` — it is scored by the jewel's own grade function, the same
|
|
248
|
+
grader as the pairs dashboard. The raw `agreement` field is a strict byte-level floor
|
|
249
|
+
that undercounts whenever free-text fields differ; never quote it when `grading`
|
|
250
|
+
exists (`mindstudio-prod jewels grade <runId>` re-grades if it is missing). The
|
|
251
|
+
trained model is an artifact and a report for now; serving it inside the app is a
|
|
252
|
+
later platform phase, so set that expectation honestly when a user asks.
|
|
239
253
|
|
|
240
254
|
## Arrival Triggers (`mindstudio.jewels.propose`)
|
|
241
255
|
|