这次我们来看一个律所 AI 实战项目。它不是某个具体的开源工具而是一个将 Agent智能体、RAG检索增强生成和 Ops运维/运营三大技术栈整合落地的工程实践案例。对于想在企业级场景尤其是法律、金融、咨询等专业领域应用大模型的技术团队来说这个打通链路的过程极具参考价值。核心问题很直接如何让大模型在专业领域“靠谱”地工作单纯调 API 回答通用问题远远不够。你需要它理解复杂的专业文档能进行多步骤推理和任务分解并且整个系统要稳定、可监控、可迭代。这就是 Agent、RAG 和 Ops 需要协同发力的地方。本文会带你拆解这个实战项目的核心架构重点关注三者是如何“打通”的。我们会从技术选型、环境搭建、功能验证到运维监控一步步还原一个可落地的工程路径。无论你是想构建内部知识问答系统、合同审核助手还是客户服务自动化流程这篇文章提供的思路和踩坑经验都能直接复用。1. 核心能力速览技术栈如何分工协作首先明确 Agent、RAG、Ops 在这个实战项目中的角色和协作关系。下表概括了它们的分工与集成点技术组件核心职责在本项目中的具体实现硬件/环境依赖RAG (检索增强生成)知识供给从海量、非结构化的专业文档如法律条文、判例、合同范本中精准检索相关信息作为大模型生成答案的依据。构建本地化知识库可能使用向量数据库如 Milvus, Chroma, Qdrant结合全文检索。处理 PDF、Word、扫描件等格式。依赖嵌入模型Embedding Model和向量数据库服务。GPU可加速嵌入生成CPU也可运行。内存和磁盘空间取决于知识库规模。Agent (智能体)大脑与执行接收用户复杂问题进行意图理解、任务规划、工具调用如调用RAG检索、计算、搜索、多轮对话和结果合成。基于大语言模型如 GPT-4, Claude, 或本地部署的 Llama 3、Qwen等构建使用 LangChain、LlamaIndex 或自主开发的框架进行编排。主要依赖大语言模型的推理能力。如果使用云端API则对本地硬件要求低如果本地部署LLM则对GPU显存要求高通常7B模型需6-8G70B模型需更高。Ops (运维/运营)系统保障与优化确保整个AI服务稳定、可靠、可监控、可迭代。包括服务部署、性能监控、日志审计、效果评估、知识库更新、安全管控等。通过 Docker 容器化部署、Prometheus/Grafana 监控指标、ELK 收集日志、构建评估管道Evaluation Pipeline对回答质量进行打分和反馈循环。依赖标准的运维基础设施服务器、Docker环境、监控栈。对硬件无特殊要求但需要规划好资源。打通的关键在于Agent 作为总控在需要专业知识时调用 RAG 工具Ops 体系则监控整个调用链路的健康度、效果和成本并驱动知识库与 Agent 的持续优化。下面我们就从零开始看看如何搭建这样一个系统。2. 适用场景与使用边界适合谁用法律科技团队构建内部案例检索系统、合同智能审查工具、法律咨询辅助助手。企业IT与业务部门需要处理大量内部规章、产品手册、历史工单并希望提供智能问答支持。AI 应用开发者希望深入理解 Agentic RAG 系统的完整落地流程而不仅仅是 Demo 级别。技术负责人/架构师评估在专业领域引入大模型方案的技术路径、资源投入和风险点。能解决什么问题解决“幻觉”问题通过 RAG 提供精准的文档依据让大模型的回答有据可查减少胡编乱造。处理复杂长流程任务用户一个问题可能涉及多个子任务如“检索某类合同范本并对比其中甲乙双方责任条款”Agent 可以自动规划分解并执行。保障系统稳定性通过 Ops 体系实现服务高可用、性能可监控、问题可追溯、知识可更新。不适合什么场景对实时性要求极高的场景复杂的 RAG 检索和 Agent 思考链可能带来秒级延迟不适合高频交易等场景。知识极度动态变化的领域如果核心知识每天剧烈变动需要极高频的知识库更新策略运维复杂度高。预算和团队资源极其有限完整的 Agentic RAG with Ops 体系涉及多个子系统需要一定的开发和运维投入。合规与安全边界数据安全法律文档通常涉密。必须确保知识库部署在私有环境向量数据库和模型服务均不外泄。内容合规Agent 生成的内容尤其是法律建议必须明确标注“辅助参考不构成正式法律意见”并建立人工审核机制。审计溯源Ops 系统必须记录每一次问答的完整链路用户问题、检索到的源文档、Agent 的思考过程、最终答案。以满足合规审计要求。3. 环境准备与前置条件在开始编码之前需要准备好以下环境。这是一个通用清单具体版本需根据你选择的技术栈调整。操作系统推荐 Linux (Ubuntu 20.04/22.04 LTS) 或 macOSWindows 可通过 WSL2 进行开发。Python 环境Python 3.9 - 3.11。建议使用conda或venv创建虚拟环境。基础依赖pip包管理工具。Docker与docker-compose用于容器化部署向量数据库和监控组件。Git用于代码版本管理。硬件资源评估开发测试环境16GB 以上内存100GB 可用磁盘空间用于存放模型和知识库。如果有 NVIDIA GPU显存 8GB 以上将显著加速嵌入模型和本地 LLM 的推理。生产环境需要根据用户量、知识库大小、响应延迟要求进行专项评估。通常需要独立的服务器或 K8s 集群。网络访问如果计划使用 OpenAI GPT-4、Claude 等云端大模型 API需要确保网络能够稳定访问。4. 安装部署与启动方式我们将系统拆分为三个部分来部署知识库RAG、智能体服务Agent、运维监控Ops。这里给出一个基于 Docker 和 Python 的通用部署示例。4.1 知识库 (RAG) 服务部署我们以使用Chroma轻量级向量数据库和sentence-transformers嵌入模型为例。# 1. 创建项目目录并进入 mkdir legal-ai-system cd legal-ai-system mkdir -p rag_service knowledge_base # 2. 创建 RAG 服务依赖文件 rag_service/requirements.txt cat rag_service/requirements.txt EOF fastapi0.104.1 uvicorn[standard]0.24.0 chromadb0.4.22 sentence-transformers2.2.2 pypdf3.17.4 python-docx1.1.0 langchain0.1.0 EOF # 3. 创建简单的 RAG 服务主文件 rag_service/main.py # 此处为示例代码实际需要完善文档加载、切分、向量化等逻辑 cat rag_service/main.py EOF from fastapi import FastAPI, HTTPException from pydantic import BaseModel import chromadb from sentence_transformers import SentenceTransformer import os app FastAPI(titleRAG Service) # 初始化嵌入模型 embed_model SentenceTransformer(paraphrase-multilingual-MiniLM-L12-v2) # 可选其他模型 # 初始化Chroma客户端 chroma_client chromadb.PersistentClient(path./chroma_db) collection chroma_client.get_or_create_collection(namelegal_docs) class QueryRequest(BaseModel): question: str top_k: int 3 app.post(/retrieve) async def retrieve_docs(request: QueryRequest): try: # 将问题转换为向量 query_embedding embed_model.encode(request.question).tolist() # 在向量数据库中检索 results collection.query( query_embeddings[query_embedding], n_resultsrequest.top_k ) # 返回检索到的文档片段和元数据 return { documents: results[documents][0], metadatas: results[metadatas][0], distances: results[distances][0] } except Exception as e: raise HTTPException(status_code500, detailstr(e)) if __name__ __main__: import uvicorn uvicorn.run(app, host0.0.0.0, port8001) EOF # 4. 启动 RAG 服务 (在虚拟环境中) cd rag_service pip install -r requirements.txt python main.py # 服务将在 http://127.0.0.1:8001 启动4.2 智能体 (Agent) 服务部署Agent 服务作为主入口调用 LLM 和 RAG 服务。这里以使用LangChain和FastAPI为例。# 在项目根目录 legal-ai-system 下 mkdir agent_service cd agent_service # 创建 Agent 服务依赖文件 agent_service/requirements.txt cat agent_service/requirements.txt EOF fastapi0.104.1 uvicorn[standard]0.24.0 langchain0.1.0 langchain-openai0.0.2 # 如果使用OpenAI # langchain-community 包含很多工具和集成 requests2.31.0 EOF # 创建 Agent 服务主文件 agent_service/main.py cat agent_service/main.py EOF from fastapi import FastAPI, HTTPException from pydantic import BaseModel from langchain.agents import initialize_agent, AgentType from langchain.tools import Tool from langchain_openai import ChatOpenAI # 示例用OpenAI可替换为其他LLM import requests import os app FastAPI(titleAgent Service) # 初始化LLM (示例需配置API KEY) llm ChatOpenAI( modelgpt-4-turbo-preview, temperature0, openai_api_keyos.getenv(OPENAI_API_KEY) ) # 定义 RAG 工具函数 def retrieve_legal_docs(question: str) - str: 调用RAG服务检索相关法律文档。 try: resp requests.post( http://127.0.0.1:8001/retrieve, json{question: question, top_k: 3}, timeout30 ) resp.raise_for_status() data resp.json() # 将检索结果格式化为字符串 contexts [] for doc, meta in zip(data[documents], data[metadatas]): contexts.append(f来源{meta.get(source, 未知)}\\n内容{doc[:500]}...) # 截取部分 return \\n\\n.join(contexts) if contexts else 未检索到相关文档。 except Exception as e: return f检索失败{str(e)} # 将函数包装成LangChain Tool tools [ Tool( nameLegalDocRetriever, funcretrieve_legal_docs, description当问题涉及法律条文、合同条款、案例等专业知识时使用此工具检索相关文档。输入应为具体的问题或关键词。 ), # 可以在此添加更多工具如计算器、网络搜索等 ] # 初始化Agent agent initialize_agent( tools, llm, agentAgentType.ZERO_SHOT_REACT_DESCRIPTION, # 选择一种Agent类型 verboseTrue, handle_parsing_errorsTrue ) class AgentRequest(BaseModel): query: str conversation_id: str None # 用于支持多轮对话 app.post(/chat) async def chat_with_agent(request: AgentRequest): try: # 这里可以加入对话历史管理逻辑 response agent.run(request.query) return { conversation_id: request.conversation_id, answer: response, status: success } except Exception as e: raise HTTPException(status_code500, detailfAgent执行失败: {str(e)}) if __name__ __main__: import uvicorn uvicorn.run(app, host0.0.0.0, port8000) EOF # 启动 Agent 服务 (需先设置 OPENAI_API_KEY 环境变量) cd agent_service export OPENAI_API_KEYyour-api-key-here # 实际使用时请妥善管理密钥 pip install -r requirements.txt python main.py # 服务将在 http://127.0.0.1:8000 启动4.3 运维监控 (Ops) 基础搭建使用Docker Compose快速启动 Prometheus 和 Grafana 来监控服务。# 在项目根目录 legal-ai-system 下创建 docker-compose-monitor.yml version: 3.8 services: prometheus: image: prom/prometheus:latest container_name: prometheus volumes: - ./ops/prometheus.yml:/etc/prometheus/prometheus.yml - prom_data:/prometheus command: - --config.file/etc/prometheus/prometheus.yml - --storage.tsdb.path/prometheus - --web.console.libraries/etc/prometheus/console_libraries - --web.console.templates/etc/prometheus/consoles - --storage.tsdb.retention.time200h - --web.enable-lifecycle ports: - 9090:9090 restart: unless-stopped grafana: image: grafana/grafana:latest container_name: grafana volumes: - grafana_data:/var/lib/grafana - ./ops/grafana/provisioning:/etc/grafana/provisioning environment: - GF_SECURITY_ADMIN_PASSWORDadmin # 首次登录密码请修改 ports: - 3000:3000 restart: unless-stopped depends_on: - prometheus volumes: prom_data: grafana_data:# 创建 Prometheus 配置 ./ops/prometheus.yml global: scrape_interval: 15s evaluation_interval: 15s scrape_configs: - job_name: agent-service static_configs: - targets: [host.docker.internal:8000] # 监控Agent服务宿主机IP labels: service: legal-ai-agent - job_name: rag-service static_configs: - targets: [host.docker.internal:8001] # 监控RAG服务 labels: service: legal-ai-rag - job_name: prometheus static_configs: - targets: [localhost:9090]启动监控栈cd legal-ai-system docker-compose -f docker-compose-monitor.yml up -d访问http://localhost:3000登录 Grafana (用户名 admin密码 admin)即可配置仪表盘监控服务状态。5. 功能测试与效果验证系统启动后我们需要验证核心链路是否打通用户提问 - Agent 接收 - 调用 RAG 工具 - 获取知识 - 合成答案。5.1 知识库灌入与检索测试首先确保 RAG 服务中有数据。# test_rag_ingestion.py - 一个简单的知识灌入脚本示例 from sentence_transformers import SentenceTransformer import chromadb from langchain.text_splitter import RecursiveCharacterTextSplitter import PyPDF2 # 示例实际需处理多种格式 # 1. 初始化 embedder SentenceTransformer(paraphrase-multilingual-MiniLM-L12-v2) chroma_client chromadb.PersistentClient(path./chroma_db) collection chroma_client.get_or_create_collection(namelegal_docs) # 2. 模拟读取一个PDF文档并切分 def extract_text_from_pdf(pdf_path): # 简化的提取逻辑 with open(pdf_path, rb) as file: reader PyPDF2.PdfReader(file) text for page in reader.pages: text page.extract_text() return text # 假设有一个合同范本PDF raw_text extract_text_from_pdf(./knowledge_base/sample_contract.pdf) text_splitter RecursiveCharacterTextSplitter(chunk_size500, chunk_overlap50) chunks text_splitter.split_text(raw_text) # 3. 生成向量并存入数据库 ids [fchunk_{i} for i in range(len(chunks))] embeddings embedder.encode(chunks).tolist() metadatas [{source: sample_contract.pdf, chunk_id: i} for i in range(len(chunks))] collection.add( documentschunks, embeddingsembeddings, metadatasmetadatas, idsids ) print(f已成功灌入 {len(chunks)} 个文本片段。)然后测试检索功能curl -X POST http://127.0.0.1:8001/retrieve \ -H Content-Type: application/json \ -d {question: 合同中关于违约责任是如何规定的, top_k: 2}预期返回包含相关合同条款片段的 JSON 数据。5.2 Agent 端到端问答测试通过 Agent 服务的接口提问观察其是否会正确调用 RAG 工具。curl -X POST http://127.0.0.1:8000/chat \ -H Content-Type: application/json \ -d {query: 请根据我们的知识库告诉我如果甲方逾期付款需要承担什么责任}成功验证的标志Agent 服务日志中应显示类似Invoking: LegalDocRetriever with args...的条目表明它识别出需要专业知识并调用了工具。RAG 服务日志中应显示接收到检索请求并返回结果。最终返回的答案应包含从知识库中检索到的具体条款内容并且答案的表述是基于这些内容的合理总结或解释而不是凭空生成。答案中最好能附带引用来源如文档名和片段ID这需要在 Agent 输出格式中设计。5.3 复杂任务分解测试测试 Agent 处理多步骤任务的能力。curl -X POST http://127.0.0.1:8000/chat \ -H Content-Type: application/json \ -d {query: 先帮我找一下关于知识产权归属的条款然后总结一下其中涉及软件著作权部分的核心要点。}验证点任务规划Agent 是否理解这是两个连续的子任务检索 - 总结。工具调用顺序是否先调用LegalDocRetriever获取相关条款。信息整合LLM 是否能在检索结果的基础上进行准确的要点总结。6. 接口 API 与批量任务6.1 服务接口标准化上述部署的 Agent 和 RAG 服务都提供了 HTTP API。为了生产环境需要增加认证鉴权在 FastAPI 中添加 API Key 验证或 JWT 认证。限流使用中间件限制请求频率防止滥用。更完善的输入输出支持流式输出Streaming、更丰富的上下文管理。6.2 批量任务处理对于需要批量处理大量文档或问题的场景如批量合同审查需要设计异步任务队列。简易实现思路创建一个新的batch_service接收包含多个问题的任务列表。使用CeleryRedis或RQ作为任务队列。将每个问题作为独立任务发布到队列由 Worker 调用 Agent 服务处理。提供任务状态查询和结果收集接口。# 伪代码示例批量任务提交 from celery import Celery app Celery(legal_ai_tasks, brokerredis://localhost:6379/0) app.task def process_legal_query(query_text, query_id): # 调用 Agent 服务 result call_agent_service(query_text) # 将结果存储到数据库 save_result_to_db(query_id, result) return result # 在API中提交批量任务 def submit_batch(questions): task_ids [] for q in questions: task process_legal_query.delay(q[text], q[id]) task_ids.append(task.id) return {batch_id: str(uuid.uuid4()), task_ids: task_ids}7. 资源占用与性能观察系统运行后需要关注以下关键指标RAG 服务性能检索延迟从发起请求到返回结果的时间。受嵌入模型推理速度、向量数据库索引规模影响。内存占用向量数据库加载索引后常驻内存的大小。观察方法在 RAG 服务代码中添加请求耗时日志并通过 Prometheus 暴露自定义指标如rag_retrieve_duration_seconds。Agent (LLM) 服务性能Token 消耗与成本如果使用云端 API这是主要成本。需要监控每次对话的输入/输出 token 数。思考时间Agent 进行规划、调用工具、合成答案的总耗时。工具调用次数频繁调用工具会增加延迟和成本。观察方法使用 LangChain 的回调Callbacks或自行在工具调用前后打点记录时间戳和 token 数并发送到监控系统。系统整体资源CPU/内存使用docker stats或宿主机监控工具查看。GPU 显存如果本地运行嵌入模型或 LLM使用nvidia-smi命令监控。网络 I/O监控服务间Agent - RAG的通信流量。性能优化方向RAG 侧优化文本切分策略chunk size/overlap选择更高效的嵌入模型对向量数据库进行索引优化。Agent 侧优化提示词Prompt以减少不必要的思考步骤对常用工具的结果进行缓存设置超时和重试机制。架构侧对于高并发场景考虑对 RAG 服务和 LLM 调用进行水平扩展。8. 常见问题与排查方法在开发和运行过程中你可能会遇到以下典型问题问题现象可能原因排查方式解决方案Agent 服务启动失败提示 LLM 连接错误1. API Key 未设置或错误。2. 网络无法访问 LLM 服务商。3. 本地 LLM 模型路径错误或未加载。1. 检查环境变量OPENAI_API_KEY等。2. 使用curl或ping测试网络连通性。3. 检查本地模型文件是否存在查看日志错误。1. 正确配置 API Key。2. 解决网络问题或使用代理。3. 确认模型路径检查 CUDA/driver 版本。RAG 检索返回空结果或无关结果1. 知识库未灌入数据或灌入失败。2. 文本切分不合理导致信息碎片化。3. 嵌入模型不匹配入库和查询用的模型不同。4. 检索 top_k 参数太小或相似度阈值太高。1. 检查向量数据库集合collection内文档数量。2. 检查原始文档内容和切分后的 chunk。3. 确认入库和查询使用的是同一个嵌入模型实例。4. 调整检索参数。1. 重新灌入数据并确认成功。2. 调整 chunk size 和 overlap或尝试语义切分。3. 确保嵌入模型单例化。4. 增大 top_k或使用混合检索向量关键词。Agent 不调用 RAG 工具直接胡编乱造1. 工具Tool的描述description不够清晰LLM无法理解何时使用。2. Agent 类型如ZERO_SHOT_REACT_DESCRIPTION不适合当前任务。3. 提示词Prompt中未强调“必须使用工具”。1. 查看 Agent 运行时的详细日志verboseTrue观察其“思考”过程。2. 检查工具描述是否准确说明了适用场景。1. 优化工具描述使其更精确。2. 尝试更换 Agent 类型如STRUCTURED_CHAT_ZERO_SHOT_REACT_DESCRIPTION。3. 在系统提示词中强制要求“在回答专业问题时务必先使用 LegalDocRetriever 工具查找依据”。服务间歇性超时或无响应1. LLM API 调用超时。2. RAG 检索过程过慢。3. 系统资源内存、CPU耗尽。4. 网络波动。1. 查看各服务日志中的超时错误。2. 监控系统资源使用情况。3. 使用链路追踪如 OpenTelemetry定位慢请求。1. 为 LLM 和 RAG 调用设置合理的超时时间并实现重试机制。2. 优化检索性能或对服务进行扩容。3. 增加资源或优化代码。4. 确保内网服务间通信稳定。监控 Grafana 中看不到数据1. Prometheus 未正确抓取服务指标。2. 服务未暴露 Prometheus 格式的 metrics 接口。3. 网络策略阻止访问。1. 检查 Prometheus 靶机配置prometheus.yml中的targetsIP 和端口是否正确。2. 访问服务的/metrics端点如果已暴露看是否有数据。3. 检查 Docker 网络或防火墙设置。1. 修正 Prometheus 配置重启服务。2. 在 Python 服务中使用prometheus_client库暴露指标。3. 调整网络配置确保 Prometheus 容器能访问到宿主机的服务端口。9. 最佳实践与使用建议基于实战经验总结以下几点建议帮助你更稳健地运行系统从小范围、高质量数据开始不要一开始就导入所有历史文档。选择一小部分如 100 份高质量、结构清晰的文档构建 MVP 知识库快速验证流程和效果。建立效果评估基线设计一个测试集QA Pair定期如每周运行量化评估系统回答的准确率、相关性和有用性。这是 Ops 闭环的关键。实现知识库的版本化和增量更新法律条文会更新合同范本会迭代。设计一套流程当源文档更新时能自动或半自动地更新向量数据库中的对应部分而不是全量重建。Agent 的提示词工程是核心投入时间精心设计系统提示词System Prompt明确其角色、职责、工具使用规范和输出格式要求。这是控制 Agent 行为性价比最高的方式。做好日志和审计记录每一次用户交互的完整轨迹原始问题、Agent 的思考链Chain of Thought、调用的工具及参数、工具返回结果、最终答案。这不仅是排查问题的依据也是效果分析和合规审计的必需品。安全前置输入过滤对用户输入进行敏感词过滤和恶意指令检测。输出审查对于高风险领域如法律意见建立最终答案的人工审核或强提示机制。权限控制不同角色的用户可能访问不同的知识库子集需要在 RAG 检索层或 Agent 调度层实现权限过滤。成本监控如果使用按 token 计费的云端 LLM必须建立成本监控告警避免意外的高额账单。可以设置每日/每周预算阈值。10. 总结与下一步这个“律所 AI 实战”项目清晰地展示了 Agent、RAG 和 Ops 如何各司其职又紧密协作将一个概念性的 AI 应用转化为可运行、可观测、可迭代的生产系统。最值得尝试的点在于你通过这个模式为专业大模型应用构建了一个可复用的技术框架。最先应该验证的功能是 RAG 检索的准确性和 Agent 调用工具的可靠性。找一个具体的业务问题确保从文档中能“捞”出正确答案并且 Agent 能“想到”去捞。这是整个系统价值的基石。最容易踩的坑往往在“对接”环节Agent 的工具描述没写好导致不调用向量数据库的嵌入模型版本不一致导致检索失效服务间网络超时导致整体失败。因此在开发初期就要为每个环节设计完备的日志和错误处理。后续可以继续扩展的方向很多多模态 RAG支持从合同扫描件图像中提取文字和表格信息。更复杂的 Agent 编排引入支持并行执行、条件判断的工作流引擎。自动化评估与再训练利用用户对回答的反馈点赞/点踩自动优化检索排序或微调嵌入模型。与现有业务系统集成将 AI 服务嵌入到律所内部的案件管理或 OA 系统中。这套架构不仅适用于法律行业任何需要结合专业知识库进行复杂问答和任务处理的领域如金融、医疗、客服、内部 IT 支持都可以借鉴。关键在于理解 Agent、RAG、Ops 这三个核心组件的职责和交互方式然后根据自身业务需求进行定制和填充。建议收藏本文在搭建你自己的专业 AI 系统时对照每个环节进行设计和验证。 企业级AI实战：Agent、RAG与Ops技术栈整合落地指南
这次我们来看一个律所 AI 实战项目。它不是某个具体的开源工具而是一个将 Agent智能体、RAG检索增强生成和 Ops运维/运营三大技术栈整合落地的工程实践案例。对于想在企业级场景尤其是法律、金融、咨询等专业领域应用大模型的技术团队来说这个打通链路的过程极具参考价值。核心问题很直接如何让大模型在专业领域“靠谱”地工作单纯调 API 回答通用问题远远不够。你需要它理解复杂的专业文档能进行多步骤推理和任务分解并且整个系统要稳定、可监控、可迭代。这就是 Agent、RAG 和 Ops 需要协同发力的地方。本文会带你拆解这个实战项目的核心架构重点关注三者是如何“打通”的。我们会从技术选型、环境搭建、功能验证到运维监控一步步还原一个可落地的工程路径。无论你是想构建内部知识问答系统、合同审核助手还是客户服务自动化流程这篇文章提供的思路和踩坑经验都能直接复用。1. 核心能力速览技术栈如何分工协作首先明确 Agent、RAG、Ops 在这个实战项目中的角色和协作关系。下表概括了它们的分工与集成点技术组件核心职责在本项目中的具体实现硬件/环境依赖RAG (检索增强生成)知识供给从海量、非结构化的专业文档如法律条文、判例、合同范本中精准检索相关信息作为大模型生成答案的依据。构建本地化知识库可能使用向量数据库如 Milvus, Chroma, Qdrant结合全文检索。处理 PDF、Word、扫描件等格式。依赖嵌入模型Embedding Model和向量数据库服务。GPU可加速嵌入生成CPU也可运行。内存和磁盘空间取决于知识库规模。Agent (智能体)大脑与执行接收用户复杂问题进行意图理解、任务规划、工具调用如调用RAG检索、计算、搜索、多轮对话和结果合成。基于大语言模型如 GPT-4, Claude, 或本地部署的 Llama 3、Qwen等构建使用 LangChain、LlamaIndex 或自主开发的框架进行编排。主要依赖大语言模型的推理能力。如果使用云端API则对本地硬件要求低如果本地部署LLM则对GPU显存要求高通常7B模型需6-8G70B模型需更高。Ops (运维/运营)系统保障与优化确保整个AI服务稳定、可靠、可监控、可迭代。包括服务部署、性能监控、日志审计、效果评估、知识库更新、安全管控等。通过 Docker 容器化部署、Prometheus/Grafana 监控指标、ELK 收集日志、构建评估管道Evaluation Pipeline对回答质量进行打分和反馈循环。依赖标准的运维基础设施服务器、Docker环境、监控栈。对硬件无特殊要求但需要规划好资源。打通的关键在于Agent 作为总控在需要专业知识时调用 RAG 工具Ops 体系则监控整个调用链路的健康度、效果和成本并驱动知识库与 Agent 的持续优化。下面我们就从零开始看看如何搭建这样一个系统。2. 适用场景与使用边界适合谁用法律科技团队构建内部案例检索系统、合同智能审查工具、法律咨询辅助助手。企业IT与业务部门需要处理大量内部规章、产品手册、历史工单并希望提供智能问答支持。AI 应用开发者希望深入理解 Agentic RAG 系统的完整落地流程而不仅仅是 Demo 级别。技术负责人/架构师评估在专业领域引入大模型方案的技术路径、资源投入和风险点。能解决什么问题解决“幻觉”问题通过 RAG 提供精准的文档依据让大模型的回答有据可查减少胡编乱造。处理复杂长流程任务用户一个问题可能涉及多个子任务如“检索某类合同范本并对比其中甲乙双方责任条款”Agent 可以自动规划分解并执行。保障系统稳定性通过 Ops 体系实现服务高可用、性能可监控、问题可追溯、知识可更新。不适合什么场景对实时性要求极高的场景复杂的 RAG 检索和 Agent 思考链可能带来秒级延迟不适合高频交易等场景。知识极度动态变化的领域如果核心知识每天剧烈变动需要极高频的知识库更新策略运维复杂度高。预算和团队资源极其有限完整的 Agentic RAG with Ops 体系涉及多个子系统需要一定的开发和运维投入。合规与安全边界数据安全法律文档通常涉密。必须确保知识库部署在私有环境向量数据库和模型服务均不外泄。内容合规Agent 生成的内容尤其是法律建议必须明确标注“辅助参考不构成正式法律意见”并建立人工审核机制。审计溯源Ops 系统必须记录每一次问答的完整链路用户问题、检索到的源文档、Agent 的思考过程、最终答案。以满足合规审计要求。3. 环境准备与前置条件在开始编码之前需要准备好以下环境。这是一个通用清单具体版本需根据你选择的技术栈调整。操作系统推荐 Linux (Ubuntu 20.04/22.04 LTS) 或 macOSWindows 可通过 WSL2 进行开发。Python 环境Python 3.9 - 3.11。建议使用conda或venv创建虚拟环境。基础依赖pip包管理工具。Docker与docker-compose用于容器化部署向量数据库和监控组件。Git用于代码版本管理。硬件资源评估开发测试环境16GB 以上内存100GB 可用磁盘空间用于存放模型和知识库。如果有 NVIDIA GPU显存 8GB 以上将显著加速嵌入模型和本地 LLM 的推理。生产环境需要根据用户量、知识库大小、响应延迟要求进行专项评估。通常需要独立的服务器或 K8s 集群。网络访问如果计划使用 OpenAI GPT-4、Claude 等云端大模型 API需要确保网络能够稳定访问。4. 安装部署与启动方式我们将系统拆分为三个部分来部署知识库RAG、智能体服务Agent、运维监控Ops。这里给出一个基于 Docker 和 Python 的通用部署示例。4.1 知识库 (RAG) 服务部署我们以使用Chroma轻量级向量数据库和sentence-transformers嵌入模型为例。# 1. 创建项目目录并进入 mkdir legal-ai-system cd legal-ai-system mkdir -p rag_service knowledge_base # 2. 创建 RAG 服务依赖文件 rag_service/requirements.txt cat rag_service/requirements.txt EOF fastapi0.104.1 uvicorn[standard]0.24.0 chromadb0.4.22 sentence-transformers2.2.2 pypdf3.17.4 python-docx1.1.0 langchain0.1.0 EOF # 3. 创建简单的 RAG 服务主文件 rag_service/main.py # 此处为示例代码实际需要完善文档加载、切分、向量化等逻辑 cat rag_service/main.py EOF from fastapi import FastAPI, HTTPException from pydantic import BaseModel import chromadb from sentence_transformers import SentenceTransformer import os app FastAPI(titleRAG Service) # 初始化嵌入模型 embed_model SentenceTransformer(paraphrase-multilingual-MiniLM-L12-v2) # 可选其他模型 # 初始化Chroma客户端 chroma_client chromadb.PersistentClient(path./chroma_db) collection chroma_client.get_or_create_collection(namelegal_docs) class QueryRequest(BaseModel): question: str top_k: int 3 app.post(/retrieve) async def retrieve_docs(request: QueryRequest): try: # 将问题转换为向量 query_embedding embed_model.encode(request.question).tolist() # 在向量数据库中检索 results collection.query( query_embeddings[query_embedding], n_resultsrequest.top_k ) # 返回检索到的文档片段和元数据 return { documents: results[documents][0], metadatas: results[metadatas][0], distances: results[distances][0] } except Exception as e: raise HTTPException(status_code500, detailstr(e)) if __name__ __main__: import uvicorn uvicorn.run(app, host0.0.0.0, port8001) EOF # 4. 启动 RAG 服务 (在虚拟环境中) cd rag_service pip install -r requirements.txt python main.py # 服务将在 http://127.0.0.1:8001 启动4.2 智能体 (Agent) 服务部署Agent 服务作为主入口调用 LLM 和 RAG 服务。这里以使用LangChain和FastAPI为例。# 在项目根目录 legal-ai-system 下 mkdir agent_service cd agent_service # 创建 Agent 服务依赖文件 agent_service/requirements.txt cat agent_service/requirements.txt EOF fastapi0.104.1 uvicorn[standard]0.24.0 langchain0.1.0 langchain-openai0.0.2 # 如果使用OpenAI # langchain-community 包含很多工具和集成 requests2.31.0 EOF # 创建 Agent 服务主文件 agent_service/main.py cat agent_service/main.py EOF from fastapi import FastAPI, HTTPException from pydantic import BaseModel from langchain.agents import initialize_agent, AgentType from langchain.tools import Tool from langchain_openai import ChatOpenAI # 示例用OpenAI可替换为其他LLM import requests import os app FastAPI(titleAgent Service) # 初始化LLM (示例需配置API KEY) llm ChatOpenAI( modelgpt-4-turbo-preview, temperature0, openai_api_keyos.getenv(OPENAI_API_KEY) ) # 定义 RAG 工具函数 def retrieve_legal_docs(question: str) - str: 调用RAG服务检索相关法律文档。 try: resp requests.post( http://127.0.0.1:8001/retrieve, json{question: question, top_k: 3}, timeout30 ) resp.raise_for_status() data resp.json() # 将检索结果格式化为字符串 contexts [] for doc, meta in zip(data[documents], data[metadatas]): contexts.append(f来源{meta.get(source, 未知)}\\n内容{doc[:500]}...) # 截取部分 return \\n\\n.join(contexts) if contexts else 未检索到相关文档。 except Exception as e: return f检索失败{str(e)} # 将函数包装成LangChain Tool tools [ Tool( nameLegalDocRetriever, funcretrieve_legal_docs, description当问题涉及法律条文、合同条款、案例等专业知识时使用此工具检索相关文档。输入应为具体的问题或关键词。 ), # 可以在此添加更多工具如计算器、网络搜索等 ] # 初始化Agent agent initialize_agent( tools, llm, agentAgentType.ZERO_SHOT_REACT_DESCRIPTION, # 选择一种Agent类型 verboseTrue, handle_parsing_errorsTrue ) class AgentRequest(BaseModel): query: str conversation_id: str None # 用于支持多轮对话 app.post(/chat) async def chat_with_agent(request: AgentRequest): try: # 这里可以加入对话历史管理逻辑 response agent.run(request.query) return { conversation_id: request.conversation_id, answer: response, status: success } except Exception as e: raise HTTPException(status_code500, detailfAgent执行失败: {str(e)}) if __name__ __main__: import uvicorn uvicorn.run(app, host0.0.0.0, port8000) EOF # 启动 Agent 服务 (需先设置 OPENAI_API_KEY 环境变量) cd agent_service export OPENAI_API_KEYyour-api-key-here # 实际使用时请妥善管理密钥 pip install -r requirements.txt python main.py # 服务将在 http://127.0.0.1:8000 启动4.3 运维监控 (Ops) 基础搭建使用Docker Compose快速启动 Prometheus 和 Grafana 来监控服务。# 在项目根目录 legal-ai-system 下创建 docker-compose-monitor.yml version: 3.8 services: prometheus: image: prom/prometheus:latest container_name: prometheus volumes: - ./ops/prometheus.yml:/etc/prometheus/prometheus.yml - prom_data:/prometheus command: - --config.file/etc/prometheus/prometheus.yml - --storage.tsdb.path/prometheus - --web.console.libraries/etc/prometheus/console_libraries - --web.console.templates/etc/prometheus/consoles - --storage.tsdb.retention.time200h - --web.enable-lifecycle ports: - 9090:9090 restart: unless-stopped grafana: image: grafana/grafana:latest container_name: grafana volumes: - grafana_data:/var/lib/grafana - ./ops/grafana/provisioning:/etc/grafana/provisioning environment: - GF_SECURITY_ADMIN_PASSWORDadmin # 首次登录密码请修改 ports: - 3000:3000 restart: unless-stopped depends_on: - prometheus volumes: prom_data: grafana_data:# 创建 Prometheus 配置 ./ops/prometheus.yml global: scrape_interval: 15s evaluation_interval: 15s scrape_configs: - job_name: agent-service static_configs: - targets: [host.docker.internal:8000] # 监控Agent服务宿主机IP labels: service: legal-ai-agent - job_name: rag-service static_configs: - targets: [host.docker.internal:8001] # 监控RAG服务 labels: service: legal-ai-rag - job_name: prometheus static_configs: - targets: [localhost:9090]启动监控栈cd legal-ai-system docker-compose -f docker-compose-monitor.yml up -d访问http://localhost:3000登录 Grafana (用户名 admin密码 admin)即可配置仪表盘监控服务状态。5. 功能测试与效果验证系统启动后我们需要验证核心链路是否打通用户提问 - Agent 接收 - 调用 RAG 工具 - 获取知识 - 合成答案。5.1 知识库灌入与检索测试首先确保 RAG 服务中有数据。# test_rag_ingestion.py - 一个简单的知识灌入脚本示例 from sentence_transformers import SentenceTransformer import chromadb from langchain.text_splitter import RecursiveCharacterTextSplitter import PyPDF2 # 示例实际需处理多种格式 # 1. 初始化 embedder SentenceTransformer(paraphrase-multilingual-MiniLM-L12-v2) chroma_client chromadb.PersistentClient(path./chroma_db) collection chroma_client.get_or_create_collection(namelegal_docs) # 2. 模拟读取一个PDF文档并切分 def extract_text_from_pdf(pdf_path): # 简化的提取逻辑 with open(pdf_path, rb) as file: reader PyPDF2.PdfReader(file) text for page in reader.pages: text page.extract_text() return text # 假设有一个合同范本PDF raw_text extract_text_from_pdf(./knowledge_base/sample_contract.pdf) text_splitter RecursiveCharacterTextSplitter(chunk_size500, chunk_overlap50) chunks text_splitter.split_text(raw_text) # 3. 生成向量并存入数据库 ids [fchunk_{i} for i in range(len(chunks))] embeddings embedder.encode(chunks).tolist() metadatas [{source: sample_contract.pdf, chunk_id: i} for i in range(len(chunks))] collection.add( documentschunks, embeddingsembeddings, metadatasmetadatas, idsids ) print(f已成功灌入 {len(chunks)} 个文本片段。)然后测试检索功能curl -X POST http://127.0.0.1:8001/retrieve \ -H Content-Type: application/json \ -d {question: 合同中关于违约责任是如何规定的, top_k: 2}预期返回包含相关合同条款片段的 JSON 数据。5.2 Agent 端到端问答测试通过 Agent 服务的接口提问观察其是否会正确调用 RAG 工具。curl -X POST http://127.0.0.1:8000/chat \ -H Content-Type: application/json \ -d {query: 请根据我们的知识库告诉我如果甲方逾期付款需要承担什么责任}成功验证的标志Agent 服务日志中应显示类似Invoking: LegalDocRetriever with args...的条目表明它识别出需要专业知识并调用了工具。RAG 服务日志中应显示接收到检索请求并返回结果。最终返回的答案应包含从知识库中检索到的具体条款内容并且答案的表述是基于这些内容的合理总结或解释而不是凭空生成。答案中最好能附带引用来源如文档名和片段ID这需要在 Agent 输出格式中设计。5.3 复杂任务分解测试测试 Agent 处理多步骤任务的能力。curl -X POST http://127.0.0.1:8000/chat \ -H Content-Type: application/json \ -d {query: 先帮我找一下关于知识产权归属的条款然后总结一下其中涉及软件著作权部分的核心要点。}验证点任务规划Agent 是否理解这是两个连续的子任务检索 - 总结。工具调用顺序是否先调用LegalDocRetriever获取相关条款。信息整合LLM 是否能在检索结果的基础上进行准确的要点总结。6. 接口 API 与批量任务6.1 服务接口标准化上述部署的 Agent 和 RAG 服务都提供了 HTTP API。为了生产环境需要增加认证鉴权在 FastAPI 中添加 API Key 验证或 JWT 认证。限流使用中间件限制请求频率防止滥用。更完善的输入输出支持流式输出Streaming、更丰富的上下文管理。6.2 批量任务处理对于需要批量处理大量文档或问题的场景如批量合同审查需要设计异步任务队列。简易实现思路创建一个新的batch_service接收包含多个问题的任务列表。使用CeleryRedis或RQ作为任务队列。将每个问题作为独立任务发布到队列由 Worker 调用 Agent 服务处理。提供任务状态查询和结果收集接口。# 伪代码示例批量任务提交 from celery import Celery app Celery(legal_ai_tasks, brokerredis://localhost:6379/0) app.task def process_legal_query(query_text, query_id): # 调用 Agent 服务 result call_agent_service(query_text) # 将结果存储到数据库 save_result_to_db(query_id, result) return result # 在API中提交批量任务 def submit_batch(questions): task_ids [] for q in questions: task process_legal_query.delay(q[text], q[id]) task_ids.append(task.id) return {batch_id: str(uuid.uuid4()), task_ids: task_ids}7. 资源占用与性能观察系统运行后需要关注以下关键指标RAG 服务性能检索延迟从发起请求到返回结果的时间。受嵌入模型推理速度、向量数据库索引规模影响。内存占用向量数据库加载索引后常驻内存的大小。观察方法在 RAG 服务代码中添加请求耗时日志并通过 Prometheus 暴露自定义指标如rag_retrieve_duration_seconds。Agent (LLM) 服务性能Token 消耗与成本如果使用云端 API这是主要成本。需要监控每次对话的输入/输出 token 数。思考时间Agent 进行规划、调用工具、合成答案的总耗时。工具调用次数频繁调用工具会增加延迟和成本。观察方法使用 LangChain 的回调Callbacks或自行在工具调用前后打点记录时间戳和 token 数并发送到监控系统。系统整体资源CPU/内存使用docker stats或宿主机监控工具查看。GPU 显存如果本地运行嵌入模型或 LLM使用nvidia-smi命令监控。网络 I/O监控服务间Agent - RAG的通信流量。性能优化方向RAG 侧优化文本切分策略chunk size/overlap选择更高效的嵌入模型对向量数据库进行索引优化。Agent 侧优化提示词Prompt以减少不必要的思考步骤对常用工具的结果进行缓存设置超时和重试机制。架构侧对于高并发场景考虑对 RAG 服务和 LLM 调用进行水平扩展。8. 常见问题与排查方法在开发和运行过程中你可能会遇到以下典型问题问题现象可能原因排查方式解决方案Agent 服务启动失败提示 LLM 连接错误1. API Key 未设置或错误。2. 网络无法访问 LLM 服务商。3. 本地 LLM 模型路径错误或未加载。1. 检查环境变量OPENAI_API_KEY等。2. 使用curl或ping测试网络连通性。3. 检查本地模型文件是否存在查看日志错误。1. 正确配置 API Key。2. 解决网络问题或使用代理。3. 确认模型路径检查 CUDA/driver 版本。RAG 检索返回空结果或无关结果1. 知识库未灌入数据或灌入失败。2. 文本切分不合理导致信息碎片化。3. 嵌入模型不匹配入库和查询用的模型不同。4. 检索 top_k 参数太小或相似度阈值太高。1. 检查向量数据库集合collection内文档数量。2. 检查原始文档内容和切分后的 chunk。3. 确认入库和查询使用的是同一个嵌入模型实例。4. 调整检索参数。1. 重新灌入数据并确认成功。2. 调整 chunk size 和 overlap或尝试语义切分。3. 确保嵌入模型单例化。4. 增大 top_k或使用混合检索向量关键词。Agent 不调用 RAG 工具直接胡编乱造1. 工具Tool的描述description不够清晰LLM无法理解何时使用。2. Agent 类型如ZERO_SHOT_REACT_DESCRIPTION不适合当前任务。3. 提示词Prompt中未强调“必须使用工具”。1. 查看 Agent 运行时的详细日志verboseTrue观察其“思考”过程。2. 检查工具描述是否准确说明了适用场景。1. 优化工具描述使其更精确。2. 尝试更换 Agent 类型如STRUCTURED_CHAT_ZERO_SHOT_REACT_DESCRIPTION。3. 在系统提示词中强制要求“在回答专业问题时务必先使用 LegalDocRetriever 工具查找依据”。服务间歇性超时或无响应1. LLM API 调用超时。2. RAG 检索过程过慢。3. 系统资源内存、CPU耗尽。4. 网络波动。1. 查看各服务日志中的超时错误。2. 监控系统资源使用情况。3. 使用链路追踪如 OpenTelemetry定位慢请求。1. 为 LLM 和 RAG 调用设置合理的超时时间并实现重试机制。2. 优化检索性能或对服务进行扩容。3. 增加资源或优化代码。4. 确保内网服务间通信稳定。监控 Grafana 中看不到数据1. Prometheus 未正确抓取服务指标。2. 服务未暴露 Prometheus 格式的 metrics 接口。3. 网络策略阻止访问。1. 检查 Prometheus 靶机配置prometheus.yml中的targetsIP 和端口是否正确。2. 访问服务的/metrics端点如果已暴露看是否有数据。3. 检查 Docker 网络或防火墙设置。1. 修正 Prometheus 配置重启服务。2. 在 Python 服务中使用prometheus_client库暴露指标。3. 调整网络配置确保 Prometheus 容器能访问到宿主机的服务端口。9. 最佳实践与使用建议基于实战经验总结以下几点建议帮助你更稳健地运行系统从小范围、高质量数据开始不要一开始就导入所有历史文档。选择一小部分如 100 份高质量、结构清晰的文档构建 MVP 知识库快速验证流程和效果。建立效果评估基线设计一个测试集QA Pair定期如每周运行量化评估系统回答的准确率、相关性和有用性。这是 Ops 闭环的关键。实现知识库的版本化和增量更新法律条文会更新合同范本会迭代。设计一套流程当源文档更新时能自动或半自动地更新向量数据库中的对应部分而不是全量重建。Agent 的提示词工程是核心投入时间精心设计系统提示词System Prompt明确其角色、职责、工具使用规范和输出格式要求。这是控制 Agent 行为性价比最高的方式。做好日志和审计记录每一次用户交互的完整轨迹原始问题、Agent 的思考链Chain of Thought、调用的工具及参数、工具返回结果、最终答案。这不仅是排查问题的依据也是效果分析和合规审计的必需品。安全前置输入过滤对用户输入进行敏感词过滤和恶意指令检测。输出审查对于高风险领域如法律意见建立最终答案的人工审核或强提示机制。权限控制不同角色的用户可能访问不同的知识库子集需要在 RAG 检索层或 Agent 调度层实现权限过滤。成本监控如果使用按 token 计费的云端 LLM必须建立成本监控告警避免意外的高额账单。可以设置每日/每周预算阈值。10. 总结与下一步这个“律所 AI 实战”项目清晰地展示了 Agent、RAG 和 Ops 如何各司其职又紧密协作将一个概念性的 AI 应用转化为可运行、可观测、可迭代的生产系统。最值得尝试的点在于你通过这个模式为专业大模型应用构建了一个可复用的技术框架。最先应该验证的功能是 RAG 检索的准确性和 Agent 调用工具的可靠性。找一个具体的业务问题确保从文档中能“捞”出正确答案并且 Agent 能“想到”去捞。这是整个系统价值的基石。最容易踩的坑往往在“对接”环节Agent 的工具描述没写好导致不调用向量数据库的嵌入模型版本不一致导致检索失效服务间网络超时导致整体失败。因此在开发初期就要为每个环节设计完备的日志和错误处理。后续可以继续扩展的方向很多多模态 RAG支持从合同扫描件图像中提取文字和表格信息。更复杂的 Agent 编排引入支持并行执行、条件判断的工作流引擎。自动化评估与再训练利用用户对回答的反馈点赞/点踩自动优化检索排序或微调嵌入模型。与现有业务系统集成将 AI 服务嵌入到律所内部的案件管理或 OA 系统中。这套架构不仅适用于法律行业任何需要结合专业知识库进行复杂问答和任务处理的领域如金融、医疗、客服、内部 IT 支持都可以借鉴。关键在于理解 Agent、RAG、Ops 这三个核心组件的职责和交互方式然后根据自身业务需求进行定制和填充。建议收藏本文在搭建你自己的专业 AI 系统时对照每个环节进行设计和验证。