【大华秋招开发一面】2022.8.17

在开发 AI 对话应用（如调用豆包、GPT 等 API）时，我们常面临一个核心问题：AI 本身是无状态的，如何让它记得用户的历史对话，且在高并发下依然保持极速响应？ 一、 核心痛点：为什么 AI 需要“记忆”？ 调用大模型 API 时，模型不会自动记录之前的聊天记录。为了实现“多轮对话”，我们必须在每次发送请求时，把历史消息一并传给 API。这就引出了三个挑战：  性能：频繁的数据库查询会拖慢响应速度。 上下文窗口：模型有 Token 上限，不能无限制地堆积历史。 成本：发送的上下文越多，消耗的 Token 越多，费用越高。  二、 四种演进方案深度解析 1. MySQL 单库方案（起步阶段）...

我觉得我经历很丰富啊，为什么在西安只有7k😭

难道前端真的已经不行了？

随着AI的发展，数据人的工作边界，正在发生变化。过去我们更熟悉的是这些词：ETL、数仓分层、指标体系、实时链路、BI 报表。这些能力当然依然重要。而且直到今天，它们还是企业数据建设的基本盘。但现在，很多企业对数据团队的期待，已经不只是：把数据算出来。而是开始进一步要求你去支撑：智能问答/企业搜索/RAG 检索增强/Agent 工具调用这意味着，数据人做的事情，正在从“建数仓”，慢慢走向“建 AI 数据底座”。未来已来，该考虑不是数仓还要不要做？而是从做数仓到做 AI 数据底座，数据人到底该补什么能力？一、不是数仓没用了，而是只会数仓已经不够了先说结论：数仓能力不会过时。因为 AI 数据底座的很...