Shreyagosavi811/ARENAINTEL

# ARENAINTEL 🏟️🤖 ## Arena 智能平台 ## 1. 问题与解决方案 在 FIFA 世界杯等大型赛事期间，体育场的运营涉及大量人群、多个运营团队以及快速变化的环境条件。获取相关运营背景信息的延迟会使决策变得更加困难。 ARENAINTEL 是一个由 GenAI 驱动的决策支持平台，旨在帮助体育场和赛事运营人员分析快速变化的情况、检索相关的操作流程、模拟假设场景，并通过人工监督的工作流审查结构化的 AI 建议。 ## 2. 赛题契合度 ARENAINTEL 通过为比赛日的体育场工作人员提供 GenAI 驱动的决策支持层，应对了**智慧体育场与赛事运营**赛题的挑战。 该系统支持： - 使用 GenAI 和检索到的 SOP 背景进行运营情况分析 - 在不更改实时运营状态的情况下进行 What-If 场景模拟 - AI 辅助的事件响应规划 - 对 AI 建议进行人工监督审批 - 面向体育场人员的无障碍操作界面 - 为比赛日运营提供结构化的决策支持 *该应用程序被设计为一个使用合成 SOP 数据和模拟运营输入的演示平台。它并不旨在取代真正的体育场控制系统、紧急服务或授权的人工决策者。* ## 3. 核心功能 - **运营 Copilot**：具备上下文感知的风险评估。 - **What-If 场景模拟器**：用于假设性压力测试的隔离预测沙盒。 - **事件响应 Copilot**：将恐慌的、非结构化的员工报告转化为结构化的应急预案。 ## 4. GenAI Pipeline 主要的应用工作流使用配置好的 Generative AI provider 来分析运营情况并生成结构化的建议。 Pipeline 如下： ``` Operational Observation ↓ Input Validation ↓ TF-IDF Retrieval of Relevant SOP Context ↓ Generative AI Analysis ↓ Structured JSON Response ↓ Pydantic Validation ↓ Human Review ↓ Approve / Reject ``` 在主要的应用工作流中未使用任何模拟的 AI 响应。演示环境使用合成的 SOP 知识和模拟的运营输入。GenAI 的输出被限制在结构化的 schema 中，在返回给前端之前进行验证，并作为咨询性建议而非自主命令呈现。 ## 5. ARENAINTEL 的独特之处 ARENAINTEL 没有将 Generative AI 视为独立的聊天机器人，而是将其置于受控的运营工作流中： - 检索机制使 AI 基于相关的操作流程。 - 结构化的 schema 限制了生成的输出。 - 领域规则强制执行有效的工作流转换。 - 模拟环境与运营状态相互隔离。 - 人工主管负责批准或拒绝建议。 - 审计记录保留了决策历史。 这创建了一个受控的 AI 决策支持循环，而不是一个自主的 AI 控制系统。 ## 6. RAG 方法 系统使用原生的 Python TF-IDF 检索层，为 GenAI provider 提供相关的运营背景信息，随后 provider 会生成结构化的建议。这消除了沉重的向量数据库带来的开销。 ## 7. Human-in-the-Loop 模型 AI 仅作为咨询智能体。它不能执行物理命令。每个生成的运营计划都会进入 `PENDING_REVIEW` 状态，需要人工主管的明确授权才能转换为 `APPROVED` 或 `REJECTED`。 ## 8. 架构 后端严格遵循 Clean Architecture。依赖规则指向内部：API 和 Infrastructure 依赖于 Application 的抽象，而 Application 依赖于 Domain 逻辑。Domain 层保持独立，不依赖于框架、数据库、FastAPI 和特定的 AI provider。 ## 9. 安全方案 - **Prompt 注入防御**：不受信任的输入会被 XML 封装（``），并明确作为数据而非指令处理。 - **资源耗尽防护**：高消耗的 AI endpoint 受到 `slowapi` 速率限制（5 次请求/分钟）的保护。 - **机密管理**：代码库中不提交任何 API 密钥。Provider 凭证保留在服务器端，绝不会暴露给前端。 - **错误净化**：Provider 和后端错误会被映射为安全的面向用户的消息，而不会暴露 stack trace 或机密。 ## 10. 技术栈 - **后端**：FastAPI, Pydantic V2, SQLModel/SQLite, Pytest。 - **前端**：React 18, Vite, TanStack Query, Vanilla CSS。 ## 11. 项目结构 ``` stadiumops-ai/ ├── backend/ │ ├── app/ │ │ ├── api/ (FastAPI Routers) │ │ ├── application/ (Orchestration) │ │ ├── domain/ (State Machine & Logic) │ │ └── infrastructure/ (AI, DB, RAG) │ └── tests/ └── frontend/ ├── src/ │ ├── features/ (Copilot, Scenarios, Approvals) │ └── components/ (Reusable UI States) └── tests/ ``` ## 12. 设置说明 **前置条件**：Node 18+，Python 3.11+ ``` # 1. Backend 设置 cd backend python -m venv venv # Windows: .\\venv\\Scripts\\activate | Mac: source venv/bin/activate pip install -r requirements.txt cp ../.env.example ../.env # Add your AI Provider API Keys # 2. Frontend 设置 cd ../frontend npm install ``` ## 13. 运行说明 同时运行两个服务器： - **后端**：`cd backend && uvicorn app.main:app --reload`（运行在端口 8000） - **前端**：`cd frontend && npm run dev`（运行在端口 5173） ## 14. 测试说明 - **后端测试**：`cd backend && pytest tests/` - **前端测试**：`cd frontend && npm run test` ## 15. 假设条件 - 体育场遥测数据（占用率、闸机通过速度）目前是为了演示而模拟的。 - SOP 文档构成了一个本地化的运营知识库。 - AI 建议仅供参考，不直接控制物理基础设施。 - 场景模拟不会修改实时状态。 - 人工主管对运营决策承担最终责任。 - AI 输出可能包含不确定性，需要人工审查。 ## 16. 局限性 - 实时传感器集成（IoT）是模拟的。 - 考虑到黑客马拉松的限制，TF-IDF 知识库特意保持轻量级。 - SOP 数据集是合成/演示数据。 - 该系统是一个决策支持工具，不能取代训练有素的急救人员。 ## 17. 仓库大小合规性 提交的代码库已经过验证，保持在 10 MB 的仓库大小限制以下。该项目避免了提交虚拟环境、`node_modules`、构建产物、模型权重、大型媒体文件以及沉重的向量数据库依赖。 在当前的开发快照中，源代码占用空间约为 1 MB。

标签：事件响应规划, 人机协同, 仿真模拟, 决策支持系统, 智慧场馆, 生成式AI, 索引, 运营管理, 逆向工具