Spaces:
Sleeping
Sleeping
| # Meta OpenEnv Hackathon β Round 2 Upgrade Documentation | |
| This document serves as the comprehensive completion report and technical walkthrough for the Round 2 upgrade of the `customer-support-env`. | |
| ## 1. Architectural Overhaul: Hierarchical Multi-Agent System | |
| We transitioned the environment from a single-agent RL loop to a robust **3-Level Hierarchical Multi-Agent System**, designed to simulate complex, real-world enterprise customer support workflows. | |
| The environment now dynamically manages states and role transitions between three distinct agent levels: | |
| 1. **Level 1: Support Agent** | |
| - **Role**: Front-line interaction, gathers information, provides initial responses. | |
| - **Actions**: `respond`, `request_info`, `close`, `escalate` (to L2). | |
| 2. **Level 2: Supervisor** | |
| - **Role**: Oversight, QA, policy enforcement, and coaching. Reviews every L1 action before it reaches the customer. | |
| - **Actions**: `supervisor_approve`, `supervisor_reject`, `supervisor_feedback` (sends back to L1), `supervisor_escalate` (to L3). | |
| 3. **Level 3: Manager** | |
| - **Role**: Executive escalation, conflict resolution, policy overriding. | |
| - **Actions**: `manager_override`, `manager_resolve`, `manager_send_back`. | |
| This is implemented via the new `HierarchicalCustomerSupportEnv` class, utilizing a phase-based state machine (`HierarchyState`) that routes actions and transitions seamlessly. Crucially, the environment maintains **100% backward compatibility** with Round 1 single-agent tasks. | |
| ## 2. Core Feature Additions | |
| ### LLM-Driven Customer Simulator & Hinglish Degradation | |
| - **File**: `env/customer_simulator.py` | |
| - Replaced deterministic customer logic with a dynamic LLM-driven simulator. | |
| - Tracks `frustration_level` based on agent interactions. | |
| - **Hinglish Degradation**: If frustration exceeds `0.6`, the customer simulator begins degrading its language into Hinglish, simulating real-world agitated Indian enterprise customers. | |
| ### Hybrid Reward Engine & LLM-as-a-Judge | |
| - **Files**: `env/reward_engine.py`, `env/llm_judge.py` | |
| - Eliminated gamable, purely deterministic rewards. | |
| - Implemented an asynchronous LLM-as-a-Judge module evaluating 5 specific rubrics: `empathy`, `resolution`, `policy_adherence`, `oversight_quality`, and `decision_quality`. | |
| - **Role-Specific Rewards**: The engine now issues isolated scores for `support_agent`, `supervisor`, and `manager`, enabling targeted RL updates (e.g., GRPO) per role. | |
| - **Anti-Gaming Penalties**: Strict deductions for hallucinated policies, ignored supervisor feedback, and repetitive loops. | |
| ### Dynamic Policy Drift Engine | |
| - **File**: `env/policy_engine.py` | |
| - Introduces mid-episode "schema drift" to test agent adaptability. | |
| - Example: The system might inject an `ENVIRONMENT EVENT: Refund portal is down` at step 3, forcing the Supervisor to reject a Support Agent's attempt to issue a refund and demanding an alternative solution. | |
| ### Indian Enterprise Dataset | |
| - **File**: `env/ticket_store.py` | |
| - Added 6 high-complexity, hierarchical tickets focused on the Indian Enterprise context (UPI failures, Big Billion Days timeouts, KYC rejections, SLA breaches). | |
| ### Hierarchy Graders | |
| - **Files**: `env/graders/task_hierarchy_easy.py`, `medium.py`, `hard.py` | |
| - Developed 3 new graders explicitly designed to evaluate the multi-agent interaction flow, ensuring L2s actually review and L3s actually resolve critical paths. | |
| ## 3. Workflow & Integration | |
| ### Server Routing | |
| - **File**: `server/app.py` | |
| - The FastAPI server was upgraded to auto-detect task requests. Requests starting with `hierarchy_*` are routed to the `HierarchicalCustomerSupportEnv`, while standard tasks use `CustomerSupportEnv`. | |
| ### Inference Loop | |
| - **File**: `inference.py` | |
| - The inference script was entirely rewritten to support dynamic role switching. | |
| - It parses the `active_role` from the observation state and injects role-specific system prompts (Support Agent vs. Supervisor vs. Manager) containing contextual data like `supervisor_feedback` and `manager_directives`. | |
| - Retains API key failover logic using NVIDIA NIM endpoints. | |
| ### API Specification | |
| - **File**: `openenv.yaml` | |
| - Bumped version to `2.0.0`. | |
| - Added 3 new hierarchy tasks and expanded the action/observation space to include fields like `active_role`, `supervisor_feedback`, and `policy_context`. | |
| ## 4. Testing & Results | |
| The entire system is successfully dockerized and validated. | |
| ### Test Suite Execution | |
| - Wrote extensive `pytest` test cases covering session isolation, LLM-as-a-judge boundaries, hierarchy phase transitions, and end-to-end API flows. | |
| - **Result**: `50/50 tests passed` in 3.71s within the Docker container. | |
| ### Live Endpoint Verification | |
| - Started the `meta_hack-env` Docker container and ran a live `test_live.py` validation script. | |
| - **Single-Agent Backward Compatibility**: Verified `easy` and `hard` tasks complete properly. | |
| - **Hierarchy Easy Flow**: Verified `L1 respond` β `L2 approve` β `L1 close` β `L2 approve`. | |
| - **Hierarchy Hard Flow**: Verified `L1 respond` β `L2 escalate` β `L3 resolve`. | |
| - **Role Rewards Verification**: Confirmed JSON output parses correct dense role-rewards (e.g., `{'support_agent': 0.425, 'supervisor': 0.725, 'manager': 0.65}`). | |
| ## 5. Next Steps | |
| With the environment, endpoints, and inference architecture fully deployed and validated on the `feat/round2` branch, the final step for Hackathon readiness is: | |
| 1. **Training Pipeline**: Develop the `train_grpo.py` script utilizing Unsloth / TRL to consume the new `role_rewards` dictionaries and fine-tune models to operate efficiently within this hierarchical structure. | |