LLMOps：针对大模型的全生命周期工程化管理。 核心目标是让大模型从模型开发、微调、部署到线上运行、监控、迭代的全流程标准化、自动化、可观测、高可用。 解决大模型落地的「模型飘移、不稳定、成本高、迭代慢」等问题。

• 数据集管理、统一API服务、Prompt 管理、监控各种指标管理（ 模型/业务/系统指标）、模型自动化微调、模型版本控制

AgentOps：解决 多Agent 协作链路混乱、Agent状态丢失、任务执行失败、资源浪费等问题。

• 状态与会话管理：解决多轮任务中 Agent 的状态持久化、上下文复用、会话过期问题；Redis保证 状态不丢失、不混乱。短期记忆和长期记忆管理。
• 多 Agent 协作管控：任务队列 做资源隔离和并发控制；
• 链路监控：LangSmith、LangFuse 监控 Agent 的任务执行链路，是否执行失败、执行耗时多久、是否出现死锁；每个 Agent 任务生成全局唯一 TraceId；
• 可解释性：日志存储，ClickHouse 行为日志分析， 记录 Agent 的「思考过程（大模型推理）→行动决策→执行结果」， （调用工具、访问数据库、调用其他 Agent）
• 成本管控：调用次数和Token统计
• 异常恢复与降级：Agent 执行任务时可能出现「大模型调用失败、工具访问超时、协作链路中断」，AgentOps 要支持自动重试、降级到备用 Agent、人工介入，比如 RAG 检索 Agent 失败时，降级为本地知识库直接查询,重试仍失败则降级为规则引擎。

如何解决大模型幻觉问题？

• 不让他胡编乱造，不知道回复不知道
• RAG + 提示工程
• 强制根据检索内容生成，标注来源
• 模糊问题澄清或重写，复杂任务 思维链 按步骤进行引导
• 建知识图谱，基于事实关联
• 多路生成比较校验、 多模型交叉验证
• QA微调LLM、对齐优化打分

大模型生成不稳定怎么办？

• 保证上下文治理（截断、摘要压缩）减少干扰信息
• 提示词 加示例、强约束
• 模型 temperature 调低

如何让LLM作为系统里可以被信任的一环？

RAG + 强制引用 + 校验 + 置信度评分 + 多模型交叉验证 + 人工复核 + 兜底机制 + 全链路记录

低置信度 → 自动降级

如何解决长尾问题？

加元数据标签、混合检索、问题扩展、知识库增量更新 补充、 对低频内容做格式标注（加粗 / 标题）强化权重。

存在问题：

上下文污染？上下文隔离

注意力分散？上下文压缩精简、裁剪过滤（ 总结后再给）、最近几轮+历史摘要、 按相关性排序后截断

输出的Token太多怎么办？记忆系统存储（长期记忆、短期记忆）

效果怎么评判？存执行过程

模型Lora训练参数和最常见的经验？

秩、 缩放因子、学习率、批量、步数、轮数、看损失曲线。

Java系统接入大模型遇到的问题？

1、并发高，流式响应 导致请求连接一直占着、占线程久，导致业务系统请求也进不了。（Flux响应式框架 底层用的Netty、AI服务独立部署 物理隔离）

2、没做限流，用户要是疯狂提问，Token不够。（三级限流：用户级限流、接口级限流、单次Token限流 超过截断、成本监控）

3、不做兜底导致系统报错。（重试 + 熔断 + 降级）

4、上下文没做管理 Token爆炸。（滑动窗口 + 上下文摘要压缩）

5、没做内容审核、违规被封。（输入校验审核、输出审核 关键词拦截、人工复审）

Workflow：确定的步骤，不需要用户参与

Agent：很多种不确定的步骤。用户可以确认。自主选择工具。（基础任务先跑出来、按需增加复杂度，优化（提示词、模型能力缺少加工具、上下文需要更精准））

什么情况适合用Dify？（其他业务系统零碎需求、简单流程、依赖工具插件好解决）

什么场景用代码框架实现？（通用AI能力 知识库RAG、智能问数、流程发起）

Dify 链路追踪 用 OpenTelemetry 做链路采集与标准化，默认用 Jaeger 做链路的可视化和存储。

---

一、智能问数

关键步骤：自然语言提问， 意图识别（拆解场景关键词和属性、实体），知识库检索，LLM生成SQL， SQL校验，执行SQL，构造Echarts所需json结构，生成可视化图表，自然语言总结返回。

扩展能力：异常处理、 数据字典管理、权限控制、数据脱敏。

限制边界：明确不支持的场景（如复杂多表关联 + 自定义计算、非结构化数据查询），提前告知用户 。

准确率关键： 核心是 “全链路校验”，从意图理解到结果返回，每个环节都设置兜底机制

（一）LLM意图识别 / 问题澄清

（1）拆解场景关键词和属性、明确领域、实体

避免跨领域知识混淆 出现歧义。

目标：将自然语言拆解为 “指标 + 维度 + 筛选条件 + 聚合方式” 四要素，例如：

提问：“2025 年 12 月北京地区各支行的个人房贷发放额（≥50 万）总和”

拆解结果：

• 指标：个人房贷发放额
• 维度：地区（北京）、支行（所有）
• 筛选条件：时间（2025-12）、金额（≥50 万）
• 聚合方式：按支行分组求和

（2）固定格式的关键词：可先用 正则表达式 + 领域词典，提取明确的实体（如时间、地区、指标名）

（3）当关键信息缺失 / 歧义时，自动 反问用户 澄清问题

（4）对模糊表述，通过大模型结合上下文解析，转换成SQL字段或条件

（二）知识库RAG

• SQL表结构、字段注释、 指标字典、 业务规则、联表规则、问答对示例。元数据

（三）LLM

• 数据字典联动、表关联规则说明
• 限制返回行数（银行数据量大，避免全表扫描），例如对 “Top5” 场景自动添加LIMIT 5
• 权限过滤：根据用户角色自动添加数据权限条件，例如客户经理只能查询 “自己名下客户”，需在 SQL 中拼接where manager_id = '当前用户ID'
• 数据脱敏：对敏感字段（如客户身份证号、手机号）自动脱敏，查询结果中只显示 “110****1234”
• 危险操作说明（如DROP/UPDATE，仅允许SELECT）
• 禁止自己生成数值。

（四）结果校验和准确性校验

• 危险操作校验
• 语法校验：生成 SQL 后，用Explain+SQL 或其他校验工具 校验语法正确性
• 银行合规校验
• 多源交叉验证：关键指标（如净利润、不良贷款率）从多个数据源（如数据仓库、业务系统）查询，对比结果一致性，不一致则触发人工复核
• 人工复核：对高敏感场景（如风控决策、管理层汇报数据），提供 “人工审核” 按钮，用户可提交查询结果给数据专员复核

（五）异常处理

查询失败时（如数据不存在、权限不足），返回明确提示，而非技术错误（如 “未查询到 2025 年 12 月深圳地区的房贷数据，请检查时间或地区是否正确”）

（六）没有办法的办法

领域微调、 人工标注反馈加入训练集

模型异常兜底：

• 多模型部署（如同时部署 GPT-4o 和通义千问，互为备份）
• 模型降级方案：大模型失效时，自动切换到纯规则引擎（支持基础查询）；

规则先行，AI 补位，校验兜底

复杂联表SQL如何保证准确率？

• 知识图谱发现联表关系
• 围绕join进行优化，
• 先做语义理解解析：判断需要哪些表、关联关系和顺序、业务规则、主键外键带表名、过滤条件提取。每一步增加一层校验
• 不用 LLM 直接写 JOIN，JOIN是程序推导。 把 “泛化生成” 转为 “结构化拼接”。
• JOIN 数量限制 、去重、不能有中间表
• 把复杂 JOIN 场景模板化，LLM只选模板，填充参数，提供模板示例并拆解

场景名称：个人客户不良贷款分地区统计
涉及表：t_customer（C）、t_account（A）、t_loan（L）
关联顺序：C → A → L（小表在前，大表在后，优化性能）
关联键：C.customer_id = A.customer_id；A.account_id = L.account_id
过滤模板：L.loan_date between {start} and {end}；C.region = {region}
聚合模板：sum(L.loan_amount) as bad_loan_total group by C.region

---

二、RAG

1、存在哪些常见问题和有哪些优化手段提高检索能力？

• 数据清洗过滤 + 标准化
• 分段。语义切分，分隔符切分，父子文档切，重叠；
• 检索。关键词 + 语义检索（比例、阈值） + Rerank模型（重排器）
• 问题。问题改写（口语化改写成语义清晰标准的问题） + 动态生成多个子问题。意图识别。
• 生成。Prompt约束，不让胡编乱造、不要额外推理。

1. 先版面解析：PDFPlumber / PaddleOCR / LayoutLM （按type分类存储 位置信息（bbox、page） ）
2. 语义切分： 文本 → 按标题 / 段落；表格和图片作为整体chuck

PDF含表格 和 图片的怎么切？跨页表格 表头？

表格：连续页 列数一致 ， 表头相同 表头相同。

• 表头只保留一次；中间页无表头 → 自动继承；合并为一个 Table Chunk，作为一个语义单元）

2、检索结果和结果无关怎么办？明明有就是召回不了怎么办？

• 人工QA标注 开启按标注回复
• 多路 或 多维度召回
• 知识图谱 图检索
• rerank重排序

多路召回 结果融合：对多路召回的结果去重、排序、筛选，得到最终的高质量上下文。

RAG 评估指标：召回率、相关性、完整性、忠实度、准确率

• LangFuse：开源且灵活，适合需要自托管、多框架兼容、定制化程度高的场景
• LangSmith：闭源但生态深度集成，适合 LangChain 重度用户和企业级 Agent 开发

如何评估？

• 构建评测集、大模型自动打分
• 召回率 统计
• 按点赞 点踩 计算用户满意度
• LangFuse

建立一套可量化的评估基准，用于客观衡量后续改进措施的效果。

1、创建评测集

• 目的：定义一套标准、可重复执行的测试用例。每个用例应包含一个问题和对应的预期结果
• 操作：创建至少包含 100 组问题的评测集，须覆盖核心真实提问场景，建议包含以下类型

事实型：“产品X”的保修期是多久？

分析型：为什么近3个月“产品X”的销量在不断上升？

教程型：如何安装“产品X”。

比较型：对比“产品X”和“产品Y”的主要差异。

2、执行自动评测并记录结果（大模型打分）

• 目的：记录初始配置下的 RAG 应用的表现，作为后续优化的对照组。
• 操作：完整运行一次评测集，并记录每个用例的召回内容与诊断结果。

三、MinerU文档识别

8GB显存 + 16GB内存

跨页提取、合并单元格提取、

• PDF 跨页拼接（最重要）： 让 MinerU 看到的不是“跨页表格”，而是“单页大表格”： 用 pdfplumber / PyMuPDF / pdfium 检测页面底部是否有表格线，判断下一页顶部是否有表格线，
• 表头相似度判断 + 表格拼接：如果有 判断是不是同一个表格，是则和下一页拼接成一页， 拼成一页长图 / 长 PDF 页面
• 如何判断“这是同一个表格？” 不用靠 MinerU，靠规则： 表头文本相似度 ≥ 90% ， 列数相同
• 行列向上/向左填充：行合并 / 列合并 语义合并。
• 预处理PDF文档。 可使用 Adobe Acrobat工具 先将 PDF 转换为 Word， 在 Word 中修复错位的合并单元格，调整 表格跨页， 再用 MinerU 识别。
• 筛选跨页表格→拼接为长页或添加跨页标记； 使用 Adobe Acrobat工具提取跨表格页面范围，合并为长图，再转成PDF，
• 用 PDF 编辑工具 在第 1 页表格末尾、第2页开头 添加页面和表格编号。
• 合并单元格内文字居中对齐，缩小字体，避免文字溢出
• 删除续页表头，保留第 1 页表头

模糊图片提取问题怎么解决优化？3识别成8，怎么解决？

• Python+OpenCV预处理：使用OCR 预处理工具 进行去噪、增强对比度、锐化，
• 业务场景语言区分：时间前几位不可能是8
• 基于字符形状特征的校验：孔洞数量，有闭合孔洞是8，没有是3
• 模型训练： 相同样本数量微调

MinerU底层处理步骤

• 文件类型判断 和 预处理
• 布局检测：LayoutLMv3、YOLO等布局检测模型，识别区域及坐标，公式检测
• 公式识别：自研模型，将公式转换为LaTeX格式
• 图片识别：PaddleOCR字符光标识别
• 处理：版面拼装、坐标修复

四、流程发起

（一）意图识别

关键词匹配 确定什么流程？

（二）参数提取 格式化+校验

格式标准化， 缺失 则生成澄清问题 让补全；

（三）参数澄清

（四）构建响应json

通用返回json结构（回复内容 + 流程参数）

（五）前端回显 填充模板

根据参数 填充 流程模板，允许修改参数值

（六）提交 - 流程发起

PROMPT_TEMPLATE = """
你是企业请假流程的AI助手，需完成以下任务：
1. 识别用户意图：仅处理「请假」意图，其他意图（如查制度、开会）返回intent为other，并提示用户仅支持请假咨询。
2. 提取请假参数：从用户话语中提取start_time（开始时间，需转为YYYY-MM-DD HH:MM格式）、location（外出地点）、days（请假天数，整数），无则为null。
3. 判断参数是否缺失：请假必填参数为start_time、location、days，缺失则返回missing_params列表，否则为空。
4. 生成澄清话术：参数缺失时，生成简洁的澄清语，仅要求补充缺失的参数。
5. 参数完整时，自动计算end_time（开始时间+days天，格式同start_time），并默认leave_type为「当年年休」。

请严格按照以下JSON格式返回结果，不要添加任何额外内容：
{{
    "intent": "leave_apply"或"other",
    "collected_params": {{
        "start_time": "str或null",
        "location": "str或null",
        "days": int或null,
        "end_time": "str或null",
        "leave_type": "当年年休"或null
    }},
    "missing_params": ["参数名列表"]或[],
    "reply_text": "给用户的回复话术"
}}

用户当前输入：{user_input}
历史对话上下文：{history_context}
"""

五、企业AI Agent平台

1、知识库：多种类型知识库、问答对；导入文档和问答对（增加相似问题）

2、多种常见任务场景（文本处理、制度查询、流程发起、智能问数），先确定核心场景。

3、意图识别：从用户输入中提取关键词和任务类型（ 先通过查询意图识别领域，再基于领域过滤元数据，最后做精准匹配 ，避免跨领域知识混淆 出现歧义 ）

4、设计、写代码

领域识别，分配给上面的专项智能体执行。

开发一个企业AI平台，支持不同业务的需求。前端有时候只展示大模型交互的文本；还可以根据用户问题发起不同的流程，不同流程还展示不一样的流程表单；当用户想查某个人信息时，可能返回某人基本信息的表单；还可以进行RAG检索问答。前端只和后端AI功能只通过一个接口交互，请根据我的需求设计一下。

1. 前端：展示 + 交互（结构化json）+ 表单模板
2. 统一API接口： 通过请求参数中的request_type区分业务类型。
3. AI后端 接口层FastAPI： 智能决策 + 流程编排 + 数据理解
4. 意图识别/任务路由：
5. Workflow： 不同意图 → 不同处理Workflow/Agent
6. 业务处理层：（LLM问答、文档问答、智能问数、流程发起、RAG检索）
7. 企业系统/数据源：HR、OA、DB

{
  "user_id": "企业内部用户ID", // 用于身份认证、数据权限
  "business_type": "text_chat/process_init/data_query/rag_qa",  // 智能体类型标识
  "content": "用户输入内容（如“发起请假”“查张三信息”）",
  "form_data": {     // 表单参数
    "name": "张三",
    "code": "A9956",
    "dept": "xx部门"
  },
  "session_id": "xxx"  // 会话ID
}

{
  "code": 200,
  
  "data": {
    "business_type": "text/process_form/data_form/rag_answer", // 智能体类型标识
    "answer": "大模型的文本回答内容",
    
    // 预设表单结构+数据:人员信息表单、流程表单、其他表单数据
    "form_data": {
      "name": "张三",
      "code": "A9956",
      "dept": "xx部门"
    },
    "process_id": "请假流程ID",
    "is_complete": "1",		// 是否完成 参数澄清
    "sources": ["知识库文档1", "知识库文档2"],    // RAG检索回答引用来源
    "session_id": "xxx"
  }
}

• business_type：可以前端选择，也可以大模型意图识别确定，不同business_type返回不同的字段和表单内容。前端根据business_type 决定渲染哪个表单。

企业AI知识库如何设计搭建

1、明确 3 个问题即可：

是否上 RAG、是否要权限、是否要人工校验。

2、知识库 做版本控制、权限校验、启用禁用开关

3、知识加工：清洗 结构化、切分、语义增强

• 表格：行级 + 表头语义补充
• 长文档：目录 → 章节 → 段落

4、存储

• 向量数据库：语义召回（Milvus / FAISS / pgvector）
• 关系型库：元数据、权限、版本
• 对象存储：原文档

5、检索策略

• 多路召回：向量 + 关键词 + 规则检索（制度类、强约束）
• 重排序（Rerank）

6、RAG 生成控制（防幻觉）：问题改写 或 澄清意图，引用来源

7、评估：最小指标集：命中率（Recall）、可用率（Answerable）、幻觉率、用户追问率

企业 AI 知识库：是 知识治理 + 多路检索 + 可控生成 + 权限体系

---

GraphRAG、LightRAG 与 AgenticRAG

在知识图谱的落地实践中，Neo4j 和 Nebula Graph （奶贝乐）是目前最常用的两款图数据库，二者分别适配不同的业务规模和技术需求。

Agent

（规划、工具、记忆）如何更靠谱？如何监控不是黑盒？如何评测？

• 思维链、ReAct、Plan-Execute

多个Agent是如何通信的？

主Agent统一管理 按优先级调度 Agent 执行 、用消息队列发布订阅+Redis缓存。

受控调度；统一风控、日志、限流的消息总线 + 结构化协议通信

基于中介者模式的核心设计目标是解耦子 Agent 之间的直接依赖，子 Agent不会直接调用其他子 Agent，所有交互都通过中介者服务中转。

具体流程是这样的：

1. 当子 Agent A 依赖子 Agent B 的结果时，A 不会直接寻址 B，而是向中介者提交依赖请求，附带任务 ID、所需数据类型、上下文版本号。
2. 中介者根据自身维护的Agent 注册列表和任务依赖 DAG，找到能处理该请求的子 Agent B，将任务分发给 B。
3. B 完成任务后，将结果写入版本化上下文存储，并通知中介者；中介者再将结果路由给依赖方 A。

这种设计的好处是：子 Agent 无需感知其他 Agent 的地址、状态，新增或下线 Agent 只需在中介者更新配置，系统扩展性更强。

多Agent如何做上下文隔离？

• 按用户id + 任务id + agentId + 版本号 做上下文key前缀隔离；
• 内存沙箱隔离
• 短期记忆、长期记忆、团队协作共享记忆

多agent系统异常处理等技术问题

多 Agent 架构异常管理最优方案：中介者统一管控 + 分层容错 + 快照恢复 + 全链路追溯

1. 故障检测：中介者心跳探活 Agent 实例；日志埋点捕获任务超时 / 结果错误 / 依赖缺失；共享记忆校验版本号，识别脏数据异常。
2. 分层容错：① Agent 宕机→重试 + 备用实例接管；② 任务失败→隔离故障 Agent + 降级执行（简化逻辑）；③ 依赖异常→读取共享记忆历史版本快照，跳过故障依赖。
3. 断点恢复：短期记忆本地快照，共享记忆版本化持久化，任务按 checkpoint 续跑，避免全量重算。
4. 追溯监控：中介者汇总全链路日志 + 调用链，异常可定位到具体 Agent / 任务 / 记忆版本。