Uber
值班工程支持与内部知识问答 Genie
企业原始材料
出行平台/软件
企业部署案例
⚙ 技术方案
深度案例｜关键链路较完整
A级证据
生产使用/持续评测
A
证据等级
Genie: Uber’s Gen AI On-Call Copilot
证据等级衡量“能否定位和复核来源”，不评价厂商披露是否经过第三方审计。
深度案例｜关键链路较完整
11 / 12
业务背景2 / 2
改造流程2 / 2
技术工作流2 / 2
人机与治理2 / 2
量化结果1 / 2
来源定位2 / 2
仍可补强：量化结果
业务问题
Uber各平台团队每月在数百个Slack支持频道提出约4.5万个问题，答案散落在内部Engwiki、Stack Overflow、工程需求文档和历史对话中；重复问答和多轮等待同时消耗提问者与值班工程师时间。
解决方案
Uber自研Genie，把内部资料经Spark抓取、LangChain切块和OpenAI Embedding转为向量，通过Sia与Terrablob构建受频道权限约束的索引；用户在Slack提问后，Knowledge Service检索相关片段并让LLM基于证据回答，同时记录成本、即时反馈和离线评测结果。
技术架构与生产工作流
Step 01
Engwiki、内部Stack Overflow与工程需求文档
→
Step 02
Spark抓取、LangChain切块与PySpark UDF批处理
→
Step 03
OpenAI Embedding生成文档和问题向量
→
Step 04
Sia向量数据库与Terrablob索引分发
→
Step 05
Slack请求进入Knowledge Service检索并调用LLM
→
Step 06
频道级权限、UUID成本审计、Kafka/Hive反馈与LLM-as-a-judge评测
关键技术与基础设施组件
SlackApache SparkLangChainOpenAI EmbeddingSia向量数据库TerrablobMichelangelo GatewayKafka/Hive
人机分工与责任边界
Genie先处理已有文档可回答的问题；需要代码审查、上下文不足或回答无关时转给值班工程师。用户以Resolved、Helpful等标签反馈，平台团队用人工反馈和评测报告继续调整检索与生成。
FDE 动作拆解
- 统计支持频道问题量和重复问答来源
- 比较微调与RAG后选择更快上线的RAG
- 按Slack频道映射知识空间访问权限
- 为每次请求传递UUID并按请求核算模型成本
- 把用户反馈流入Hive并用Michelangelo评测检索与生成
可迁移复用的落地方法论
- 内部知识助手必须继承原知识空间权限
- 支持机器人要明确哪些请求直接转人工
- 成本、用户反馈和离线质量评测应使用同一请求标识关联
- RAG组件需要分别评估召回与生成而不是只看最终答案
业务成效与交付成果
Genie已进入Uber内部支持流程并建立可追踪的反馈、成本与幻觉评测闭环；公开工程文章披露了问题规模和完整架构，但没有披露解决率、节省工时或投资回报。
证据边界与核验记录
- 每月约4.5万个问题是需求基线，不是Genie处理量。
- 文章未给上线后的解决率、响应时间或节省工时，不据此推算ROI。