customer-support-env / docs /walkthrough.md
lebiraja's picture
docs: reorganize .md files into docs/ and rewrite README for Round 2
a8f3713
|
Raw
History Blame Contribute Delete
5.62 kB
# 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.