企业官网建设流程全解析

Milvus 官方 Bootcamp 仓库到底提供了什么？这是很多刚接触向量数据库的程序员第一个想问的问题。它的定位不是 SDK 源码，也不是简单的 Hello World 集合，而是一整套面向真实业务的“示例项目 + 落地教程”。如果你打算做 RAG 知识库、以图搜图、商品推荐、多模态检索，或者只是想搞清楚 Milvus 到底能跑通哪些场景，这个仓库值得花时间过一遍。

借助这个仓库，你可以快速建立对 Milvus 技术栈的直观认识，并在本地搭建出一套可运行的向量检索环境：从 Docker Compose 启动 Milvus，到用 PyMilvus 写入向量数据，再到跑通一个语义搜索示例，最后还能通过 Attu 或 RESTful API 验证结果。下面的内容会把 Bootcamp 涉及的模块、环境准备、部署流程、示例代码与性能观察串起来，帮助你在自己机器上完整跑一遍。

1. Milvus Bootcamp 核心能力速览

Bootcamp 位于 milvus-io/bootcamp，是 Milvus 官方维护的教程和示例集中地。它面向不同水平的开发者，既包含入门的向量数据库操作演示，也包含面向生产场景的推荐系统、问答系统、图像检索等端到端项目。

需要说明的是，Bootcamp 不是一个开箱即用的“软件”，它更像一个学习路径和可复用代码库。你可以把自己的数据套进示例脚本中，也可以参考其中的架构设计来搭建业务系统。

2. Milvus 是什么，以及为什么需要 Bootcamp

Milvus 是一款开源向量数据库，专门用来存储、索引和检索海量高维向量数据。它建立在多种 ANN（近似最近邻）索引库之上，对外提供统一的向量插入、删除、查询接口，并且支持标量字段过滤与向量检索混合执行。正因为这些特性，Milvus 经常被用来承载大模型应用中的“外部记忆”，也就是把文本、图片、音视频经过 Embedding 模型转成向量后，再做相似度检索。

Bootcamp 的价值在于它把这些“大词”拆成了能跑的代码。向量数据库本身并不难理解，难的是把它和真实业务串起来：文本怎么切片？Embedding 用什么模型？向量字段和标量字段如何设计？检索时如何让结果更准确？Bootcamp 对这些问题给出了可参考的工程范本。

如果你在 Github 上搜索“milvus bootcamp”，会看到它包含多个目录，通常会覆盖以下几种类型：

• 基础操作：连接 Milvus、创建 Collection、插入向量、构建索引、执行搜索。
• 场景示例：问答机器人、语义搜索、以图搜图、推荐系统等。
• 集成案例：与 OpenAI、HuggingFace Embedding 模型、图像识别模型等外部服务配合使用。

因此，这篇教程后续的实操环节，会以“部署 Milvus + 运行 Bootcamp 示例”为主线展开。你可以先把环境跑起来，再深入看代码逻辑。

3. 本地部署环境准备

3.1 硬件与系统要求

Milvus 本身是分布式架构，但本地开发和测试通常用单机模式启动，对硬件要求并不苛刻。

• 操作系统：Linux 最省事；macOS 和 Windows 也可以跑，但 Windows 强烈推荐 WSL 2 或 Docker Desktop。
• CPU：x86/ARM 均可，单机测试 4 核以上足够。
• 内存：Milvus 依赖 etcd、MinIO 等组件，本地分配 8 GB 以上内存更稳妥。
• 磁盘：MinIO 会存储日志和向量数据文件，预留 20 GB 以上剩余空间。
• GPU：Milvus 本身不强制需要 GPU，但如果你在本机跑 Embedding 模型或图像模型做示例，则需要考虑显卡显存。

如果你使用的是 Windows 且不想装 Docker，后面会单独给出非 Docker 启动的注意事项。更稳妥的生产路径仍是 Linux + Docker Compose。

3.2 软件依赖清单

Bootcamp 中的 Python 示例大多依赖 milvus 客户端库、OpenAI/HuggingFace 的 SDK、pymilvus 等。启动前至少要保证下面几项就绪：

• Docker 与 Docker Compose
• Python 3.8 以上版本（推荐 3.10 或 3.11）
• pip 包管理工具
• Git（用于拉取 Bootcamp 代码）
• curl 或其他 HTTP 调试工具（用于 RESTful API 验证）

安装 Docker 后，可以用下面的命令确认版本：

docker --version docker compose version

如果 Docker 未安装，请先到 Docker 官网下载对应系统的 Docker Desktop，并启动 Docker 服务。

3.3 Python 环境准备

建议为 Bootcamp 单独创建虚拟环境，避免污染系统 Python：

python -m venv milvus_env source milvus_env/bin/activate # Linux/macOS milvus_env\Scripts\activate # Windows CMD

激活后升级 pip 并安装基础依赖：

pip install --upgrade pip pip install pymilvus openai sentence-transformers requests

如果是在中国大陆网络环境，可以临时使用国内 PyPI 镜像加速：

pip install pymilvus openai sentence-transformers requests -i https://pypi.tuna.tsinghua.edu.cn/simple

这里安装的 openai 不一定用于真实 OpenAI 接口，部分 Bootcamp 示例允许自定义 embedding endpoint，你可以后续按需配置。

4. Milvus 服务端启动方式

4.1 使用 Docker Compose 启动 Milvus 单机版

Milvus 官方仓库中提供了单机版 docker-compose 配置。从 Bootcamp 或 Milvus 官网获取稳定版配置即可。推荐的操作方式是先建立一个独立目录，并拉取配置：

mkdir milvus-docker && cd milvus-docker wget https://github.com/milvus-io/milvus/releases/download/v2.4.x/milvus-standalone-docker-compose.yml -O docker-compose.yml

或者直接使用 Bootcamp 仓库中的脚本。如果你不想手动找 URL，也可以直接克隆 Bootcamp 后，在其scripts目录下查找启动脚本。

启动命令：

docker compose up -d

执行后 Docker 会拉取镜像，并使用默认配置启动三个核心服务：

• etcd：存储元数据
• MinIO：存储数据文件
• Milvus Standalone：提供查询与写入服务

启动完成后，用以下命令观察状态：

docker compose ps

当所有服务的状态显示为 healthy 或 Up 时，Milvus 即可访问。默认 gRPC 端口为 19530，管理端口为 9091。

4.2 Milvus 的 Windows 非 Docker 安装思路

很多用户在 Windows 上不希望安装 Docker，或者 Docker Desktop 申请企业授权不方便。对于这种情况，Milvus 的 Windows 非 Docker 安装虽然不如 Docker 方式主流，但也是可行的，核心思路是手动运行 Milvus 依赖的 etcd 和 MinIO，再单独启动 Milvus 服务。

非 Docker 方式对依赖版本有严格要求，不同 Milvus 版本对应的 etcd、MinIO 版本也要仔细匹配。通常不建议在 Windows 上手动编译部署 Milvus。更推荐的替代路径有两种：

1. 安装 WSL 2，在 Ubuntu 子系统内按 Linux 方式安装 Milvus。
2. 使用云厂商提供的向量数据库服务，或在远程 Linux 服务器上部署 Milvus，Windows 本机只安装客户端 SDK。

如果一定要在 Windows 原生环境试验，可以下载 etcd 的 Windows 版本和 MinIO 的 Windows 版本，分别启动服务后，再把 milvus.yaml 中的对应地址指到本地服务端口。这个方案排查成本较高，只适合研究学习。

4.3 启动 Bootcamp 自带脚本

Bootcamp 仓库通常包含一个scripts目录，里面有启动 Milvus 和示例项目的脚本。假设你已经克隆了仓库：

git clone https://github.com/milvus-io/bootcamp.git cd bootcamp

然后根据 README 指引执行脚本。例如部分场景会提供：

cd bootcamp/quickstart python run_milvus.py

这个脚本会调用本机命令行工具启动 Docker Compose，或引导你指定 Milvus 服务地址。实际脚本名称以仓库 README 为准。

如果你不想被仓库结构困惑，可以先用最直接的方式验证 Milvus 是否通：

from pymilvus import connections connections.connect(host="127.0.0.1", port="19530") print("Milvus 连接成功")

如果输出正常，说明服务端已经可用。

5. 验证 Milvus 与 Attu 可视化工具

5.1 基础连接验证

Milvus 启动以后，第一步是通过 SDK 创建 Collection。这是一个非常重要的“冒烟测试”，能一次性验证网络、服务端状态和权限。

创建一个名为test_demo的 Collection，并插入少量向量：

from pymilvus import ( connections, CollectionSchema, FieldSchema, DataType, Collection ) connections.connect(host="127.0.0.1", port="19530") fields = [ FieldSchema(name="id", dtype=DataType.INT64, is_primary=True), FieldSchema(name="embedding", dtype=DataType.FLOAT_VECTOR, dim=8), ] schema = CollectionSchema(fields=fields) collection = Collection(name="test_demo", schema=schema) data = [ [i for i in range(10)], [[0.1 + i * 0.05] * 8 for i in range(10)], ] collection.insert(data) collection.flush() print("插入完成，实体数量：", collection.num_entities)

运行这段代码后，如果打印出数字 10，说明 Milvus 插入链路正常。接下来可以搜索：

import random collection.load() search_vectors = [[random.random() for _ in range(8)]] results = collection.search( data=search_vectors, anns_field="embedding", param={"metric_type": "IP", "params": {}}, limit=3, output_fields=["id"], ) for hits in results: for hit in hits: print(hit.id, hit.score)

搜索能返回数据，就说明索引和查询链路没有问题。

5.2 启动 Attu 查看 Milvus 数据

Attu 是 Milvus 的可视化管理工具，可以用网页方式查看 Collection、实体数据和查询结果。Attu 支持独立 Docker 启动：

docker run -p 8000:3000 -e MILVUS_URL=127.0.0.1:19530 zilliz/attu:latest

启动后，浏览器访问http://127.0.0.1:8000，在连接界面填入 Milvus 地址127.0.0.1:19530，点击连接即可。进入界面后可以看到刚才创建的test_demoCollection 以及向量维度和实体数量。

需要注意，不同版本 Attu 对 Milvus 版本的支持范围不同。比如旧版 Attu 可能无法连接 Milvus 2.4，而新版对 Milvus 2.3 支持也需要确认。稳妥做法是使用 Docker 镜像最新版本，并按 README 说明对照适用的 Milvus 版本。

5.3 通过 RESTful API 验证

Milvus 在 2.x 版本也提供了 RESTful API。如果你不想安装任何 SDK，可以直接用 curl 做接口验证：

curl -X POST http://127.0.0.1:19530/v2/vectordb/collections/list \ -H "Content-Type: application/json" \ -d '{}'

正常情况会返回包含test_demo的列表结果。有了 RESTful 接口，后面编写跨语言业务系统时就方便很多。

6. 运行 Bootcamp 典型场景示例

6.1 语义搜索示例

Bootcamp 中最常被参考的是语义搜索。它的流程是：读取文本 -> 切分成块 -> 用 Embedding 模型转成向量 -> 存入 Milvus -> 用户输入 query -> 转成向量 -> 搜索并返回相似文本。

在 Bootcamp 仓库中，通常会有类似semantic_search的目录。运行前需要确认在代码中使用的 Embedding 模型来源。常见方式有两种：

• 调用远程 embedding API。
• 使用本地sentence-transformers模型。

为了减少网络依赖，可以先使用本地模型跑通流程。下面是一个简化版参考：

from sentence_transformers import SentenceTransformer from pymilvus import connections, CollectionSchema, FieldSchema, DataType, Collection model = SentenceTransformer("paraphrase-multilingual-MiniLM-L12-v2") docs = [ "Milvus 是一个开源的向量数据库。", "Bootcamp 是 Milvus 的官方示例仓库。", "向量检索可以用于推荐系统。", ] doc_embeddings = model.encode(docs).tolist() connections.connect(host="127.0.0.1", port="19530") fields = [ FieldSchema(name="id", dtype=DataType.INT64, is_primary=True), FieldSchema(name="doc", dtype=DataType.VARCHAR, max_length=500), FieldSchema(name="embedding", dtype=DataType.FLOAT_VECTOR, dim=doc_embeddings[0].__len__()), ] schema = CollectionSchema(fields=fields) collection = Collection(name="semantic_demo", schema=schema) collection.insert([[i for i in range(len(docs))], docs, doc_embeddings]) collection.flush() collection.load() query = "向量数据库能做什么？" query_embedding = model.encode([query]).tolist() results = collection.search( data=query_embedding, anns_field="embedding", param={"metric_type": "IP", "params": {}}, limit=2, output_fields=["doc"], ) for hits in results: for hit in hits: print(f"相似度: {hit.score:.4f}，文本: {hit.entity.get('doc')}")

执行时，如果本机第一次加载 HuggingFace 模型，会先下载权重，需要几分钟时间。网络较慢时可以提前通过环境变量HF_ENDPOINT设置国内镜像：

export HF_ENDPOINT=https://hf-mirror.com

运行结果会打印两条最相似的文本作为参考。如果返回的文本明显不相关，可以检查向量模型语言适配性或增大limit值再观察。

6.2 以图搜图示例

以图搜图也是 Bootcamp 中很有辨识度的案例。流程上与文本检索类似，只是 Embedding 模型换成了图像特征提取模型，比如 ResNet、CLIP 或其他视觉模型。

这里需要注意两个问题：

1. 图像特征提取通常需要 GPU，显存占用取决于模型大小和 batch_size。
2. 图像要向量的维度一般比文本向量更高，Collection 设计时要预留 dim 值。

Bootcamp 中常见代码结构如下：

• image_embedding.py：负责把本地图片转成向量。
• load_data.py：把图片向量写入 Milvus。
• search.py：提供查询图片并返回相似图片的示例。

运行这类示例时，建议先用 10 张以内的测试图片跑通全流程，再扩大到更多图片，避免首次运行时因为网络、模型下载或路径问题浪费时间。

6.3 问答系统与知识库 RAG 示例

Bootcamp 中问答系统示例更贴近当前大模型应用。它通常会演示如何结合 Milvus 与 LLM：先把文档切片并向量化，写入 Milvus；用户提问时先在 Milvus 中检索相关片段；再把片段拼进 Prompt 中，交给 OpenAI 或其他大模型接口生成回答。

这种设计的价值在于：大模型不再依赖内部记忆回答，而是基于业务知识库中的真实内容进行回答，可以有效降低幻觉比例。RAG 类系统的成败往往不在大模型本身，而在于检索质量。片段的切分粒度、Embedding 模型的语义能力、Milvus 检索时使用的 metric type、TopK 数量都会直接影响最终答案质量。

在本地运行这类示例时，OpenAI 接口需要配置密钥。也可以把 OpenAI SDK 的 base_url 替换成本地部署的模型服务，例如使用 Ollama 提供兼容接口。Bootcamp 部分示例支持配置环境变量来覆盖 endpoint，具体以仓库 README 为准。

7. 接口 API 与批量任务设计

7.1 RESTful API 对业务集成的意义

Milvus 提供的 RESTful API 意味着不一定要写 Python 才能调用向量检索能力。在 Bootcamp 的架构参考中，Milvus 通常被部署为独立的检索服务，上层业务通过 SDK 或 HTTP 接口访问。如果你所在团队以 Java、Go 为主，查看 Bootcamp 中的 Python 示例更多是为了理解数据流和参数设置，落地时可以用对应语言的 Milvus SDK 改写。

RESTful 接口的基础请求格式如下：

# 列出所有 Collection curl -X POST http://127.0.0.1:19530/v2/vectordb/collections/list \ -H "Content-Type: application/json" \ -d '{}' # 查询向量 curl -X POST http://127.0.0.1:19530/v2/vectordb/entities/search \ -H "Content-Type: application/json" \ -d '{ "collectionName": "semantic_demo", "vector": [0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8], "limit": 3, "outputFields": ["doc"] }'

这里的vector维度需要与 Collection 中定义的 dim 一致。如果返回字段为空，检查outputFields是否包含预定义字段名。

7.2 批量写入向量数据

Bootcamp 中很多示例需要一次写入大量向量，比如给数千张图片构建索引。直接逐条插入效率很低，正确做法是使用批量插入，将数据组织成多个列表，一次写入。

batch_size = 1000 for i in range(0, len(all_ids), batch_size): batch_ids = all_ids[i:i+batch_size] batch_texts = all_texts[i:i+batch_size] batch_vectors = all_vectors[i:i+batch_size] collection.insert([batch_ids, batch_texts, batch_vectors]) print(f"已插入 {i + len(batch_ids)} 条") collection.flush()

Milvus 的flush会把内存中的数据落盘，确保后续检索能查到。插入大数量级数据后，还需要执行create_index，否则查询性能会显著下降。

下面给出一个索引创建示例：

from pymilvus import Index index = Index( collection=collection, field_name="embedding", index_params={ "index_type": "HNSW", "metric_type": "IP", "params": {"M": 16, "efConstruction": 200} } )

常见索引类型包括 HNSW、IVF_FLAT、DISKANN 等。其中 HNSW 查询速度快，适合中等数据量的本地示例；IVF 系列内存占用相对可控；DISKANN 适用于超大数据集。

7.3 批量查询与任务队列

构建批量查询时，需要重点关注查询的 batch 大小和服务端并发能力。一次性发送大量并发请求可能会让 Milvus 或嵌入模型服务崩溃；在批量查询中建议使用线程池或队列限制并发数：

from concurrent.futures import ThreadPoolExecutor queries = ["Milvus 索引怎么建", "向量数据库应用", "RAG 架构"] futures = [] with ThreadPoolExecutor(max_workers=2) as executor: future = executor.submit(search_func, queries) futures.append(future) for future in futures: result = future.result() print(result)

7.4 批量任务失败重试建议

批量任务一旦跑起来，最头疼的问题就是“中间失败后从哪里继续”。建议在任务启动时先确认三件事：数据源是否可重复读取；写入库中是否有幂等主键；失败记录是否写入日志或单独的 CSV 文件。

合理的做法是给每批数据标记 offset 或唯一 ID，写入失败时从断点继续。Bootcamp 里很多 Python 脚本不具备这个机制，它们更适合做演示。实际生产开发时需要对这部分做工程化扩展。

8. 资源占用与性能观察

8.1 内存与磁盘占用

Milvus 运行后主要占用来自 etcd、MinIO 和 Milvus 主进程。对于几千到几万条向量的本地测试场景，内存占用一般在 2 GB 到 6 GB 之间，实际取决于是否有其他容器占用。

观察资源占用，可以使用：

docker stats

该命令会动态展示每个容器的 CPU、内存、网络和磁盘 I/O。如果你的本机同时运行了多个 Embedding 模型的 Web UI 或其他服务，需要先将长期占用的容器或进程停掉，避免影响 Milvus 稳定性。

8.2 向量查询性能关键因素

向量查询性能受几个因素影响：

• 数据量：数据越多，索引构建时间越长，查询耗时也会增加。
• 索引类型：HNSW 查询快但内存占用高；IVF_FLAT 在数据量小时不一定有明显优势。
• 查询的 limit 和 filter：返回更多结果会增加耗时；如果使用了标量过滤，过滤字段若没有索引，扫描成本会明显增加。
• 向量维度：Embedding 模型输出 768 维、1024 维很常见，高维度查询对 CPU 和内存压力更大。
• metric type：通常 IP 和 COSINE 在向量归一化后差别不大，但不同项目的计算耗时略有差异。

Bootcamp 中的示例数据量一般不大，用户往往察觉不到性能瓶颈。如果把同样的代码逻辑搬到几十万维数据和千万级数据上，就必须要关注索引参数和服务器配置。

8.3 Embedding 模型推理的显存占用

Bootcamp 的部分示例需要本地跑 Embedding 模型。如果用的是 HuggingFace 的 Transformer 模型，显存占用会随着模型体积和 batch_size 变化。以常见的中等模型为例，4GB 到 8GB 显存可以覆盖大多数开源 Embedding 模型的小批量推理。

如果显存不足，可以考虑降低 batch_size，或者使用 CPU 推理。CPU 推理速度会慢很多，但测试场景完全够用。这里的核心原则是：不要一次性把上千条文本塞给模型去编码，分批处理更安全。

8.4 降低资源占用的小技巧

本地测试时，为了减少等待和崩溃风险，可以采用这些做法：

• 先用少量样本跑通代码，再扩展数据量。
• 删除不再使用的 Collection，避免磁盘膨胀和数据文件堆积。
• 定期清理 Docker 构建缓存和无用镜像。
• 如果 Milvus 长期不用，用docker compose down停止服务，需要保留数据时不要加-v参数。
• 在使用 Attu 时，只打开必要的 Collection 页面，避免工具自动加载大量元数据导致浏览器卡顿。

9. 常见问题与排查方法

10. 最佳实践与使用建议

10.1 数据模型设计要早于代码编写

Bootcamp 示例的 Collection schema 通常很简单，只有主键、文本和向量字段。但真实业务里，你可能需要支持多租户隔离、时间范围过滤、文档类型过滤、权限标签过滤。这些都需要提前设计为标量字段，并补充对应索引。

设计 schema 时要注意：

• 主键尽量使用能对应业务 ID 的整数或字符串，不要用无意义的自增 ID。
• 过滤频繁的标量字段应选择合适的数据类型，并在高基数字段上考虑是否创建索引。
• 文本字段的 max_length 要留足余地，尤其是使用长文本切片时不要超过字段上限。
• 如果需要区分多个知识库或数据集，可以让 Collection 支持 partition 分区或增加业务字段。

10.2 向量数据要关注来源与质量

向量数据不是凭空产生的，它来自文档、图片、音频或行为序列。数据质量直接决定检索效果。在实践中，文档需要先做清洗，去掉页眉页脚、无意义符号和重复段落；图片需要确保清晰，避免倒置或不相关背景；音频需要确认授权范围。

对于文本切片，建议按语义完整度切分，而不是死板地按字符数切分。Bootcamp 示例中通常不会展开讲切分细节，但真实系统中切片策略必须单独设计，并多次测试。

10.3 检索效果要反复验证

向量检索与关键词检索不同，它没有“精确匹配”的概念。判断一个检索系统是否正常，不能只看是否返回结果，还要看返回结果是否相关。建议建立一个小型测试集，每组查询包含预期命中的文档 ID，每次修改参数后重新评估命中率。

Milvus 搜索结果的 score 在不同 metric type 下含义不同：

• IP：分数越高表示向量内积越大，一般认为更相似。
• L2：分数越低表示欧氏距离越小，更相似。
• COSINE：分数越高表示余弦夹角越小，更相似。

Batch 搜索时，往往需要把 query 和文档向量做同模型编码。如果 query 和文档分别使用不同模型，相似度对比会失去意义。

10.4 安全与合规要求

如果你在 Bootcamp 基础上扩展业务应用，需要特别注意以下几点：

• 人脸图片、私人文档、声音样本等敏感数据，未经授权不得采集、存储、检索或用于模型训练。
• 涉及用户隐私数据时，Milvus 应部署在内网，Access 控制遵循最小权限原则。
• 使用外部大模型接口做 RAG 时，不要把未脱敏的个人信息直接拼接进 Prompt。
• 对版权图片、专利文档、商业资料进行向量化前，确认是否有复制、存储和检索的合法权限。
• 发布商用应用前，要对输出内容做人工抽查与合规审查，不传播侵权、违法或不良内容。

10.5 工程化建议

Bootcamp 代码适合学习，但生产使用需要做不少工程化改造。下面这些建议能帮你少走弯路：

• 将 Milvus 地址、模型名称、Collection 名称写入环境变量或配置文件，避免硬编码。
• 向量化任务采用队列或异步任务，例如 Celery 或自定义消息队列。
• 为每个批处理任务添加日志，记录开始时间、处理数据量、失败原因、耗时。
• 定期评估 Collection 数据量和索引状态，必要时清理过期数据或重建索引。
• 将 Bootcamp 示例代码按“数据接入、向量化、写入、检索”分层拆成独立模块，避免一个脚本包揽所有逻辑。
• 上线前使用压测工具模拟并发查询，观察 Milvus 查询延迟和服务稳定性。

11. 总结与下一步

Milvus Bootcamp 最值得尝试的点在于，它用可运行代码把向量数据库的应用场景讲清楚了。你不需要从零研究 Milvus API，拉下仓库跑一遍语义搜索，就能快速建立起“数据怎么存、检索怎么做、结果怎么用”的完整链路。

如果你刚开始接触，建议按下面的顺序来验证：先部署 Milvus 单机版，再用 pymilvus 完成建表、插入、查询的最基础操作；然后启动 Attu，可视化确认数据；接着把 Bootcamp 的 semantic search 示例跑通，替换成自己的几条文本试一下；最后再扩展图片或问答场景。

比较容易踩的坑出现在模型下载和版本匹配上。文本和图像模型首次运行往往需要下载权重，这一步建议先做好网络准备；Attu 与 Milvus 的版本匹配也务必提前确认，旧版 Attu 连新版 Milvus 时会出现兼容问题。

后续可以继续探索的方向包括：把 Bootcamp 的检索链路接到大模型接口形成完整 RAG 服务；引入不同 Embedding 模型做效果对比；使用 Attu 定位 indexing 状态和查询性能；研究 Milvus 的分区、标量过滤和多租户能力，为真实的在线业务做准备。跑通 Bootcamp 只是开始，怎样让检索更准、更快、更适合自己的业务场景，才是更值得投入精力的部分。