如果说过去两年我在电商数据分析这一块做得最多的事情不是写SQL也不是调模型而是处理一类很隐蔽的“需求膨胀”业务方越来越不满足于“看一个报表”他们想要直接问系统“为什么最近三天下单转化率掉了5个点高价值用户主要流失在哪个环节以前我们做过什么类似动作”这种问题背后既要有实时的行为事实又要有历史业务知识的沉淀还得有一套能自主拆解任务的逻辑缺一不可。我尝试过纯BI方案接不住这种自然语言交互也试过纯大模型问答模型一本正经胡说八道的概率高得吓人。最终跑通了一套组合方案核心就是四个字AI Agent 大数据 RAG。在没有几百万预算、没有专门的算法团队、连服务器都要挤在几台8核16G机器上的情况下把“电商用户行为分析”这个事干成了而且效果远远超出预期。这篇就当是一次完整复盘。从技术选型为什么这么走到数据管道怎么搭、RAG怎么和Agent配合、遇到哪些坑全部展开。适合正在做电商数据分析、用户增长、私域运营或者单纯想在中小团队里低预算落地AI能力的朋友。如果你准备自己搭建这篇可以直接当脚手架用。1. 整体方案设计与技术选型思路1.1 为什么非要把Agent、RAG、大数据绑在一起先说个大背景电商用户行为数据天然是“海量、异构、高维”的。一条完整的用户行为链路可能涉及商品浏览、搜索点击、加购、下单、支付、退款、评价以及客服对话、售后工单里大段大段的非结构化文本。这类数据有两个显著特征一是量级大动辄每天几千万条事件二是结构混杂既有高度结构化的订单表又有评论、对话、问卷这种文本。传统大数据平台能解决“存储和统计”的问题但解决不了“理解和问答”的问题。一个业务负责人问“昨天新客和非新客在加购环节的流失差异大不大”传统BI能拉一张表出来但需要数据分析师先写复杂SQL再人工解读。反过来直接拿大模型去答模型没有底层事实只能靠训练数据里的“常识”瞎猜出了数字没人敢信。这就是需要三者协同的原因大数据层负责“事实”把原始行为日志清洗成标准事件表、聚合指标表提供硬数据。RAG负责“知识”把商家自己的历史分析报告、运营SOP、商品FAQ、过往策略文档向量化让大模型在回答时能参考历史沉淀而不是凭空发明。AI Agent负责“行动”把“查数据”和“检索知识”封装成工具让大模型能自主规划、调用工具、深度推理最后输出可执行的业务结论。这三层缺一个都会出问题没有大数据Agent和RAG都是空中楼阁没有RAGAgent就算能查数也解释不了数值背后的业务含义没有Agent数据和知识是分裂的用户只能二选一。1.2 选型前必须想明白的一个关键问题为谁服务复杂到什么程度做技术选型之前我先问了自己一个问题用户是谁是业务运营还是数据分析师如果目标是数据分析师用的辅助工具那么Agent不需要做太复杂的推理只需要把“SQL生成查询结果解释”做扎实就够了。但如果是给业务运营甚至管理层用的那系统必须能处理模糊问题、进行多轮追问、主动拆解任务容错率极低。我们最后定位的是“运营自助分析助手”所以我把Agent的能力权重放得很高。另一个问题是“复杂到什么程度”。很多团队一上来就想上全链路大规模平台Hadoop、Spark、Flink全上结果光运维就累死一半人。我的原则是按数据量和查询时延倒推架构如果单日原始日志在2亿条以下查询并发不超过20个QPS完全没必要上重型分布式系统。用对象存储加单机列式分析引擎比如DuckDB、ClickHouse单机版就能扛住绝大多数场景。省下来的预算和人力全部投到Agent和RAG质量上性价比高得多。1.3 为什么选RAG而不是让大模型直接学业务知识曾经有同事建议干脆把电商业务规则、历史分析报告全部拿来做模型微调这样就不用每轮都检索了。我明确反对。微调有两个致命问题第一业务知识和经验是动态更新的每周都有新策略、新复盘不可能每个星期做一次微调第二微调的本质是让模型记住而不是让模型能够引用溯源。当运营问“1月我们做过什么提升复购的动作”时微调模型既没法明确指出依据也没法保证数字准确。RAG天然避开了这两个坑。它把知识外置到向量库里回答时可以检索原文片段作为上下文模型只需要做“理解归纳”。这样知识更新只要重新跑一遍文档索引就行成本极低而且还顺带解决了大模型“幻觉”问题——只要检索到的片段质量足够高模型就不敢也不能随意发挥。至于Agent我要的不仅是问答而是要它能“替我干活”。比如运营问“帮我分析下近7天流失最严重的品类并在最后给一份可执行的召回建议”这个任务包含查数、关联知识库、生成建议三个子任务。普通的RAG问答搞不定必须让Agent规划步骤、调用不同的工具然后串联结果。1.4 预算有限这三方面钱绝对不能省低成本不等于零成本。我踩过的坑告诉我下面三块一定不能省否则后续都是泪。Embedding模型的选型开源的bge-large-zh、m3e等模型效果就够用但如果你懒省事直接用某个在线通用embedding API检索质量很可能拉胯。这块推荐用本地部署的向量化模型花钱不多甚至完全免费但检索效果稳定。向量数据库的维护性虽然我用的是pgvectorPostgreSQL扩展但也得注意索引参数调优。如果你不想折腾花钱买托管向量数据库也行但中小团队用pgvector是最物美价廉的选择。Agent的编排框架这块千万别自己从零造轮子。用LangGraph、LangChain或者Spring AI这类成熟框架可以省一个月的开发时间。更重要的是后面要升级多Agent用框架会省心很多。2. 核心细节解析与实操要点数据管道、RAG、Agent三层怎么落地2.1 用户行为数据管道用“轻量数仓”扛住亿级日志很多朋友一听到大数据就想到Hadoop实际上今天完全有更优解。电商用户行为日志属于很规整的JSON事件流埋点SDK出来之后经过消息队列如Kafka进入数据管道最终落到对象存储做冷热分离。我用的是下面的结构层级技术选型职责说明日志采集自研埋点SDK Kafka统一事件命名实时接入数据存储MinIOS3兼容存放原始JSON日志按日期分区数据处理DuckDB Python做ETL、清洗、聚合生成明细表、宽表查询分析ClickHouse单机面向Agent的指标查询秒级返回聚合结果元数据管理PostgreSQL存储表结构、指标口径、事件字典这套组合能扛一天上亿条日志查询时延在1秒以内针对预聚合表。处理流程也很简单每天凌晨把前一天的日志从MinIO拉下来用DuckDB做一次清洗和聚合生成一张面向分析的事件汇总宽表然后同步到ClickHouse。为什么要同步因为DuckDB更适合本地文件分析并发查询能力弱ClickHouse更适合面向服务的固定SQL查询。这一步的关键在于事件建模。我把用户行为统一抽象成几个核心事件view_item、search_item、add_to_cart、purchase、refund每个事件都要有user_id、item_id、category_id、timestamp、session_id等标准字段。建模没做好后面Agent生成的SQL就是无根之木。2.2 RAG知识库构建电商场景下到底要切哪些文档这里要为“知识”赋予一个具象的范围。RAG知识库里放的不是普通常识而是和电商业务强相关的四类资料商品库知识包括商品名称、卖点、规格参数、对应品类的运营人群标签。历史业务分析报告过去12个月的重点周报、月报、大促复盘、用户洞察报告。运营策略文档各品类在不同节点的促活策略、优惠券规则、推送文案模板。FAQ数据库客服高频问题、退换货规则、物流时效说明以及对应的运营解释口径。这些文档的格式五花八门有PDF、Word、Markdown还有表格。我采用的是朴素清洗加统一分块策略先转成纯文本按段落和标题进行分块使用滑动窗口重叠方式确保上下文不割裂每块约300到500个字。分块大小对检索质量影响非常大太短容易丢上下文太长则命中噪声大。我们在验证集上试过300字左右的小块加少量重叠结合重排效果最稳定。嵌入模型先用的是BAAI/bge-large-zh-v1.5本地部署3040显卡即可运行。这个模型对中文长文本语义理解力不错而且支持最大512 token足够覆盖我们的小分块。向量存储直接复用PostgreSQL的pgvector插件建一个knowledge_chunks表字段包括chunk_text、source_doc、chunk_metadata、embedding vector(1024)。2.3 Agent的编排让大模型拥有“手”和“眼”真正让系统“活”起来的是Agent这一层。我这里用的是FastAPI LangGraph搭的轻量Agent服务。Agent的核心动作是“规划-调用-观察-再规划”的循环。举例来说运营问“上周加购后两天内未下单的用户主要集中在哪些城市他们的共同商品偏好是什么”Agent内部会分解子任务一是从ClickHouse取加购未下单用户的城市分布二是从向量库检索该商品类目的偏好标签三是生成综合解释。调用工具query_clickhouse执行SQL、search_vector_db语义检索、call_llm汇总生成。汇总质量校验检查返回结果中是否有SQL报错、检索结果是否为空如果没有再走最后生成步骤。这个编排是纯代码层面控制的使用LangGraph的状态图来定义。每个节点就是一个工具状态里保存“任务计划”“中间结果”“当前问题”。遇到需要多次查询时Agent会通过反思节点动态调整SQL。这里我建议用ReAct模式的变体不要过度依赖“大模型直接输出最终答案”而是强迫它先输出工具调用计划再动手这样可控性高很多。下面是一个核心代码片段的简化版已脱敏核心连接信息from langgraph.graph import StateGraph, END from typing import TypedDict, Optional class AgentState(TypedDict): question: str plan: list current_step: int tool_results: dict final_answer: str def planner(state: AgentState): # 调用LLM生成任务计划例如 [query_kpi, retrieve_docs, generate] prompt f基于用户问题拆解任务计划只输出JSON数组{state[question]} state[plan] call_llm(prompt) return state def query_kpi(state: AgentState): # 从ClickHouse查指标 sql generate_sql(state[question]) result clickhouse_client.execute(sql) state[tool_results][kpi] result return state def retrieve_docs(state: AgentState): # 从pgvector检索相关文档片段 docs vector_search(state[question], top_k5) state[tool_results][docs] docs return state def generate(state: AgentState): context format_context(state[tool_results]) state[final_answer] call_llm(state[question] 请结合\n context) return state graph StateGraph(AgentState) graph.add_node(planner, planner) graph.add_node(query_kpi, query_kpi) graph.add_node(retrieve_docs, retrieve_docs) graph.add_node(generate, generate) graph.add_edge(planner, query_kpi) graph.add_edge(planner, retrieve_docs) graph.add_edge(query_kpi, generate) graph.add_edge(retrieve_docs, generate) graph.add_edge(generate, END) graph.set_entry_point(planner) app graph.compile()实际开发中每一步都可能出错。比如SQL生成错误、向量库连接超时、模型返回格式不对。我的解决办法是给Agent加一个“重试与纠错”节点如果工具调用抛异常把错误信息反馈给模型让它重新规划一次。这非常有效将整体任务成功率从65%提升到了90%以上。2.4 成本控制本地小模型 云端大模型混合调度低成本的核心之一是模型策略。我们没有全部用云端大模型API而是设计了一套“分级调度”机制简单事实类问题如“昨天订单量多少”走本地部署的Qwen2.5-7B-Instruct只负责生成SQL或直接检索查询速度快且免费。复杂推理类问题如“综合分析流失原因并给建议”走云端高能力模型比如Claude系列好处是思维链质量高但仅在必要的时候触发。Embedding模型始终本地跑。换算下来平均单次回答的模型成本被压到了0.02元左右。当然这比纯规则或纯BI查询贵但考虑到它省掉的数据分析师人工成本完全划算。这个量级的成本对中小电商团队来说几乎没有感觉。3. 实操过程与核心环节实现从埋点日志到答案生成的全流程3.1 第一步数据ETL先把“脏乱差”的事件流捋顺最初我拿到的用户行为日志简直是一场灾难同一个“加购”事件在不同端叫法不同iOS叫addAndroid叫add_to_bagWeb叫cart_add甚至有的字段类型都不一致。所以第一步我在DuckDB里写了一个清洗脚本统一事件名和参数字段去掉空session、爬虫流量、测试账号然后按事件时间补全user_id和session_id。清洗完的数据长这样仅为示例结构event_date: 2025-02-20 user_id: U123456 session_id: S789 event_type: add_to_cart item_id: I100200 category_id: C10 source: search / app_home / campaign_A time_ts: 2025-02-20 14:23:11这个标准化过程很费工夫但属于“一次性投入、长期受益”的事。如果这一步偷懒后面Agent生成的SQL很容易查不到数且口径对不齐。我强烈建议把事件字典和口径文档一并放进RAG知识库这样Agent在写SQL之前能先检索到“什么是有效加购”再决定查询逻辑。3.2 第二步构建业务指标层让Agent“有数可查”为了让Agent写SQL足够简单我预先在ClickHouse里建好了几张聚合指标表。比如daily_uv、funnel_daily、user_retention、category_sales每张表都有对应的口径注释。这一步的意义在于把复杂的逻辑提前物化Agent只需要根据问题选择正确的表去查询而不是从头写JOIN和GROUP BY。比如用户问“最近7天不同品类的转化率”Agent只需要查funnel_daily表按category_id分组。如果让Agent自己从头写SQL它大概率需要在十几张源表之间做复杂关联极易出错、也慢。为了让Agent“知道”每张表长什么样我把表结构、字段含义、样例数据、典型SQL模板都放进了一个专门的“表schema文档”并同步到RAG索引。Agent查询前会先检索相关知识确定该用哪张表。3.3 第三步把知识库跑起来注意三个“反直觉”细节知识库建设很容易踩坑。我第一次做的时候把知识库文档按“一个PDF对应一个向量块”来存结果检索效果极差。后来改成小分块后确实好多了。这里分享三个反直觉但非常关键的点不要只存“原文”建议在向量库中为每个文档块额外存储一个“业务解释”字段。比如原文是“3月8日-3月10日开展秒杀活动参与商品共2000个”对应的“业务解释”可以补充为“此活动为38大促目标人群是女性用户主要目的是提升复购率”。这样检索时可以通过摘要字段匹配到更泛化的业务问题。数据定期重索引业务文档每月都有更新建议每月重新跑一次索引。旧文档不要删除而是把过期标签标记为inactive这样既能追溯历史又不会干扰当前检索。做一级重排Rerank仅靠向量相似度检索排序结果往往不尽人意。我接入了一个轻量级的rerank模型比如bge-reranker-base在召回的top20结果中重新打分取top5作为最终上下文。这一步不大但对效果提升非常明显。3.4 第四步开发Agent工具层让大模型像“人”一样干活Agent的工具层是整个系统的核心。我暴露给LangGraph的工具主要有四个generate_sql_and_query(question)先从RAG库检索相关表结构然后让本地模型生成SQL在ClickHouse中执行并返回Markdown表格。retrieve_knowledge(question)从pgvector检索业务知识和历史报告片段。analyze_trend(metric, window)调用时间序列分析函数返回环比、同比、趋势方向以及简单异常检测如超过3个标准差标记为异常。compose_answer(question, facts, knowledge)用高能力模型综合事实和知识生成结论并附上数据来源标注。每个工具我都写好了详细的功能说明和参数示例这样模型在规划时才能正确选择工具。这一步非常吃细节。比如generate_sql_and_query的说明里我会写明“输入必须是中文业务问题方法会返回查询结果结果可能为空返回前需要检查字段名是否与预期一致”。有了这些“工具提示词”Agent工具调用的准确率能提高30%。3.5 第五步整链路跑通后我给运营做了简单到极致的交互页最后我写了一个极简的Web页面左侧是历史对话记录右侧是一个对话框。用户提问后后台自动进行Agent规划、工具调用和答案生成最终答案里包含了“数据结论”“参考依据”“行动建议”三个板块。参考依据里会直接列出引用到的知识库片段来源方便用户人工复核。这步花了两天时间用FastAPI做了后端前端就一个静态HTMLJS。重点是把接口稳定性和流式输出做好。如果用户问题暂时性触发成本较高的模型调用交互上要有等待状态千万不要让人感觉卡死了。4. 常见问题与排查技巧实录4.1 “Agent一直报SQL错误查不出数据”这个几乎是我们初期最高频的问题。排查思路如下先看错误是“表不存在”还是“字段不存在”还是“SQL语法错误”。表不存在大概率是Agent检索表结构文档时没有检索到正确的表。解决方法是把表schema文档做成独立的小文档分块并在工具描述中把常用表名直接写死。字段不存在原因是RAG里没有字段映射比如业务“月活”对应表里的active_users。我增加了字段同义词表放入了RAG知识库让Agent在生成SQL前先检索字段同义词。SQL语法错误多数是因为模型生成的SQL用了ClickHouse不支持的写法或者把时间条件写错。我在generate_sql_and_query函数里加了一层SQL合法性校验不合法就自动重试一次重试仍失败就给前端返回“请减少条件或联系管理员”避免模型反复硬试浪费成本。4.2 “检索到的知识片段不相关答案答非所问”遇到这种情况不要急着换embedding模型。先检查三个环节分块是否过大、是否有重复信息干扰、重排模型是否引入偏差。我的一次真实踩坑是知识库里有大量历史周报周报开头都是“本周业绩达成率XX”导致检索任何问题后台总是优先返回“业绩达成率”相关的片段。后来我在分块时把这类高频无效信息做了加权降权并在写入向量库前做了去重。改造后相关性问题明显改善。另一个技巧是使用混合检索向量检索 关键词匹配BM25。因为我发现很多用户行为问题里包含品类、活动名称等专有名词比如“3月8日秒杀活动”向量检索可能会丢失精确匹配而BM25可以做到。把二者结果按比例合并后重排召回质量整体提升了15%。4.3 “回答里数据是对的但结论太抽象没有可执行性”这是AI回答最常见的问题——“正确的废话”。原因不是模型能力不够而是提示词没有要求结合业务实际。我在最终的compose_answer提示词里加了几条硬性要求第一句话必须直接回答用户问题禁止铺垫。如果涉及指标变化必须指出变化幅度、可能原因引用数据分析或检索到的知识不能只说“有波动”。如果结论中有行动建议必须针对电商场景给出可落地动作例如“对高流失品类进行定向优惠券触达用户圈选规则为近7天加购未下单”,不能给通用话术。举个例子最初回答“上周转化率为什么下降”时模型只会说“可能因为市场竞争加剧、用户需求变化”。加上提示词后它学会了看数据转化率从4.2%跌到3.1%下降26%主要受损环节是加购到支付页流失用户集中在一线城市。知识库里的历史复盘则提示类似情况在去年双11前发生过当时的应对是优化支付页文案和运费险政策。于是最终建议就具体了很多。这些细节就是成本和效果的分水岭。4.4 “响应太慢用户等不了”3-5秒是心理阈值。我们最初平均响应时长是8秒主要在向量检索重排高模型推理。优化思路有三给Agent增加“快速回答”通道如果用户问题是明确的指标类问题通过正则和意图分类识别直接走本地SQL查询不进入高模型推理。给向量检索增加缓存将“问题向量”相似度高于0.92的历史问题直接复用答案。流式输出先返回“正在查询数据”再逐步展示Agent的动作过程配合打字机效果用户感知上会快很多。优化后简单问题2秒内返回复杂问题4秒内开始输出运营侧的耐心基本够用了。4.5 常见问题速查表现象可能原因排查步骤与解决办法检索为空文档未正确分块、embedding维度不匹配检查知识库索引状态手动测试单条检索确认向量维度SQL字段报错字段名映射缺失补充字段同义词文档到RAG并在工具提示中列出常用字段回答模糊提示词缺少约束增加“第一句直接回答”和“必须引用数据”的约束响应太慢高模型调用频繁增加本地方案命中率走本地小模型或直接SQL答案来源不透明没做引用溯源在知识库中存储source_doc字段最终答案附上出处并发一高就挂向量库连接池、ClickHouse并发限制使用连接池限制Agent单实例并发数加上队列4.6 避坑指南这些坑我替你先踩了别让Agent无限重试。必须设置最大步数限制比如最多5次工具调用否则遇到复杂问题它会反复“自我反思”最终导致成本和延迟都飚上去。SQL要设置禁止DDL操作。我在数据库连接中只授权SELECT权限给Agent用否则模型一旦生成DROP或者DELETE后果不堪设想。不要全局共享一个知识库。最好按商品线、店铺、用户分层拆分知识库命名空间避免互相干扰。5. 这套方案的后续扩展方向目前这套系统已经稳定运行了三个月业务方从最初的好奇逐渐变成了日常依赖。每天大概处理200多个真实业务问题其中70%是简单查询和对比分析25%是需要多轮交互的归因类问题5%是临时性探索类问题。整体答案采纳率用户没有二次纠正且给了正向反馈稳定在85%左右算是低成本方案里很理想的数字了。后续想扩展的方向主要有两个。第一个是让Agent具备“主动监控”能力比如每天自动跑一遍关键指标异常检测发现问题就生成一份带数据佐证的分析报告推到运营群里而不是等业务方来问。第二个是引入多Agent协作一个Agent负责查询一个Agent负责知识检索一个Agent负责质量校验最后由主Agent汇总。这个架构在LangGraph里已经能很好地支撑我正在试点。如果你也想做类似的事情我的建议是先把手头的数据管道和知识库整理干净再考虑Agent。很多人一上来就沉迷于让Agent去写复杂SQL、做复杂推理结果地基不稳上线就翻车。反过来把数据和知识梳理仔细后Agent基本上能把80%的脏活累活接住你只需要在旁边盯着它偶尔纠正几回。个人在这几个月里最大的体会是所谓“低成本落地”核心不是选最便宜的工具而是把数据的边界、知识的边界、模型能力的边界都摸清楚。在这三层边界清晰的前提下AI Agent 大数据 RAG的组合完全可以让一个两三人的小团队做出过去需要数十人数据团队才能交付的分析服务。这本身就是件很值的事。