[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-82227":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":8,"htmlUrl":8,"language":9,"languages":8,"totalLinesOfCode":8,"stars":10,"forks":11,"watchers":12,"openIssues":13,"contributorsCount":13,"subscribersCount":13,"size":13,"stars1d":14,"stars7d":15,"stars30d":16,"stars90d":13,"forks30d":13,"starsTrendScore":17,"compositeScore":18,"rankGlobal":8,"rankLanguage":8,"license":19,"archived":20,"fork":20,"defaultBranch":21,"hasWiki":22,"hasPages":20,"topics":23,"createdAt":8,"pushedAt":8,"updatedAt":24,"readmeContent":25,"aiSummary":26,"trendingCount":13,"starSnapshotCount":13,"syncStatus":12,"lastSyncTime":27,"discoverSource":28},82227,"alpamayo-coc-autolabeler","NVlabs\u002Falpamayo-coc-autolabeler","NVlabs",null,"Python",78,3,2,0,1,13,41,7,1.81,"Apache License 2.0",false,"main",true,[],"2026-06-12 02:04:24","# Chain-of-Causation (CoC) Autolabeling Pipeline\n\nThis repository provides an autolabeling pipeline for autonomous-driving\nscenarios. It derives meta-actions, which are high-level categorical\ndescriptions of ego motion, and chain-of-causation labels, which connect causal\nfactors in the scene to the ego vehicle's intended behavior.\n\n## Table of Contents\n\n- [Workflow Overview](#workflow-overview)\n- [Paper](#paper)\n- [Runtime Requirements](#runtime-requirements)\n  - [Validated Configurations](#validated-configurations)\n- [Dependencies (Build Image from Dockerfile)](#dependencies-build-image-from-dockerfile)\n- [Prepare the Data (Physical-AI AV Dataset)](#prepare-the-data-physical-ai-av-dataset)\n  - [Step 1: Generate Meta-Actions](#step-1-generate-meta-actions)\n  - [Step 2: Identify Keyframes](#step-2-identify-keyframes)\n- [Run CoC Autolabeling](#run-coc-autolabeling)\n  - [Step 3: Generate CoC Labels](#step-3-generate-coc-labels)\n  - [Output Structure](#output-structure)\n- [Troubleshooting](#troubleshooting)\n  - [1. vLLM Import Fails With `libtorch_cuda.so`](#1-vllm-import-fails-with-libtorch_cudaso)\n  - [2. Local Qwen Fails With Unsupported CUDA\u002FPTX](#2-local-qwen-fails-with-unsupported-cudaptx)\n  - [3. Cloud GPT Request Fails With `invalid_request_error`](#3-cloud-gpt-request-fails-with-invalid_request_error)\n- [Extend with Other Model Clients](#extend-with-other-model-clients)\n  - [1) Add or reuse a wrapper class](#1-add-or-reuse-a-wrapper-class)\n  - [2) Register the model key in the wrapper factory](#2-register-the-model-key-in-the-wrapper-factory)\n  - [3) (Optional) Export the wrapper in package init](#3-optional-export-the-wrapper-in-package-init)\n  - [4) Add or update runtime configs](#4-add-or-update-runtime-configs)\n  - [5) Validate with a smoke run](#5-validate-with-a-smoke-run)\n- [Disclaimer](#disclaimer)\n- [License](#license)\n- [Citation](#citation)\n\n## Workflow Overview\n\n1. **Step 1: Generate Meta-Actions**: produce per-clip high-level motion labels\n   from trajectory data.\n2. **Step 2: Identify Keyframes**: select frames where ego meta-actions change,\n   since these transitions are likely to contain decision-making context.\n3. **Step 3: Generate CoC Labels**: run the VLM pipeline on selected keyframes\n   to produce chain-of-causation labels.\n\n## Paper\n\nThis autolabeling pipeline is related to the Chain-of-Causation reasoning\npipeline described in\n[Alpamayo-R1: Bridging Reasoning and Action Prediction for Generalizable\nAutonomous Driving in the Long Tail](https:\u002F\u002Farxiv.org\u002Fabs\u002F2511.00088).\n\n## Runtime Requirements\n\nThe minimum hardware requirement depends on the model backend and dataset size.\nGPU is not required when CoC labels are generated with a hosted model API such\nas `gpt5` or `gpt5.5`; in that setup, local compute is mainly used for data\nloading, meta-action generation, keyframe selection, and video extraction.\n\nLocal Qwen inference requires GPU capacity sufficient for the selected Qwen\nmodel. The released Qwen model examples have been tested on NVIDIA A100 and\nH100 GPUs with the CUDA 12.8 Docker image; other GPU setups may work depending\non the selected Qwen model, available VRAM, batch size, driver compatibility,\nand worker settings. CPU and host-memory usage also scale with the number of\nworkers used for trajectory-data caching and meta-action labeling.\n\n### Validated Configurations\n\nUse `nvidia-smi` on the host to confirm the NVIDIA driver before running local\nQwen inference. The Docker image uses CUDA 12.8 and vLLM 0.17.1.\n\n| GPU generation | Example GPUs | Minimum host NVIDIA driver | Validation status |\n| -------------- | ------------ | -------------------------- | ----------------- |\n| Ampere         | A100         | `>=535`                    | Tested            |\n| Hopper         | H100         | `>=545`                    | Tested            |\n\nFor a small smoke test of about 100 clips with hosted model API for CoC\ngeneration, the following setup is sufficient:\n\n- 8 CPU cores\n- 8 GB memory\n- no GPU, unless running a local Qwen model\n\n## Dependencies (Build Image from Dockerfile)\n\nA standalone image can be built from this repository's `Dockerfile`.\n\nBuild:\n\n```bash\ndocker build -t coc_auto_labeling:latest .\n```\n\nRun:\n\n```bash\ndocker run --gpus all -it --ipc=host \\\n  -v path\u002Fto\u002Fcoc_label_oss:\u002Fworkspace\u002Fcoc_auto_labeling \\\n  coc_auto_labeling:latest\n```\n\nThe default in-container project path is `\u002Fworkspace\u002Fcoc_auto_labeling`.\n\nFor local Qwen inference, verify the vLLM import before starting a labeling\nrun:\n\n```bash\ndocker run --gpus all coc_auto_labeling:latest \\\n  python -c 'from vllm import LLM; print(\"ok\")'\n```\n\n## Prepare the Data (Physical-AI AV Dataset)\n\nTo standardize trajectory data formats and support reindexing and\ninterpolation, this pipeline leverages\n[trajdata](https:\u002F\u002Fgithub.com\u002FNVlabs\u002Ftrajdata) for data formatting under the\nhood.\n\nDownload the Physical-AI AV dataset once from\n`https:\u002F\u002Fhuggingface.co\u002Fdatasets\u002Fnvidia\u002FPhysicalAI-Autonomous-Vehicles\u002Ftree\u002Fmain`.\nThe same dataset root is used for meta-action labeling, keyframe selection,\nvideo extraction, and CoC labeling.\n\n### Step 1: Generate Meta-Actions\n\nRun meta-action autolabeling to produce per-clip ego-motion labels:\n\n```bash\nmeta-action-autolabel \\\n  --dataset_name pai \\\n  --meta_action_names all_ego \\\n  --data_dir \u002Fpath\u002Fto\u002Fphysical_ai_data \\\n  --cache_dir \u002Fpath\u002Fto\u002Ftrajdata_cache \\\n  --save_dir \u002Fpath\u002Fto\u002Fmeta_action\u002Fresultdir \\\n  --num_workers 8\n```\n\nCommon options:\n\n- `--meta_action_names`: meta-action types to generate. The CLI default is\n  `go_straight`; the example uses `all_ego` to generate the default ego-action\n  set.\n- `--scene_list`: optional path to a text file with one clip ID per line. Use\n  this for small subset or sample-eval runs.\n- `--num_workers`: worker count for data loading and clip processing. The CLI\n  default is `32`; the example uses `8` as a conservative sample-run setting.\n\nKey outputs:\n\n- `--cache_dir`: formatted trajectory data cache.\n- `--save_dir`: final per-clip meta-action text outputs. Use\n  this path as `meta_action_dir` in later steps, for example\n  `\u002Fpath\u002Fto\u002Fmeta_action\u002Fresultdir\u002Ffinal_outputs`.\n\nFor details on running meta-action autolabeling, including dataset input\nlayout, output format, worker guidance, and visualization commands, see\n[`docs\u002Fmeta_action_autolabel.md`](docs\u002Fmeta_action_autolabel.md).\n\n### Step 2: Identify Keyframes\n\nUse meta-action transitions to generate relative keyframe timestamps:\n\n```bash\npython -m coc_labeling.keyframe_auto_select \\\n  --meta_action_dir \u002Fpath\u002Fto\u002Fmeta_action\u002Fresultdir\u002Ffinal_outputs \\\n  --output_dir .\u002Fexperiments\u002Fkeyframes\n```\n\nArguments:\n\n- `--meta_action_dir`: folder containing meta-action text outputs from Step 1.\n  This should point to the `final_outputs` directory.\n- `--min_duration`: minimum action span duration in frames. The default is\n  `10`, which keeps brief maneuvers such as short strong-deceleration events in\n  sample-eval runs.\n- `--target_count`: maximum number of segments to keep per action type after\n  balancing. The default is `500000` for large-scale experiments, so small\n  samples usually keep every matching segment.\n- `--output_dir`: folder where the generated keyframe index files are written.\n\nThis script automatically generates relative keyframe timestamps from\nmeta-action outputs by selecting frames where ego meta-actions change, as these\ntransitions are more likely to indicate ego decision-making moments.\n\nThe output keyframes will be stored at:\n\n`.\u002Fexperiments\u002Fkeyframes\u002Fsegments_relative_timestamp_sampled.json`\n\nThe structure is:\n\n```json\n{\n  \"\u003Cmeta_action_1>\": [\n    {\n      \"meta_action\": \"\u003Cmeta_action_1>\",\n      \"clip_id\": \"\u003Cclip_uuid>\",\n      \"event_start_frame\": \u003Cstart_frame_index>,\n      \"event_end_frame\": \u003Cend_frame_index>,\n      \"duration\": \u003Cnum_frames>\n    },\n    \"... additional entries ...\"\n  ],\n  \"\u003Cmeta_action_2>\": [\n    {\n      \"meta_action\": \"\u003Cmeta_action_2>\",\n      \"clip_id\": \"\u003Cclip_uuid>\",\n      \"event_start_frame\": \u003Cstart_frame_index>,\n      \"event_end_frame\": \u003Cend_frame_index>,\n      \"duration\": \u003Cnum_frames>\n    }\n  ],\n  \"... additional meta_action keys ...\": [\n    \"... additional entries ...\"\n  ]\n}\n```\n\n## Run CoC Autolabeling\n\n### Step 3: Generate CoC Labels\n\nBefore running CoC labeling, confirm the following inputs. Configure dataset\npaths in `src\u002Fcoc_labeling\u002Fconfig\u002Fdata\u002Fbase.yaml`.\n\n1. `data_dir`: root folder that contains parquet clip data, for example, `\u002Fpath\u002Fto\u002Fphysical_ai_data`\n2. `cache_dir`: formatted trajectory data cache.\n3. `meta_action_dir`: meta-action outputs, for example:\n   `\u002Fpath\u002Fto\u002Fmeta_action\u002Ffinal_outputs`\n4. Keyframe input: the `segment_config_path` can be set in the config `src\u002Fcoc_labeling\u002Fconfig\u002Fdata\u002Fkeyframe_rel_ts.yaml`,\n   the `segment_generator_type` and `meta_action_filter` can be set in the config `src\u002Fcoc_labeling\u002Fconfig\u002Fbase_config_vlm_rel_ts.yaml`.\n5. `video_dir`: root folder that contains a `camera` subfolder for raw AV videos, for example:\n   `\u002Fpath\u002Fto\u002Fextracted_pai_videos`\n\nIf `video_dir` is not already populated, you can extract only the clips\nreferenced by your keyframe\u002Findex JSON. Set `EXTRACTED_VIDEO_ROOT` to the path\nyou want to use for `video_dir`; the extracted MP4 files will be saved under\nits `camera` subfolder. `VIDEO_ZIP_DIR` should point to the folder containing\nthe PAI camera chunk zips, for example `camera_front_wide_120fov.chunk_0000.zip`,\n`camera_front_wide_120fov.chunk_0001.zip`, and so on.\n\n```bash\nexport SEGMENT_INDEX=.\u002Fexperiments\u002Fkeyframes\u002Fsegments_relative_timestamp_sampled.json\nexport VIDEO_ZIP_DIR=\u002Fpath\u002Fto\u002Fphysical_ai_data\u002Fcamera\u002Fcamera_front_wide_120fov\nexport EXTRACTED_VIDEO_ROOT=\u002Fpath\u002Fto\u002Fextracted_pai_videos\n\npython scripts\u002Fextract_pai_videos_from_index.py \\\n  --index-file \"${SEGMENT_INDEX}\" \\\n  --video-zip-dir \"${VIDEO_ZIP_DIR}\" \\\n  --output-video-root \"${EXTRACTED_VIDEO_ROOT}\"\n```\n\nVariables and arguments:\n\n- `SEGMENT_INDEX`: keyframe\u002Findex JSON generated in the previous step.\n- `VIDEO_ZIP_DIR`: folder containing the PAI camera chunk zip files.\n- `EXTRACTED_VIDEO_ROOT`: output root used later as `video_dir`.\n- `--index-file`: path to the keyframe\u002Findex JSON that lists clips to extract.\n- `--video-zip-dir`: path to the source camera zip folder.\n- `--output-video-root`: root directory where extracted videos are written under\n  a `camera` subfolder.\n- `--meta-action-filter`: optional filter that extracts only clips matching the\n  requested meta-action type.\n\nWithout `--meta-action-filter`, the script extracts all clips referenced by the\nindex file. If your run uses a meta-action filter, pass the same filter to the\nextraction script, for example `--meta-action-filter go_straight`.\n\nExample video structure:\n\n```text\n\u002Fpath\u002Fto\u002Fextracted_pai_videos\u002Fcamera\n├── 01d55181-c15d-49f2-8b52-0ddf141375d0.camera_front_wide_120fov.mp4\n├── 5b530101-f63b-4c61-aeac-178ad1626774.camera_front_wide_120fov.mp4\n└── ...\n```\n\nThe released framework currently supports a VLM labeling agent.\n\nSupported `model_name` values in the current release:\n\n- `qwen3_vl_235b_awq`\n- `qwen3.5_35b`\n- `qwen3.5_397b_fp8`\n- `gpt5`\n- `gpt5.5`\n\nFor label quality, the recommended `model_name` values are `gpt5.5` and\n`qwen3.5_397b_fp8`. For local-only runs, start with `qwen3.5_397b_fp8` when\nthe machine has enough GPU memory; otherwise use `qwen3.5_35b`. Use\n`qwen3.5_35b` for local smoke tests because it is faster to download and load\nthan the larger local Qwen variants.\n\nFor Qwen models, authenticate with Hugging Face:\n\n```bash\nexport HF_TOKEN=\"hf_yourtoken\"\nhf auth login --token \"$HF_TOKEN\"\n```\n\nThis is required because the Qwen models are hosted on Hugging Face. `HF_TOKEN`\nis your Hugging Face access token, and `--token` passes it to the login command.\n\nFor `gpt5` or `gpt5.5`, configure one of the following credential sets.\n\nStandard OpenAI API credentials:\n\n```bash\nexport OPENAI_API_KEY=\"sk-your-openai-api-key\"\n```\n\nNVIDIA inference credentials from inference.nvidia.com\u002Fbuild.nvidia.com:\n\n```bash\nexport NVIDIA_API_KEY=\"nvapi-your-nvidia-api-key\"\n```\n\nNVIDIA-hosted Azure OpenAI credentials:\n\n```bash\nexport NVHOST_OAI_CLIENT_ID=\"your_client_id\"\nexport NVHOST_OAI_CLIENT_SECRET=\"your_client_secret\"\n```\n\nCredential precedence is NVIDIA-hosted Azure OpenAI first, then NVIDIA\ninference, then standard OpenAI.\n\nFor Hugging Face local cache, optionally set:\n\n```bash\nexport MODEL_CACHE_DIR=\u002Fpath\u002Fto\u002Fhf-cache   #examples, \u002Fworkspace\u002Fhf-cache\n# or\nexport HF_HOME=\u002Fpath\u002Fto\u002Fhf-cache\n```\n\nRun CoC autolabeling. For example:\n\n```bash\nexport MODEL_CACHE_DIR=\u002Fworkspace\u002Fhf-cache\npython -m coc_labeling.data_labeling \\\n  --config-name=base_config_vlm_rel_ts \\\n  model_name=qwen3.5_35b \\\n  resume_exp_dir=null \\\n  exp_name=qwen3.5_35b_test \\\n  data_loader.keyframe.meta_action_filter='[go_straight]' \\\n  data_loader.video.save_segment_videos=false\n```\n\nVariables and arguments:\n\n- `MODEL_CACHE_DIR`: local Hugging Face model cache used by local Qwen model\n  loading.\n- `--config-name`: Hydra config preset. `base_config_vlm_rel_ts` runs VLM\n  labeling with relative keyframe timestamps.\n- `model_name`: model backend to use for CoC generation. Use one of the\n  supported `model_name` values listed above.\n- `vlm_agent.temperature`, `vlm_agent.top_p`, `vlm_agent.repetition_penalty`:\n  local Qwen sampling parameters. Defaults are `0.0`, `1.0`, and `1.0`.\n- `resume_exp_dir`: existing experiment directory to resume from. Use `null` to\n  create a new experiment directory.\n- `exp_name`: readable suffix for the output experiment folder.\n- `data_loader.keyframe.meta_action_filter`: list of meta-action types to label.\n  Use `null` to include all available meta-action types.\n- `data_loader.video.save_segment_videos`: whether to save extracted segment\n  videos alongside CoC outputs.\n\nYou can configure `meta_action_filter`, `save_segment_videos`, `model_name`, and related settings in:\n`src\u002Fcoc_labeling\u002Fconfig\u002Fbase_config_vlm_rel_ts.yaml`\n\nMore examples for running CoC autolabeling.\n\n```bash\npython -m coc_labeling.data_labeling \\\n  --config-name=base_config_vlm_rel_ts \\\n  model_name=qwen3.5_397b_fp8 \\\n  resume_exp_dir=null \\\n  exp_name=qwen3.5_397b_fp8_test \\\n  data_loader.keyframe.meta_action_filter=null \\\n  data_loader.video.save_segment_videos=false\n```\n\nThis example uses the same arguments as above. It switches to\n`qwen3.5_397b_fp8` and sets `data_loader.keyframe.meta_action_filter=null` to\nprocess all available meta-action types.\n\nFor local model inference, if you run into out-of-memory errors, use a GPU or\nmachine with more available GPU memory, or reduce parallelism.\n\n### Output Structure\n\nExperiment outputs are written under:\n\n```text\npath\u002Fto\u002Fcoc_label_oss\u002Fexperiments\u002F\u003Crun_id>_\u003Cexp_name>\u002F\n```\n\nExample:\n\n```text\npath\u002Fto\u002Fcoc_label_oss\u002Fexperiments\u002F20260308_002355_qwen3.5_35b_test\n├── b6700354-ab89-45ec-8b47-7d6dbfe16b1a\u002F\n│   ├── cot_12600000.yaml\n│   ├── ...\n└── ...\n```\n\n`cot_\u003Ckeyframe_timestamp>.yaml` uses the keyframe timestamp in the filename.\nIn this example, `12600000` is the keyframe's relative timestamp.\n\nInside each YAML file, the `results` structure looks like:\n\n```yaml\nresults:\n  event_start_frame: 126\n  event_start_timestamp: 12600000\n  final_content:\n    ego_behavior_schema:\n      effect_on_ego_behavior: \"Keep distance to the lead vehicle by decelerating.\"\n  # prompt: [...]  # full model input (system\u002Fuser text + sampled video frame references)\n```\n\nField meanings:\n\n- `event_start_timestamp`: relative keyframe timestamp in microseconds (also used in `cot_\u003Ctimestamp>.yaml` filename).\n- `event_start_frame`: relative frame index in the sampled clip timeline. With default `10` FPS, `126` means `12.6s`.\n- `final_content`: model output payload.\n- `final_content.ego_behavior_schema.effect_on_ego_behavior`: free-form CoC text.\n\nIf `data_loader.video.save_segment_videos` is set to true, the segment videos are saved under:\n`experiments\u002Fvideo_segment` folder by default.\n\n## Troubleshooting\n\n### 1. vLLM Import Fails With `libtorch_cuda.so`\n\nPyTorch likely resolved to a CPU wheel, or the image was built without the CUDA\n12.8 wheel index. Rebuild from this Dockerfile and run:\n\n```bash\ndocker run --gpus all coc_auto_labeling:latest \\\n  python -c 'from vllm import LLM; print(\"ok\")'\n```\n\n### 2. Local Qwen Fails With Unsupported CUDA\u002FPTX\n\nIf local Qwen loading fails with `cudaErrorUnsupportedPtxVersion` or another\nCUDA\u002FPTX compatibility error, check the host NVIDIA driver with `nvidia-smi`.\nThe Docker image uses CUDA 12.8 and vLLM 0.17.1, so the host driver must satisfy\nthe validated configuration table above.\n\n### 3. Cloud GPT Request Fails With `invalid_request_error`\n\nThe hosted GPT endpoint may reject explicit sampling parameters. Use the\ncurrent wrapper defaults for `gpt5` or `gpt5.5`; sampling overrides documented\nin this README are for local Qwen. Non-retryable 4xx errors fail fast.\n\n## Extend with Other Model Clients\n\nUse this section to add new model clients beyond built-in options (for example,\nfuture Qwen variants or other VLM providers).\n\n### 1) Add or reuse a wrapper class\n\nIf the new model uses a provider flow that is already implemented, reuse the\nexisting wrapper. For example, new Qwen aliases should use `QwenWrapper`, and\nnew OpenAI-compatible aliases should use `OpenAIWrapper`.\n\nIf the new provider needs different request or response handling, create a\nwrapper under:\n\n- `src\u002Fcoc_labeling\u002Fmodel_clients\u002Fvlm_wrappers\u002F`\n\nYour wrapper should implement the same interface used by existing wrappers:\n\n- `infer(...)`\n- `add_message(...)`\n\nSee `qwen.py`, `cloud.py`, and `dummy.py` as reference implementations.\n\n### 2) Register the model key in the wrapper factory\n\nEdit:\n\n- `src\u002Fcoc_labeling\u002Fmodel_clients\u002Fvlm_wrappers\u002Ffactory.py`\n\nImport the wrapper class if it is new, then add your model key to\n`MODEL_WRAPPER_REGISTRY`, mapping to the wrapper class. This key is the value\npassed via `model_name=...` when launching\n`coc_labeling.data_labeling`.\n\nFor a new Qwen model alias, also add its cache folder, Hugging Face model ID,\nand quantization setting to `QWEN_MODEL_SPECS` in `qwen.py`.\n\nFor a new OpenAI-compatible alias, also update `model_name_map` in `cloud.py`\nwhen the public `model_name` key should map to a different provider model ID.\n\n### 3) (Optional) Export the wrapper in package init\n\nIf you want public import coverage from the wrapper package, update:\n\n- `src\u002Fcoc_labeling\u002Fmodel_clients\u002Fvlm_wrappers\u002F__init__.py`\n\n### 4) Add or update runtime configs\n\nUpdate default configs if you want the new model as a runnable preset:\n\n- `src\u002Fcoc_labeling\u002Fconfig\u002Fbase_config_vlm.yaml`\n- `src\u002Fcoc_labeling\u002Fconfig\u002Fbase_config_vlm_rel_ts.yaml`\n\n### 5) Validate with a smoke run\n\nRun a short test on a small clip subset:\n\n```bash\npython -m coc_labeling.data_labeling \\\n  --config-name=base_config_vlm_rel_ts \\\n  model_name=\u003Cyour_model_key> \\\n  resume_exp_dir=null \\\n  exp_name=smoke_\u003Cyour_model_key>\n```\n\nUse the same CoC labeling arguments described above. Replace\n`\u003Cyour_model_key>` with the model registry key you added, and set `exp_name` to\na short name that identifies the smoke run.\n\nIf your wrapper loads local model weights, make sure cache folder names and Hugging\nFace model IDs are both correctly mapped in the wrapper implementation.\n\n## Disclaimer\n\nThis autolabeling tool is provided for research and development in the autonomous vehicle (AV) domain. It is intended as a foundation and a starting point for building custom VLA applications and is not a production-ready system.\n\nBecause this pipeline relies on VLMs, generated CoC outputs may contain errors, including incorrect maneuver attribution (for example, right vs. left lane change), hallucinated objects, or inaccurate temporal-causal reasoning about surrounding agents and ego behavior.\n\nTo improve the CoC quality, use human auditing and\u002For a hybrid post-processing workflow that combines review with heuristic checks. Example safeguards include but are not limited to validating outputs against object-detection signals (for example, lead-vehicle or pedestrian presence), planner\u002Fbehavior signals (for example, nudging or yielding), and human correction loops. These safeguards are outside the scope of the current release.\n\nBy using this tool, you acknowledge that it is intended to support scientific inquiry, benchmarking, and exploration, and is not a substitute for a validated or certified AV stack. Developers and contributors disclaim responsibility and liability for use of the model and its outputs.\n\n## License\n\nThis project is licensed under the [Apache-2.0](.\u002FLICENSE) License.\n\n## Citation\n\nIf you use this autolabeling pipeline in your research, please cite:\n\n```bibtex\n@article{nvidia2025alpamayo,\n      title={{Alpamayo 1}: Bridging Reasoning and Action Prediction for Generalizable Autonomous Driving in the Long Tail},\n      author={NVIDIA and Yan Wang and Wenjie Luo and Junjie Bai and Yulong Cao and Tong Che and Ke Chen and Yuxiao Chen and Jenna Diamond and Yifan Ding and Wenhao Ding and Liang Feng and Greg Heinrich and Jack Huang and Peter Karkus and Boyi Li and Pinyi Li and Tsung-Yi Lin and Dongran Liu and Ming-Yu Liu and Langechuan Liu and Zhijian Liu and Jason Lu and Yunxiang Mao and Pavlo Molchanov and Lindsey Pavao and Zhenghao Peng and Mike Ranzinger and Ed Schmerling and Shida Shen and Yunfei Shi and Sarah Tariq and Ran Tian and Tilman Wekel and Xinshuo Weng and Tianjun Xiao and Eric Yang and Xiaodong Yang and Yurong You and Xiaohui Zeng and Wenyuan Zhang and Boris Ivanovic and Marco Pavone},\n      year={2025},\n      journal={arXiv preprint arXiv:2511.00088},\n}\n```\n","该项目提供了一个针对自动驾驶场景的自动标注流水线，能够生成元动作和因果链标签。其核心功能包括从轨迹数据中提取高层面的动作描述（即元动作），识别关键帧，并在此基础上生成因果链标签，从而连接场景中的因果因素与车辆预期行为。技术上，项目支持通过Docker构建依赖环境，并且提供了基于物理AI AV数据集的数据准备步骤。此外，该系统设计灵活，允许用户扩展以使用其他模型客户端。适用于需要对自动驾驶数据进行详细标注的研究或开发场景，特别是在探索驾驶决策背后的因果关系时。","2026-06-11 04:08:07","CREATED_QUERY"]