Kubeflow 文档 AI 助手
面向 Kubeflow 官网的 RAG 文档问答助手,提供语义检索、流式回答与结构化引用。
- Star 数
- ★ 46
- 最近更新
- 1 天前
- License
- Apache-2.0
- 主语言
- Python
- FA 评分
- 42/100 · 缺口较多
30 秒速览
- 运行形态
- 可在哪里用
- 平台专用OpenAI API(部分支持)
- 费用
- 软件免费,模型调用费用自付
- 上手难度
- 高 · 需要较重的基础设施
- 开始前需要
- 典型场景
- Kubeflow 平台运维人员收到用户提问“如何创建 pipeline”,希望获得带官方文档引用的准确回答。
- 不适合
- 没有 Kubernetes 集群或 GPU 节点的个人开发者
- 希望几分钟内在本地跑起来的用户
- 不接受自建 Milvus、KServe、KFP 等多套服务的团队
这个 Agent 能做什么,适合哪些场景?
这是 Kubeflow 文档助手的官方 LLM 实现,基于检索增强生成(RAG),让用户跨 Kubeflow 文档进行语义搜索并获得带上下文的回答。检索侧由 Milvus 承担,生产环境使用 RAG v4 混合检索:768 维 MPNet 稠密向量加原生 BM25 稀疏向量,并带类型化的 release_date 字段。生成侧由 KServe 上的 vLLM 后端提供 Llama 3.1-8B-Instruct(RedHatAI/Llama-3.1-8B-Instruct),开启自动工具调用与 llama3_json 解析器。数据接入由 Kubeflow Pipelines 完成,包括仓库抓取、规范化解析与分块、调用集群内 TEI 服务生成向量、最后写入 Milvus 的 v4 混合 schema。对外接口有两套:server/app.py 的 WebSocket API 和 server-https/app.py 的 FastAPI HTTPS API,均支持流式与非流式响应、工具调用和引用自动收集去重。仓库还包含 MCP 服务器、kagent 控制器、Terraform 平台栈与 gateway-guardrails Helm 图表,将整个系统部署在 Kubernetes(OKE)之上。
系统从 GitHub 仓库(默认 kubeflow/website 的 content/en 目录)抓取 .md 与 .html 文档,经 canonical_rag_ingest.py 做 Hugo/Markdown 规范化解析、按 token 分块并抽取 release_date,再通过集群内 TEI 服务生成 768 维向量,以 pymilvus 批量写入 Milvus 的稠密加原生 BM25 混合索引。查询阶段,docs-agent-mcp/mcp-server/server.py 以确定性意图路由(SEARCH_MODE=auto)在 Milvus 上做 v4 混合检索,把带引用的片段交给 KServe 的 llama3.1-8B 推理服务生成答案,模型只输出结构化引用而不渲染 URL。对外由 WebSocket 的 handle_websocket / stream_llm_response 或 HTTPS 的 POST /chat 提供流式(SSE 事件 content、tool_result、citations、done)与非流式 JSON(response、citations)两种响应,GET /health 供 Kubernetes 探针使用。基础设施由 docs-agent-mcp/terraform 下的 namespaces.tf、knative.tf、kubeflow_pipelines.tf、milvus.tf、kagent.tf、gateway_guardrails.tf 声明式编排,gateway-guardrails 图表提供 Istio 网关 TLS、CORS 锁定、每分钟 60 次限流和零信任 AuthorizationPolicy。CI 由 oke-cicd.yaml 与 tests.yml 完成流水线编译、ruff、pytest、镜像推送 GHCR 及可选 OKE 部署。
- Kubeflow 平台运维人员收到用户提问“如何创建 pipeline”,希望获得带官方文档引用的准确回答。
- 文档维护者在发布新版本文档后,希望重新跑 KFP 接入流水线更新 Milvus 集合而不重建整套服务。
- 平台团队需要在自有 Kubernetes/OKE 上部署一个只在内部使用的文档问答服务,并通过 Terraform 复现。
- 前端工程师要把问答组件嵌入 Kubeflow 官网,只需要 POST /chat 并消费 SSE 事件与 citations 字段。
- Agent 开发者希望用 MCP 客户端复用同一套检索与引用逻辑,而不是自己实现切分与向量检索。
- 安全团队要求对外暴露的聊天入口具备 TLS、CORS 白名单和速率限制,可直接使用 gateway-guardrails 图表的默认值。
如何安装或部署这个 Agent?
前置条件:Kubernetes 1.20+、Helm 3.x、Kubeflow Pipelines、用于 LLM 推理的 GPU 节点,以及受信任 CA 签发的 SSL 证书(浏览器会拦截无效证书下的 WebSocket 与 HTTPS 请求)。
先在 docs-agent 命名空间安装 Milvus(standalone 模式):
helm repo add milvus https://milvus-io.github.io/milvus-helm/
helm repo updatehelm upgrade --install my-release zilliztech/milvus -n docs-agent \
--set cluster.enabled=false \
--set standalone.enabled=true \
--set etcd.replicaCount=1 \
--set etcd.persistence.enabled=false \
--set minio.mode=standalone \
--set minio.replicas=1 \
--set pulsar.enabled=false \
--set pulsarv3.enabled=false \
--set standalone.podAnnotations."sidecar\.istio\.io/inject"="false"验证连接:
from pymilvus import connections
connections.connect("default", host="my-release-milvus.docs-agent.svc.cluster.local", port="19530")
print("Connected to Milvus successfully!")再部署 KServe 的 ServingRuntime 与 InferenceService(模型 RedHatAI/Llama-3.1-8B-Instruct,vLLM 后端,需要 huggingface-secret 中的 HF_TOKEN):
apiVersion: serving.kserve.io/v1alpha1
kind: ServingRuntime
metadata:
name: llm-runtime
namespace: docs-agent
spec:
supportedModelFormats:
- name: huggingface
version: "1"
autoSelect: true
containers:
- name: kserve-container
image: kserve/huggingfaceserver:latest-gpu
command: ["python", "-m", "huggingfaceserver"]
resources:
requests:
cpu: "4"
memory: "16Gi"
nvidia.com/gpu: "1"
limits:
cpu: "6"
memory: "24Gi"
nvidia.com/gpu: "1"若 Kubeflow Pipelines 需要访问 Milvus,还要补上 RBAC:
kubectl create role milvus-access \
--namespace docs-agent \
--verb=get,list,watch \
--resource=services,endpoints
kubectl create rolebinding kfp-to-milvus-editor \
--namespace docs-agent \
--role=milvus-access \
--serviceaccount=kubeflow:default-editor完整平台(Knative、Istio、KServe、KFP、Milvus、kagent、网关护栏)由 docs-agent-mcp/terraform 下的配置声明式创建,路径上的具体变量名与凭据配置仓库未逐条列出,需要按 variables.tf 与 kagent.tf 自行补齐。
如何使用这个 Agent?
运行数据接入流水线,把文档写入 Milvus:
python docs-agent-mcp/pipelines/kubeflow-pipeline.py启动 API 服务(WebSocket 或 HTTPS 二选一):
# WebSocket API
python server/app.py
# HTTPS API
python server-https/app.py流式调用(Server-Sent Events):
curl -X POST "https://your-domain.com/chat" \
-H "Content-Type: application/json" \
-H "Accept: text/event-stream" \
-d '{"message": "What is KServe?", "stream": true}'非流式调用:
curl -X POST "https://your-domain.com/chat" \
-H "Content-Type: application/json" \
-d '{"message": "What is KServe?", "stream": false}'import requests
import json
response = requests.post(
'https://your-domain.com/chat',
json={
'message': 'What is KServe?',
'stream': False
}
)
data = response.json()
print(f"Response: {data['response']}")
if data.get('citations'):
print(f"Sources: {data['citations']}")常用环境变量:KSERVE_URL、MODEL(默认 llama3.1-8B)、PORT(默认 8000)、MILVUS_HOST、MILVUS_PORT(默认 19530)、MILVUS_COLLECTION(默认 kubeflow_docs)、EMBEDDING_MODEL(默认 sentence-transformers/all-mpnet-base-v2)。流水线参数包括 repo_owner、repo_name、directory_path(默认 content/en)、chunk_size(1000)、chunk_overlap(100)、base_url、milvus_host。排查可用:
kubectl get pods -n docs-agent | grep milvus
kubectl get inferenceservice -n docs-agent
kubectl logs -f deployment/docs-assistant-api这个 Agent 有哪些优点和局限?
- 检索质量有明确设计:RAG v4 采用 768 维 MPNet 稠密向量加原生 BM25 的混合检索,并区分类型化的 release_date。
- 引用可控:确定性 MCP 意图路由产出结构化引用,README 明确说明 LLM 不渲染 URL,降低链接幻觉风险。
- 接口形态完整:同一后端同时提供 WebSocket 与 FastAPI HTTPS API,支持 SSE 流式、非流式 JSON 与 /health 探针。
- 基础设施可复现:docs-agent-mcp/terraform 用 namespaces.tf、knative.tf、milvus.tf、kagent.tf、gateway_guardrails.tf 声明式管理,Milvus 被调度到 CPU 节点以保留 GPU。
- 接入流水线做了工程取舍:移除 Feast、改用集群内 TEI 服务生成向量,使 Dockerfile.pipeline 保持 python:3.11-slim、避免镜像膨胀和 OKE 驱逐。
- 边缘安全有默认护栏:gateway-guardrails 图表内置 TLS、CORS 锁定、每分钟 60 次令牌桶限流与零信任 AuthorizationPolicy。
- 部署门槛高:需要 Kubernetes 1.20+、Helm 3.x、Kubeflow Pipelines、GPU 节点,以及受信任 CA 的 SSL 证书,缺少证书时浏览器会直接拦截连接。
- 组件耦合 Kubeflow 技术栈:检索依赖 Milvus、推理依赖 KServe+vLLM、接入依赖 KFP,替换任一环都需要改配置或代码。
- 模型来源绑定:默认推理服务固定使用 RedHatAI/Llama-3.1-8B-Instruct 与 llama3_json 工具解析器,且要提供 HF_TOKEN。
- 检索范围默认只覆盖 kubeflow/website 的 content/en,接入其它仓库需要改 repo_owner、repo_name、directory_path 等参数。
- Terraform 内部细节未完整公开,README 只列出各 .tf 文件职责,变量与密钥的具体填写方式未逐项说明。
- 运维负担落在使用方:RBAC、GPU 显存(利用率 0.90)、慢查询告警与本地存储式对话历史限制都由部署者自行处理。
这个 Agent 与同类方案有什么区别?
与相关度最高的同类 agent 并排比较关键指标。
| Agent | 源码审查 | 形态 / 费用 | Star | 最近更新 | 主语言 | 完整支持的平台 |
|---|---|---|---|---|---|---|
| Kubeflow 文档 AI 助手 当前 | 42 · 缺口较多 | 自托管服务免费 + 模型费 | ★ 46 | 1 天前 | Python | — |
| Heym | 46 · 缺口较多 | 自托管服务免费 + 模型费 | ★ 1.2k | 今天 | Python | Codex · Claude.ai |
| Google Cloud Agent Starter Pack | 67 · 存在缺口 | 命令行工具免费 + 模型费 | ★ 6.6k | 5 个月前 | Python | — |
| OpenContracts 开源文档智能平台 | 51 · 缺口较多 | 自托管服务免费 + 模型费 | ★ 1.5k | 1 天前 | Python | Claude Code · Claude.ai |
FollowAgents 如何评估这个 Agent?
查看各维度的扣分理由
README 描述了 gateway-guardrails 的限流、CORS 锁定与零信任 AuthorizationPolicy,并给出 KFP 到 Milvus 的 RBAC 示例,说明最小权限有初步设计,但未展示实际策略文件,且 KServe 配置使用 latest-gpu 镜像、HF_TOKEN 通过 secretKeyRef 注入,敏感数据处理仅停留在描述层面,故 least_privilege、sensitive_data_handling 各 1。用户确认方面,聊天接口直接执行工具调用与流式输出,未见任何确认或审批环节,记 0。数据流透明度有架构图与 RAG v4 说明,但缺少端到端数据保留与日志策略,记 1。依赖安全方面,CI 固定 ruff 版本、Helm 版本,但容器镜像使用 latest-gpu 且未见依赖漏洞扫描,记 1。外部效应方面,CI 明确不接触集群、部署由 Argo CD 负责,但 Agent 本身会调用外部模型与向量库,影响范围未完整声明,记 1。回滚方面,CI 提到通过修改镜像 tag 并同步 Argo CD 回滚,但无具体回滚步骤或版本保留策略,记 1。来源归属方面,README 明确作者、KEP-867、导师与组织,并说明引用由结构化 citations 提供、LLM 不渲染 URL,记 2。
自一致性方面,README 同时描述 legacy FastAPI 服务器与新的 MCP 架构,且安装章节仍指向 server/app.py 与 server-https/app.py,与仓库布局中的 legacy/ 存在潜在冲突,记 1。依赖可用性方面,CI 分别安装 MCP 与 pipeline 依赖并编译,但未锁定全部版本,且 KServe 镜像使用 latest-gpu,存在漂移风险,记 1。失败消息方面,README 列出常见问题与调试命令,但代码层面未见结构化错误处理或错误码说明,记 1。
受众与场景方面,README 明确面向 Kubeflow 用户、网站聊天机器人、WebSocket 与 HTTPS 两种集成方式,场景覆盖较清楚,记 2。能力边界方面,提到 RAG v4、混合检索、意图路由,但未系统列出不支持的问题类型或模型能力边界,记 1。触发精度方面,MCP 意图路由与 SEARCH_MODE=auto 有描述,但缺少触发条件、阈值与误触发处理说明,记 1。环境适配方面,依赖 Kubernetes、GPU、Helm、Terraform、OKE 等特定环境,README 未提供本地或替代环境运行路径,记 1。
信息架构方面,README 有目录、仓库布局表、架构图与配置表,结构清晰,记 2。安装说明方面,Milvus、KServe、KFP、API 服务器均有步骤与命令,但部分路径指向 legacy 代码,记 2。命名稳定性方面,存在 legacy/ 与 docs-agent-mcp/ 两套命名,且 CI 变量名 ENABLE_OKE_DEPLOY 与注释说明不一致,记 1。示例与 FAQ 方面,提供 WebSocket、curl、JavaScript、Python 示例及 Troubleshooting,记 2。已知限制方面,仅提到未来改进与聊天历史限制,缺少系统性的已知限制清单,记 1。许可证方面,LICENSE 为完整 Apache-2.0 文本,README 也声明 Apache-2.0,记 3。版本与变更日志方面,CI 支持 SemVer 镜像标签,但仓库未见 CHANGELOG 或版本发布说明,记 1。维护责任方面,README 列出作者与导师,但未说明 issue 处理、维护者轮换或安全联系方式,且发布者身份未经验证,记 1。
输出可用性方面,API 返回结构化 JSON 与 SSE 事件,包含 citations,便于前端集成,记 2。边际价值方面,项目解决 Kubeflow 文档检索问题,但同类 RAG 文档助手较多,且仓库包含 legacy 与多套实现,增量价值不够突出,记 1。成本效益方面,需要 GPU 节点、Milvus、KServe、KFP 等较重基础设施,README 未给出资源成本估算或轻量替代方案,记 1。
主张可追溯性方面,README 引用 KEP-867、RAG_V4_ARCHITECTURE.md 与具体文件路径,但未提供评估数据或可复现的验证步骤,记 1。跨源佐证方面,CI 工作流与 Helm 测试模板部分佐证了构建与连接测试,但核心 RAG 质量与安全策略缺少多源交叉验证,记 1。事实与推断分离方面,README 将设计目标与已实现功能混写,未明确区分已验证与计划中的能力,记 1。
- 源码中未见:执行前用户确认开启或自行加上执行前确认;先在沙箱或测试环境跑通,确认行为后再接入真实数据。
- README 同时描述 legacy FastAPI 服务器与新的 MCP 架构,安装章节仍指向 server/app.py 与 server-https/app.py,实际部署前需确认哪套实现是当前受支持路径。
- KServe 配置使用 kserve/huggingfaceserver:latest-gpu 等浮动镜像标签,存在不可复现与供应链漂移风险,生产使用前应固定镜像摘要。
- 聊天接口直接执行工具调用并流式返回,未见用户确认或审批机制,若接入敏感或写操作工具需补充确认与权限边界。
- 仓库未见 CHANGELOG、版本发布说明或安全联系方式,发布者身份未经验证,维护责任与更新路径不清晰。
- 依赖 GPU、Milvus、KServe、KFP 等较重基础设施,README 未提供资源成本估算或轻量替代方案。