当前位置：首页 > news >正文

【AI大模型应用开发】【项目实战】Agent智扫引擎项目知识整体知识总结以及为什么要使用各个方案进行项目开发与设计

news 2026/8/10 20:11:02

一. 架构决策：为什么用 Agent，而不是传统流程？

意图的复杂性与动态性：传统客服机器人基于意图识别（Intent Classification）+ 固定SOP流转,但在该项目场景中，用户的表达往往是多意图混合且带有上下文依赖的,传统流程需要配置极其复杂的正则和状态机，而ReActAgent可以通过“思考-行动”循环，自主决定先查设备日志（排查），再查知识库（原因），最后给出建议
工具调用的动态规划：统不仅有静态知识库，还接入了IoT设备数据,Agent可以根据及其的实时状态动态编排工具链,比如发现异常，Agent会自主调用“生成依从性报告”工具，而不是靠用户主动触发,这种“主动关怀”是传统状态机无法实现的
容错与自我修正：项目场景下，用户描述往往不规范,Agent的ReAct循环允许它在工具调用失败或信息不足时，进行自我反思（Reflection）并向用户追问，而不是直接抛出“我不明白您的意思”

二. 工程兜底：Tool设计与异常处理机制

LLM是不稳定的，在项目场景下，一次错误的压力参数指导可能导致机器事故,系统如何保证绝对安全？

Tool设计的“防御性编程”：
参数强校验：所有暴露给LLM的Tool，底层全部使用Pydantic进行严格的Schema校验,LLM传错参数（如把压力值传成字符串，或超出安全阈值），Pydantic会直接拦截并返回结构化错误，而不是让脏数据进入业务逻辑
只读与写操作分离：对于涉及设备参数修改的Tool，Agent只有“建议权”没有“执行权”,Agent只能生成“建议将压力调至X”的报告，必须经过用户或工作人员在UI上的二次确认（Human-in-the-loop），从物理层面杜绝AI误操作
异常处理的三层兜底：
L1 (解析层)：使用OutputFixingParser,如果LLM输出的JSON格式错误，Parser会自动把错误信息喂回给LLM，让它重新格式化，而不是直接报错
L2 (执行层)：多重try-except,如果第三方IoT接口超时或返回空数据，Agent会捕获异常，并在Prompt中注入“设备数据暂时不可用，请基于通用指南回答”的上下文，避免幻觉
L3 (业务层)：设置最大迭代步数（Max Iterations）和置信度阈值,如果Agent绕了3圈还没解决问题，或者检索到的知识相关性得分低于阈值，强制触发降级策略——无缝转接“专属顾问”人工客服，并附带Agent之前的思考过程摘要，保证用户体验不中断

三.RAG的特殊性：如何做到 Precision@5 = 1.0？

通用RAG在该领域往往会“水土不服”,你的检索精度极高，具体做了哪些针对性的工程优化？

切分策略（Chunking）的领域定制：操作手册和指南具有极强的结构化特征,我们没有用简单的固定字符切分，而是基于Markdown标题层级和表格边界进行语义切分,对于“型号与对照表”这种关键数据，将其转化为“QA对”或“JSON格式”单独存储，确保检索时不会把表头和数据行切断
混合检索（Hybrid Search）：虽然用了ChromaDB做向量检索，但对于“RMed Fit P10”这种精确型号，或者“AH < 5”这种精确数值，纯向量检索容易飘,引入了SQLite FTS5 做关键词精确匹配，将向量召回和关键词召回的结果进行RRF（倒数排名融合），这就是为什么我们的 MRR 能达到 1.0
元数据过滤（Metadata Filtering）：在检索前，Agent会先提取用户的设备型号和购买时间，将其作为 Metadata Filter 传给 ChromaDB,绝不把“家用机器”的指南召回给“工用机器”用户，从源头上切断幻觉

四. 性能与评估：102ms 延迟与 RAGAS 体系

102ms 的端到端延迟对于包含检索和生成的RAG系统来说非常低，你是怎么做到的？RAGAS 是怎么指导你优化的？

极致性能优化：
模型选择与部署：没有盲目追求大参数模型，而是选择了Qwen2.5这种在指令遵循和工具调用上表现优异的开源模型，并通过Ollama进行本地化/私有化部署，结合 vLLM 等推理加速框架，大幅降低了首字延迟（TTFT）
流式输出（Streaming）：采用LCEL 的流式编排，检索一结束，生成模块立刻开始吐字，用户体感延迟远低于实际端到端延迟
缓存策略：针对“滤网更换周期”、“常见漏水排查”等高频且答案固定的问题，在检索层之上增加了 Redis 语义缓存，命中缓存直接返回，耗时降至 10ms 级别
RAGAS 驱动的持续迭代：
不是上线前测一次，而是把 RAGAS 集成到了 CI/CD 流水线中,每次更新知识库或更换 Prompt，都会自动跑一遍评估集
Faithfulness 0.863 的代价与收益：为了达到这个指标，在 Prompt 中加入了极其严苛的约束（如：“如果上下文中没有提到该问题，请直接回答‘知识库未收录’，严禁推测”）,这虽然牺牲了一点点“Answer Relevancy”（有时显得不够聪明），但在严格场景下，“知之为知之，不知为不知”才是最高级的智能

五. 模型超时重试怎么设计？

核心原则：拒绝无脑重试，必须引入“幂等性”与“退避策略”，防止雪崩效应

幂等性设计：重试的前提是请求必须幂等,在系统中，像检索操作手册、查询设备状态等无副作用操作，天然支持重试；但如果是涉及修改用户设备参数的写操作，必须在请求头中携带全局唯一的Idempotency-Key(如 UUID),服务端根据该 Key 缓存状态,若发现相同 Key 的请求正在处理或已完成，直接返回缓存结果，彻底杜绝重复修改和操作风险
指数退避 + 抖动（Exponential Backoff + Jitter）：当遇到网络超时或 502/503 等瞬时故障时，重试间隔不能是固定的,应采用指数退避（如 1s -> 2s -> 4s），并加入随机抖动因子（如 ±0.5s）,这能有效打散并发请求的重试时间，避免大量请求在同一瞬间重试，导致服务端负载瞬间翻倍（即“惊群效应”）
重试次数与熔断：严格限制最大重试次数（通常 3~5 次为宜）,若连续失败，应触发熔断机制，直接返回降级结果，而不是让 Agent 陷入无限重试的死循环

六. Tool 调用失败了怎么回退？

核心原则：错误必须结构化，回退必须分层级（Fallback Chain）

结构化错误分类：工具返回的不能是一段自然语言，而必须是结构化 JSON,系统需根据error_type精准分类：
瞬态故障（Timeout/502）：触发指数退避重试
参数错误（Schema Error/400）：禁止重试，将错误信息反馈给 LLM，让其修正参数后重新调用
权限/业务拒绝（403/Empty Result）：禁止重试，直接记录日志并返回明确的“未找到”或“无权限”提示
多级降级策略（Fallback Chain）：为关键工具配置备选方案,例如，主用的高精度翻译 API 挂了，自动降级到备用 API；备用 API 也挂了，降级到本地小模型；小模型也失败，最终降级为返回友好的静态提示语或转人工
任务剪枝：如果某个非核心子工具永久失效，Agent 应具备“大局观”，主动跳过该子目标，优先保障核心任务的完成，而不是让整个任务卡死

七. 对话记忆越积越长，怎么裁剪？

核心原则：分层渐进式压缩，优先无损，有损兜底

即时轻量化（SnipCompact）：每轮请求前，通过纯文本处理截断超长的工具日志（如保留首尾和省略号）、合并连续重复的助手消息、删除空消息,这一步零成本，能挡住大部分上下文膨胀
滑动窗口 + 无损归档（MicroCompact）：仅保留最近 N 轮（如最近 5-10 轮）的完整对话,更早的历史消息移出上下文窗口，写入本地磁盘或 Redis，上下文中仅保留一个占位符（如“[前文已归档，需要时可调用 read_memory 工具]”）,这是无损的，模型需要时可按需检索
有损摘要压缩（AutoCompaction）：当 Token 占用达到阈值（如 78%）时，触发 LLM 对早期历史进行结构化摘要,保留核心目标、已完成的步骤、关键决策和修改过的文件列表，丢弃中间的探索过程和冗余日志
紧急全量压缩（Full Compaction）：当濒临溢出（如 92%）时，执行最激进的压缩，仅保留系统提示词、当前核心目标和最近一次工具结果，丢弃所有中间调试细节

八. Token 消耗怎么压下来？

核心原则：从输入、输出、模型路由三个维度进行全链路“瘦身”

输入端极致压缩：
工具结果裁剪：工具返回的原始数据（如几万行的日志、完整的数据库表）绝不能直接塞给 LLM,必须在工具层做预处理，只返回 LLM 需要的关键字段（如只返回order_id和status），并限制最大字符数
动态 Prompt 注入：不要把所有规则都写在 System Prompt 里,将规则拆分为“常驻规则”和“场景规则”，只在触发特定意图时，才将相关规则动态注入上下文
模型路由（Model Routing）：不要杀鸡用牛刀,对于意图识别、信息抽取、简单分类等任务，使用轻量级小模型（如 7B/8B）；只有在复杂的逻辑推理、代码生成或最终总结时，才调用强模型（如 72B/405B）,实测可将整体成本降低 40%~60%
输出端控制：在 Prompt 中明确要求输出格式，例如“仅输出 JSON”、“不超过 200 字”、“使用 Markdown 表格”,限制输出长度能大幅减少 Output Token 的消耗
高频任务 Skill 化：对于日报生成、周报整理等高频重复任务，将其封装为固定的 Skill（Prompt + 脚本），避免每次都让 LLM 重新规划步骤，可节省 80% 以上的 Token

九. 日志和告警怎么配？

核心原则：结构化 Trace，聚焦高价值信号，避免“狼来了”

全链路 Trace 记录：采用 JSONL 格式记录 Agent 的每一步决策,每条日志必须包含run_id、step、type（thought/action/observation）、input_tokens、latency等字段,特别是thought字段，是排查“目标漂移”和“幻觉性成功”的关键
聚焦核心 KPI 告警：不要对所有日志都告警，重点监控以下指标：
死循环/绕圈：同一任务中，同一个工具被连续调用超过 3 次，或单任务迭代步数超过阈值（如 10 步）
Token 预算熔断：单次任务的 Token 消耗超过预设上限（如 50k Tokens），立即暂停并告警，防止失控导致高额账单
工具失败率：某工具的失败率在短时间内（如 1 分钟）超过 30%，触发告警
告警降噪：配置for: 2m这样的持续时间条件，过滤掉网络抖动引起的瞬时毛刺,同时支持告警分组和静默，避免同一根因引发几百条告警轰炸

十.线上模型效果突然下降，排查和回滚流程是怎样的?

使用”精准排查 + 多级回滚”策略进行排查

1.核心排查流程：基于 RAGAS 指标的快速定位

当线上用户反馈“变笨了”或出现指导错误时，不会盲目去改 Prompt，而是依托搭建的RAGAS自动化评估体系，按照优先级进行分层排查：

第一步：看 Context Recall（召回率）—— 排查检索层（约占 50% 的问题）
现象：模型回答“知识库未收录”或给出的建议与型号不符
排查动作：优先检查知识库更新记录,很多时候效果下降是因为增量同步时，旧文档被误删但新文档的向量索引还在“构建中”，或者新增文档导致检索权重漂移，老文档被挤出了 Top-K26,会立即对比新旧版本的知识库快照，确认检索链路是否健康
第二步：看 Faithfulness（忠实度）—— 排查生成层（项目场景的 P0 红线）
现象：模型开始“一本正经胡说八道”，比如给出了错误的湿化器档位建议
排查动作：检查近期的 Prompt 变更记录或模型温度（Temperature）参数,在项目场景下，宁可回答“信息不足”，也绝不能脑补,如果是 Prompt 约束被削弱，立即回退 Prompt 版本
第三步：看 Answer Relevancy（相关性）—— 排查意图与路由层
现象：用户问“下水功能漏水怎么办”，系统却回答了“机器故障报修”。
排查动作：检查路由日志和 Query 改写模块,确认用户的真实意图是否被正确分类到了对应的知识库或工具链上

2. 紧急回滚机制：从“一键切流”到“版本快照”

如果排查发现是核心组件（如新上线的 Embedding 模型、新 Prompt 或知识库更新）引发了系统性故障，会立即启动多级回滚预案：

(1).模型与 Prompt 回滚（秒级恢复）
ModelFactory 和 Prompt 管理实现了版本化,一旦发现新模型或新 Prompt 导致幻觉率飙升，可以通过网关层立即将流量 100% 切回上一个稳定版本（Immediate Rollback），整个过程对用户无感
(2).知识库版本回退（分钟级恢复）
针对知识库更新导致的灾难，会利用 ChromaDB 或向量数据库的版本快照功能，一键将知识库状态回退到更新前的时间点,回退后，使用包含真实用户问题的“黄金测试集”跑一遍自动化评估，确认 Precision 和 Faithfulness 恢复到基线水平（如 0.863 以上）后，再重新开放线上流量

3.服务降级策略：保底线，防崩溃

在排查和回滚期间，为了保证 C 端用户的体验，系统会触发多级降级策略（Fallback）：

(1).轻度降级（L1）：如果大模型推理耗时变长或队列堆积，系统会自动关闭非核心的“创意生成”或“超长多轮记忆”功能，精简 Prompt，限制最大输出 Token，优先保障核心问答的可用性
(2).中度降级（L2 - 缓存兜底）：如果检索服务出现抖动，系统会强制优先走 Redis 语义缓存,对于“滤网多久换一次”这类高频问题，直接返回缓存的标准答案，跳过实时推理，用极低延迟保障基本服务
(3).重度降级（L3 - 人工接管）：如果大模型频繁超时或发生严重幻觉，触发安全熔断机制,系统会直接返回静态兜底话术（如“当前系统维护中，已为您转接专属人工顾问”），并附带用户的设备异常日志，无缝转交人工处理,在项目场景下，宁可保守转人工，绝不可冒进编造