yixiali-taiji-workflow

name

yixiali-taiji-workflow

description

Personal Taiji v5 workflow overlay for yixiali. Use together with taiji-basic-platform-skills when creating or starting yixiali RL/GRPO or SFT training tasks, applying yixiali naming and storage defaults, discovering checkpoints, automatically creating model cards and callable inference services, cloning evaluation tasks, monitoring the RL training-to-evaluation pipeline, auditing evaluation error rates, exporting xlsx metrics, restoring background monitors, or producing a full progress report.

Yixiali Taiji Workflow

Use this personal overlay together with the installed Taiji v5 aggregate skill. The target Taiji child skill owns exact tool schemas, authentication, and safety rules. This overlay supplies yixiali-specific defaults and cross-module orchestration.

Start every request

1. Route the request through taiji-basic-platform-skills and read the selected child SKILL.md completely.
2. Read only the personal reference needed for the request:
   • identity, credentials, names, paths, IDs: defaults-and-identifiers.md
   • RL/GRPO or SFT cloning and startup: training-workflows.md
   • checkpoint-to-evaluation automation: rl-automation.md
   • SFT export to HF and Yuanbao evaluation: sft-export-and-yuanbao.md
   • retries and xlsx exports: evaluation-and-export.md
   • full reports and monitor recovery: monitoring-and-reporting.md
3. Use only Taiji v5 clients. Do not use legacy/v4 tool names or TAIJI_API_TOKEN.
4. When tool names or parameters are uncertain, read the target child skill's API reference before calling it.

Maintenance contract

• Before changing this SKILL.md, describe the proposed change and obtain explicit user confirmation. A general request to improve code or references does not authorize changing SKILL.md unless it says so explicitly.
• Treat README.md as the user-facing mirror of personal preferences. Whenever an approved change affects names, defaults, IDs, source experiments, output paths, credentials handling, resources, evaluation policy, or reporting preferences, update the corresponding README table in the same change.
• Record every material change to this skill, its references, scripts, or preference documentation in CHANGELOG.md. Include the date, affected files or area, behavior change, and validation performed.
• Before adding code behavior, validate the need and assumptions first with the safest available evidence: an existing failing example, a local fixture/test, official v5 API documentation, or a read-only platform query. Then implement and run proportional post-change validation. Do not add speculative fallback logic without evidence.
• Do not default to accumulating small patches or defensive wrappers. When the current structure is the problem, propose a focused rewrite of the relevant section or module. Obtain user confirmation first when the rewrite materially changes scope, behavior, interfaces, or migration risk.
• Read README and CHANGELOG before maintaining this skill. Keep operational instructions concise in SKILL.md; keep detailed personal facts in references and mirror the user-facing subset in README.

Core defaults

• Use wsid=10103, identity yixiali, application group TaiJi_HYAide_PosttrainINF_NJ_H20, region zw, and GPU H20 unless the user overrides them.
• Append _yixia once to a new training run name when absent.
• Name a checkpoint model card, inference, service group, and normal evaluation {run_name}_step{step}.
• Name Yuanbao evaluations {run_name}_step{step}_nothink and {run_name}_step{step}_low.
• If an inference name exceeds 58 characters, propose a deterministic shorter name and ask before any write. Never truncate silently.
• Clone and start training by default. Honor an explicit clone-only/no-start request.
• Treat a request for the full RL pipeline as advance authorization for its listed idempotent writes. Never retry a failed write blindly.

Credentials

• Let Taiji v5 load PAT from TAIJI_PAT_TOKEN or ~/.config/taiji/credentials.json.
• Load SwanLab credentials from ~/.config/yixiali-taiji-workflow/credentials.env when direct SwanLab access is required.
• Never put PATs, SwanLab keys, stream tokens, or other secrets in this skill, Git, monitor state, logs, process reports, or final answers.
• Configure the SwanLab credential file with scripts/configure_credentials.py; it writes mode 600 and never echoes the key.

Execution rules

• Validate names, experiment numbers, paths, source IDs, exact-name absence, and requested resources before a write.
• Use platform facts as authoritative. Local JSON is cache and audit state only.
• Use exact-name lookup for idempotency. A transport error or permission failure is not evidence that a resource is absent.
• Create a callable deployment: inference, same-name service group bound to it, ready replicas, then one minimal service-group chat probe.
• Deploy an A20B SFT inference only as part of a Yuanbao evaluation, cloning SFT_INFERENCE_SOURCE at SFT_EVAL_REPLICAS replicas, and release it to 0 once the evaluation is audited. Do not stand one up for other reasons. See sft-export-and-yuanbao.md.
• After an SFT run reaches SUCCEED, publish the last step, convert mcore→HF, then submit both Yuanbao evaluations by default. State this chain when submitting the training so one confirmation covers it; honor an explicit opt-out.
• Keep checkpoint deletion disabled unless the user explicitly authorizes it for one task. Never delete evaluated or target checkpoints.
• For 完整汇报, run scripts/live_active_report.py; it restores missing registered monitors before rendering unless explicitly disabled.

Reusable scripts

• clone_training.py: prepare, clone, verify, and normally start an RL or SFT task.
• register_monitor.py: create an RL monitor config, register it, and optionally launch it.
• monitor_training_to_eval.py: reconcile one RL task through model, deployment, evaluation, audit, export, and release.
• deploy_from_reference.py: exact-reference deployment helper with preflight and post-create validation.
• export_eval_metrics.py: update one stable {run_name}_eval_metrics.xlsx workbook.
• restore_active_monitors.py: restore missing active monitor processes.
• live_active_report.py: render the standard progress table and anomalies.

Run scripts yourself when performing the workflow; do not hand commands to the user unless they ask for commands or a reproducible handoff.