2025-02-28发表2025-02-28更新LLM / RAG / 原理 / 对比分析 / 食用文档1 小时读完 (大约8751个字)

基于 Elasticsearch 和 Milvus 的 RAG 运维知识库的实现方法以及落地步骤

最近在整理一些业务场景的架构设计和部署落地实现指南
先放一个【基于 Elasticsearch 和 Milvus 的 RAG 运维知识库的实现方法以及落地步骤】，其中包含了详尽的技术实现细节、可运行的示例代码、原理分析、优缺点分析和应用场景分析。

架构描述： 基于RAG的运维知识库 (ElasticSearch + Milvus)

部署指南

1. 极其详细的部署步骤 (包含详尽的技术实现细节和分步骤、可运行的示例代码-也只能给示例代码)

1.1 环境准备

操作系统选择： 推荐使用 Linux 发行版，如 CentOS 7/8、Ubuntu 18.04/20.04。本指南以 CentOS 7 为例。
网络环境配置： 确保服务器之间网络互通，防火墙开放 Elasticsearch (默认端口 9200)、Milvus (默认端口 19530) 和应用程序所需的端口。

安装必要软件包：

# 更新 yum 源
sudo yum update -y

# 安装常用工具
sudo yum install -y wget curl vim net-tools

# 安装 Java (Elasticsearch 依赖)
sudo yum install -y java-1.8.0-openjdk-devel

# 安装 Python (用于后续脚本)
sudo yum install -y python3 python3-pip

# 安装 Docker 和 Docker Compose (可选，用于容器化部署)
sudo yum install -y yum-utils
sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
sudo yum install -y docker-ce docker-ce-cli containerd.io
sudo systemctl start docker
sudo systemctl enable docker
sudo curl -L "https://github.com/docker/compose/releases/download/1.29.2/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
sudo chmod +x /usr/local/bin/docker-compose

配置环境变量：

# 编辑 /etc/profile 或 ~/.bashrc
# 添加以下内容 (根据实际安装路径修改)
export JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk
export PATH=$JAVA_HOME/bin:$PATH

# 使环境变量生效
source /etc/profile  # 或 source ~/.bashrc

1.2 组件安装配置

1.2.1 Elasticsearch 安装配置

下载 Elasticsearch：

1
2
3

wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-7.17.17-linux-x86_64.tar.gz  # 根据需要选择版本
tar -xzf elasticsearch-7.17.17-linux-x86_64.tar.gz
cd elasticsearch-7.17.17/

修改配置文件 config/elasticsearch.yml：

cluster.name: my-rag-cluster  # 集群名称
node.name: node-1  # 节点名称
network.host: 0.0.0.0  # 监听所有 IP 地址
http.port: 9200  # Elasticsearch 端口
discovery.seed_hosts: ["node-1"]  #  单节点部署，配置为节点名称
cluster.initial_master_nodes: ["node-1"]  # 单节点部署
# 建议配置 (根据实际情况调整):
# bootstrap.memory_lock: true  # 锁定内存，防止交换
# xpack.security.enabled: false  # 如果不需要安全认证，可以禁用
# 注意：以上只是示例配置，生产环境请务必根据实际情况进行详细配置，特别是安全相关的配置。

关键参数解释：

cluster.name: 集群名称，同一集群内的节点应具有相同的集群名称。
node.name: 节点名称，用于标识集群中的单个节点。
network.host: Elasticsearch 监听的 IP 地址，0.0.0.0 表示监听所有 IP。
http.port: Elasticsearch 的 HTTP 端口，默认为 9200。
discovery.seed_hosts: 集群发现的主机列表。在单节点部署中，可以设置为节点名称。
cluster.initial_master_nodes: 初始主节点列表。在单节点部署中，设置为节点名称。
bootstrap.memory_lock: 是否锁定内存，防止 Elasticsearch 内存被交换到磁盘，影响性能。
xpack.security.enabled：开启xpack security功能。

启动 Elasticsearch：
1
./bin/elasticsearch -d # 后台启动
验证 Elasticsearch：
1
curl http://localhost:9200/
如果返回 JSON 格式的 Elasticsearch 信息，则表示启动成功。

1.2.2 Milvus 安装配置

使用 Docker Compose 安装 Milvus (推荐)：

# 创建 docker-compose.yml 文件
cat > docker-compose.yml <<EOF
version: '3.5'
services:
  etcd:
    container_name: milvus-etcd
    image: milvusdb/etcd:v3.5.5
    environment:
      ETCD_USE_EMBEDDED: "true"
    volumes:
      - ${DOCKER_VOLUME_DIRECTORY:-.}/volumes/etcd:/etcd
  standalone:
    container_name: milvus-standalone
    image: milvusdb/milvus:v2.2.14 # 根据需要选择版本
    command: ["milvus", "run", "standalone"]
    environment:
      ETCD_ENDPOINTS: etcd:2379
      MINIO_ADDRESS: minio:9000
    volumes:
      - ${DOCKER_VOLUME_DIRECTORY:-.}/volumes/milvus:/var/lib/milvus
    ports:
      - "19530:19530"
      - "9091:9091"
    depends_on:
      - "etcd"
  minio:
    container_name: milvus-minio
    image: minio/minio:RELEASE.2022-10-29T06-21-33Z
    environment:
      MINIO_ACCESS_KEY: minioadmin
      MINIO_SECRET_KEY: minioadmin
    volumes:
      - ${DOCKER_VOLUME_DIRECTORY:-.}/volumes/minio:/minio_data
    ports:
      - "9000:9000"
      - "9001:9001"
    command: minio server /minio_data --console-address ":9001"
    depends_on:
      - "etcd"
networks:
  default:
    name: milvus
EOF

# 启动 Milvus
docker-compose up -d

关键配置参数解释：

milvus-etcd: etcd镜像，用于存储milvus的元数据。
milvus-standalone： Milvus的standalone模式镜像。
- ETCD_ENDPOINTS: etcd 的连接地址。
- MINIO_ADDRESS: MinIO 的连接地址，用于存储数据。
milvus-minio: 对象存储minIO镜像。
- MINIO_ACCESS_KEY：MinIO用户名
- MINIO_SECRET_KEY：MinIO密码

验证 Milvus：

1	docker ps # 查看 Milvus 容器是否正常运行

1.2.3 安装 Python 依赖

1 2	pip3 install pymilvus==2.2.14 elasticsearch==7.17.1 # 注意版本匹配 pip3 install sentence-transformers

1.3 组件集成 (RAG 应用程序)

以下是一个 Python 代码示例，展示如何使用 Elasticsearch 和 Milvus 实现 RAG：

from elasticsearch import Elasticsearch
from pymilvus import connections, FieldSchema, CollectionSchema, DataType, Collection, utility
from sentence_transformers import SentenceTransformer

# --- 1. 连接到 Elasticsearch 和 Milvus ---

es = Elasticsearch(
    hosts=["http://localhost:9200"],  # Elasticsearch 地址
    # 如果 Elasticsearch 启用了安全认证，需要提供用户名和密码
    # http_auth=("elastic", "your_password")
)

connections.connect(
    alias="default",
    host="localhost",  # Milvus 地址
    port="19530"
)

# --- 2. 定义 Elasticsearch 索引和 Milvus Collection ---

# Elasticsearch 索引
index_name = "operations_knowledge"
if not es.indices.exists(index=index_name):
    es.indices.create(
        index=index_name,
        body={
            "mappings": {
                "properties": {
                    "title": {"type": "text"},
                    "content": {"type": "text"},
                    "tags": {"type": "keyword"},  # 可选的标签字段
                    # ... 其他字段 ...
                }
            }
        }
    )

# Milvus Collection
collection_name = "operations_knowledge_embeddings"
if not utility.has_collection(collection_name):
    fields = [
        FieldSchema(name="id", dtype=DataType.INT64, is_primary=True, auto_id=True),
        FieldSchema(name="doc_id", dtype=DataType.VARCHAR, max_length=256), # 存储对应的 Elasticsearch 文档 ID
        FieldSchema(name="embedding", dtype=DataType.FLOAT_VECTOR, dim=768)  # 假设使用 768 维的向量
    ]
    schema = CollectionSchema(fields, "Operations Knowledge Embeddings")
    collection = Collection(collection_name, schema)
    index_params = {
        "metric_type": "L2",  # 欧氏距离
        "index_type": "IVF_FLAT",  # 索引类型
        "params": {"nlist": 1024}  # 索引参数
    }
    collection.create_index(field_name="embedding", index_params=index_params)
else:
    collection = Collection(collection_name)

collection.load()

# --- 3. 加载数据到 Elasticsearch 和 Milvus ---

# 示例文档数据 (实际应用中从数据库或其他来源获取)
documents = [
    {"title": "服务器无法启动", "content": "检查电源、硬件和操作系统日志。", "tags": ["服务器", "启动"]},
    {"title": "网络连接中断", "content": "检查网线、交换机和路由器配置。", "tags": ["网络", "连接"]},
    # ... 更多文档 ...
]

# 加载 Sentence Transformer 模型
model = SentenceTransformer('all-mpnet-base-v2') # HuggingFace模型

# 将文档批量插入 Elasticsearch 和 Milvus
bulk_actions = []
for doc in documents:
    # 插入 Elasticsearch
    es_action = {
        "_index": index_name,
        "_source": doc,
    }
    bulk_actions.append(es_action)

    # 计算文档向量
    embedding = model.encode(doc["content"]).tolist()

    # 插入 Milvus
    milvus_data = [
        {"doc_id": str(len(bulk_actions) // 2), "embedding": embedding},  # 注意 doc_id 的类型和对应关系
    ]
    collection.insert(milvus_data)

# 执行 Elasticsearch 批量插入
if bulk_actions:
    es.bulk(index=index_name, operations=bulk_actions)

# 刷新 Elasticsearch 索引
es.indices.refresh(index=index_name)

# --- 4. 执行 RAG 检索 ---
def rag_search(query, top_k=5):
    # 1. 将用户查询向量化
    query_embedding = model.encode(query).tolist()

    # 2. 在 Milvus 中进行向量相似度检索
    search_params = {"metric_type": "L2", "params": {"nprobe": 16}}
    results = collection.search(
        data=[query_embedding],
        anns_field="embedding",
        param=search_params,
        limit=top_k,
        expr=None, # 无需表达式，可以添加基于标量字段的过滤表达式
        output_fields=["doc_id"],  # 获取对应的 Elasticsearch 文档 ID
    )
    doc_ids = [hit.id for hit in results[0]]

    # 3. 在 Elasticsearch 中检索文档
    es_results = es.mget(index=index_name, body={'ids': doc_ids})

    # 4. 整合结果 (这里简单地将 Milvus 检索结果和 Elasticsearch 检索结果合并)
    retrieved_docs = []
    for doc in es_results['docs']:
      if doc['found']: # 防止找不到文档
        retrieved_docs.append(doc['_source'])
    return retrieved_docs
    # 5. (可选) 使用 LLM 生成答案 (这部分需要结合具体的 LLM 模型和 API)
    # ...

# 示例查询
query = "服务器启动不了怎么办？"
results = rag_search(query)

# 打印检索到的文档
for doc in results:
    print(f"Title: {doc['title']}")
    print(f"Content: {doc['content']}")
    print("---")

# (可选) 使用 LLM 生成答案
# ...

代码解释：

连接到 Elasticsearch 和 Milvus： 使用 elasticsearch 和 pymilvus 库分别连接到 Elasticsearch 和 Milvus 集群。
定义 Elasticsearch 索引和 Milvus Collection：
- Elasticsearch 索引：定义文档字段（title、content、tags 等）。
- Milvus Collection：定义字段（id、doc_id、embedding），其中 doc_id 用于关联 Elasticsearch 文档，embedding 存储文档向量。
加载数据到 Elasticsearch 和 Milvus：
- 使用 SentenceTransformer 加载预训练的 Sentence Transformer 模型。
- 遍历示例文档，将文档插入 Elasticsearch，同时计算文档向量并插入 Milvus。
执行 RAG 检索：
- rag_search 函数：
  - 将用户查询向量化。
  - 在 Milvus 中进行向量相似度检索，获取匹配的文档 ID 列表。
  - 在 Elasticsearch 中使用 mget 批量检索文档内容。
  - 整合 Milvus 和 Elasticsearch 的检索结果。
  - (可选) 使用 LLM 生成答案 (这部分需要结合具体的 LLM 模型和 API，代码中未包含)。

重要说明：

向量维度： 代码中假设使用 768 维的向量 (与 all-mpnet-base-v2 模型匹配)。如果使用不同的 Sentence Transformer 模型，需要调整 dim 参数。
索引类型和参数： Milvus 中使用了 IVF_FLAT 索引，并设置了 nlist 和 nprobe 参数。这些参数会影响检索速度和精度，需要根据实际数据集大小和性能要求进行调整。
错误处理： 示例代码中省略了一些错误处理逻辑 (例如，连接失败、检索失败等)。在生产环境中，需要添加适当的错误处理机制。
LLM 集成： 代码中未包含 LLM 生成答案的部分。这部分需要根据选择的 LLM 模型 (例如，OpenAI GPT 系列、LLaMA 等) 和 API 进行实现。通常，需要将检索到的文档内容作为上下文，与用户查询一起输入到 LLM 中，生成最终答案。
数据同步: 在实际应用中，需要考虑文档数据和向量数据的实时同步，避免数据不一致。

1.4 应用程序部署 (可选)

如果需要将 RAG 应用程序部署为服务，可以使用 Docker 和 Docker Compose 进行容器化部署。

Dockerfile 示例：

FROM python:3.9

WORKDIR /app

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY . .

CMD ["python", "app.py"]

docker-compose.yml 示例 (包含 Elasticsearch, Milvus 和 RAG 应用程序)：

version: '3.7'

services:
  elasticsearch:
    # ... (Elasticsearch 配置，参考 1.2.1) ...

  milvus:
    # ... (Milvus 配置，参考 1.2.2) ...

  rag_app:
    build: .
    ports:
      - "8000:8000"  # 假设应用程序监听 8000 端口
    depends_on:
      - elasticsearch
      - milvus
    environment:
      ELASTICSEARCH_HOSTS: elasticsearch:9200  # 使用服务名称作为主机名
      MILVUS_HOST: milvus
      MILVUS_PORT: 19530

启动服务：

1	docker-compose up -d

2. 技术栈需求分析

技术组件	版本/最低版本要求	依赖说明
操作系统	CentOS 7/8, Ubuntu 18.04/20.04 或其他 Linux 发行版
Java	1.8.0-openjdk-devel	Elasticsearch 依赖
Python	3.7+
Elasticsearch	7.17.1 (建议) 或 7.x 系列
Milvus	2.2.14 (建议) 或 2.x 系列
pymilvus	2.2.14 (与 Milvus 版本匹配)
elasticsearch	7.17.1 (与 Elasticsearch 版本匹配)
sentence-transformers	最新版本	用于文本向量化
Docker (可选)	最新版本
Docker Compose (可选)	最新版本
LLM (可选)	根据需要选择，如 OpenAI GPT 系列、LLaMA,ChatGLM等	需要根据 LLM 提供的 API 进行集成

3. 机器配置建议与范围

组件	CPU 核心数	内存 (GB)	存储 (GB)	网络带宽	备注
Elasticsearch	4+	8+	SSD: 100+ (可扩展)	千兆或万兆网卡	Elasticsearch 对 CPU 和内存要求较高，存储空间根据文档数量和大小确定。建议使用 SSD 存储以获得更好的性能。
Milvus	4+	16+	SSD: 50+ (可扩展)	千兆或万兆网卡	Milvus 对内存要求较高，用于存储向量索引。存储空间根据向量数量和维度确定。建议使用 SSD 存储。
RAG 应用程序	2+	4+	50+	千兆网卡	应用程序的资源需求取决于并发请求量和 LLM 模型大小 (如果使用)。

说明：

以上配置为建议范围，具体配置需要根据实际负载和性能需求进行调整。
对于大规模的知识库，建议使用分布式部署 Elasticsearch 和 Milvus，以提高性能和可扩展性。
如果使用 LLM，LLM 的计算资源需求通常较高，建议使用 GPU 服务器。

4. 方案原理分析

RAG (Retrieval-Augmented Generation) 原理：

我会由浅入深，一步一步地解释 RAG 的概念、原理、优势、应用场景以及代码示例，力求让对 RAG 有一个清晰而深入的理解。

1. RAG 的定义：检索增强生成

RAG (Retrieval-Augmented Generation) 的全称是 “检索增强生成”。顾名思义，它是一种结合了 信息检索 (Retrieval) 和 文本生成 (Generation) 的技术。

RAG 的核心思想是： 在生成文本的过程中，先从外部知识库中检索出相关的信息，然后将检索到的信息融入到生成模型的输入中，从而增强生成文本的质量和信息量。

简单来说，RAG 就是让大语言模型在生成答案之前，先“查阅资料”，然后再“组织语言”回答问题。

2. RAG 解决的问题：标准 LLM 的局限性

为了理解 RAG 的必要性，先来看看标准大语言模型 (例如直接使用 GPT-3/4 等) 在某些场景下的局限性：

知识的“时效性”问题 (Knowledge Cut-off): 大多数预训练的 LLM 的知识都停留在训练数据截止的时间点。对于训练数据之后出现的新知识、新事件，模型可能一无所知，或者给出过时的信息。例如，询问 LLM 关于最近发生的某个新闻事件，它可能无法给出准确的回答。
缺乏特定领域或私有知识: 通用 LLM 在通用知识方面表现出色，但对于特定领域 (例如医学、法律、金融) 或私有数据 (例如企业内部文档、个人知识库) 的知识可能非常有限。直接使用通用 LLM 难以处理这些特定领域或私有知识相关的任务。
“幻觉”问题 (Hallucination): LLM 有时会生成一些听起来很流畅，但实际上是不真实、不准确，甚至完全捏造的信息，这就是所谓的 “幻觉” 问题。尤其是在需要事实性知识的任务中，LLM 的幻觉问题会严重影响其可靠性。
缺乏可追溯性 (Lack of Traceability): 标准 LLM 生成答案的过程通常是黑箱的，很难知道模型生成某个答案的依据是什么，它从哪里“学到”了这个知识。这在一些需要解释性和可信度的场景下是一个问题。

RAG 技术正是为了解决上述标准 LLM 的局限性而提出的。 通过引入外部知识检索机制，RAG 可以让 LLM：

获取最新的知识: 从实时更新的知识库中检索信息，克服知识的“时效性”问题。
利用特定领域或私有知识: 对接特定领域或私有的知识库，让模型能够回答相关领域的专业问题或访问企业内部数据。
减少 “幻觉”: 生成答案时有外部知识作为依据，可以减少模型“无中生有”的幻觉问题，提高答案的事实性和准确性。
提高可追溯性: 可以追溯生成答案所依据的外部知识来源，提高模型的可解释性和可信度。

3. RAG 的核心流程和组件

RAG 的核心流程主要分为两个阶段：

阶段 1: 检索 (Retrieval)

目标: 从外部知识库中检索出与用户查询 (Query) 最相关的信息片段 (Documents)。
关键步骤:
1. 构建索引 (Indexing): 将外部知识库中的文档 (例如文本、网页、PDF 等) 进行预处理，例如分段 (chunking)，然后使用嵌入模型 (Embedding Model) (例如 Sentence-BERT, OpenAI Embeddings) 将每个文档片段转换为向量表示 (Vector Embeddings)。将这些向量表示存储到向量数据库 (Vector Database) (例如 FAISS, Milvus, Pinecone, Weaviate) 中，并建立索引，以便快速检索。
2. 查询向量化 (Query Embedding): 接收用户的查询 (例如用户提出的问题)，同样使用相同的嵌入模型将查询转换为查询向量 (Query Embedding)。
3. 相似度搜索 (Similarity Search): 在向量数据库中，使用查询向量与所有文档片段的向量进行相似度搜索 (Similarity Search) (例如余弦相似度、点积)。找到与查询向量最相似的 Top-K 个文档片段 (即相关性最高的文档片段)。
输出: 检索到的 Top-K 个相关文档片段。

阶段 2: 增强生成 (Augmented Generation)

目标: 将检索到的相关文档片段融入到 LLM 的输入中，让 LLM 基于这些信息生成更准确、更丰富的答案。
关键步骤:
1. 构建增强的 Prompt (Augmented Prompt): 将用户的原始查询 (Query) 和检索到的相关文档片段 (Context Documents) 组合成一个新的 增强的 Prompt。常见的组合方式包括：
  - 简单拼接: 将文档片段直接拼接在查询前面或后面。
  - Prompt 工程: 设计更复杂的 Prompt 模板，例如：
    1
    2
    3
    4
    5
    6
    7
    8
    "请根据以下上下文信息回答问题：\n"
    "上下文信息:\n"
    "[文档片段 1]\n"
    "[文档片段 2]\n"
    "...\n"
    "[文档片段 K]\n"
    "问题: [用户查询]\n"
    "答案:"
2. 输入 LLM 生成 (Generation): 将构建好的 增强的 Prompt 输入到预训练的 LLM 中 (例如 GPT-3/4, LLaMA 等)。 LLM 基于增强的 Prompt 生成答案。
输出: LLM 生成的 增强的答案 (Augmented Answer)。

RAG 流程图示:

+-----------------+      +---------------------+      +----------------------+      +-------------------+
| 用户查询 (Query) |----->| 信息检索 (Retrieval)  |----->| 增强的 Prompt        |----->| LLM 生成 (Generation)|-----> 增强的答案 (Answer)
+-----------------+      +---------------------+      +----------------------+      +-------------------+
       |                      |                          |
       |                      v                          |
       |              外部知识库 (Knowledge Base)          |
       |                (已索引的文档片段)                  |
       +-------------------------------------------------+

RAG 的核心组件:

外部知识库 (Knowledge Base): 存储需要检索的文档数据，可以是文本文件、网页、数据库、知识图谱等。
文档索引 (Document Index): 对知识库中的文档进行索引，通常使用向量数据库和向量索引技术，以支持高效的相似度搜索。
嵌入模型 (Embedding Model): 用于将文档片段和查询转换为向量表示，以便进行相似度计算。
LLM (Large Language Model): 预训练的大语言模型，用于生成最终的答案。
Prompt 工程 (Prompt Engineering): 设计有效的 Prompt 模板，将检索到的信息和用户查询有效地组合起来，输入给 LLM。

4. RAG 的优势和特点

增强知识 (Knowledge Augmentation): 让 LLM 具备了访问和利用外部知识库的能力，突破了模型自身知识的限制。
提高事实性 (Factuality): 生成答案有外部知识作为依据，减少幻觉，提高答案的准确性和可靠性。
可定制化 (Customizable): 可以根据不同的应用场景，选择不同的知识库、嵌入模型和 LLM，灵活定制 RAG 系统。
可解释性 (Explainability): 可以追溯生成答案的知识来源，提高模型的可解释性和可信度。
易于更新 (Updatable): 知识库可以独立更新和维护，无需重新训练 LLM，即可让系统获取最新的知识。
模块化 (Modular): RAG 系统是模块化的，检索模块和生成模块可以独立开发和优化。

5. RAG 的不同实现方式和进阶技巧

RAG 的实现方式和技巧有很多，可以根据不同的需求进行选择和优化。一些常见的 RAG 进阶技巧包括：

文档分段策略 (Document Chunking Strategies): 如何将文档分割成合适的片段 (chunk) 大小，会影响检索效果和生成质量。常见的策略有固定大小分段、基于语义的分段等。
高级检索技术 (Advanced Retrieval Techniques):
- 语义搜索 (Semantic Search): 使用更先进的语义相似度计算方法，提高检索的准确性和相关性。
- 混合搜索 (Hybrid Search): 结合关键词搜索和向量搜索的优点，提高检索效果。
- 查询重写 (Query Rewriting): 对用户查询进行改写或扩展，使其更适合向量搜索。
- 多跳检索 (Multi-hop Retrieval): 对于复杂问题，可能需要多次检索，逐步获取相关信息。
- 检索结果重排序 (Re-ranking): 对检索到的文档片段进行重排序，选择更重要的信息。
增强生成策略 (Augmented Generation Strategies):
- Prompt 工程优化: 设计更有效的 Prompt 模板，更好地引导 LLM 利用检索到的信息。
- 答案抽取 (Answer Extraction): 从检索到的文档片段中直接抽取答案，而不是完全依赖 LLM 生成。
- 生成过程控制 (Generation Control): 控制 LLM 的生成过程，例如使用约束解码 (Constrained Decoding) 或引导生成 (Guided Generation) 技术，确保生成答案符合特定的要求。
- 多文档融合 (Multi-document Fusion): 如何有效地融合来自多个文档片段的信息，生成连贯和一致的答案。
RAG 系统的评估 (RAG Evaluation): 如何评估 RAG 系统的性能，例如检索质量、生成质量、答案的事实性、相关性、流畅性等。常用的评估指标包括 Recall, Precision, F1, BLEU, ROUGE, 答案相关性评估指标等。

6. RAG 的应用场景

RAG 技术在各种需要利用外部知识的场景下都有广泛的应用：

问答系统和聊天机器人 (Question Answering and Chatbots):
- 知识密集型问答: 例如针对百科知识、产品文档、法律法规等知识库的问答。
- 企业内部知识库问答: 让员工快速获取企业内部文档、知识库中的信息。
- 客服聊天机器人: 基于产品手册、FAQ 文档等知识库回答用户咨询。
- 研究助手: 帮助研究人员快速检索和总结学术文献。
内容创作和生成 (Content Creation and Generation):
- 信息丰富的文章生成: 例如基于维基百科、新闻报道等知识库生成文章。
- 产品描述生成: 基于产品信息数据库生成产品描述。
- 报告生成: 基于行业报告、数据分析报告等生成报告。
搜索引擎和知识检索 (Search Engines and Knowledge Retrieval):
- 语义搜索引擎: 提供更精准、更智能的搜索结果，不仅仅基于关键词匹配，而是基于语义理解。
- 垂直领域搜索引擎: 例如医学搜索引擎、法律搜索引擎等。
- 知识图谱问答: 结合知识图谱和 RAG 技术，实现更深入的知识问答。
教育和学习 (Education and Learning):
- 智能辅导系统: 基于教材、题库等知识库为学生提供个性化辅导。
- 在线学习平台: 提供课程内容检索、答疑解惑等功能。
其他领域: 金融分析、法律咨询、医学诊断辅助、新闻摘要、智能推荐等。

7. RAG 代码示例 (Python with LangChain - 概念演示)

以下是一个使用 Python 库 LangChain 演示 RAG 基本流程的简化代码示例 (仅为概念演示，可能需要根据实际情况调整):

from langchain.embeddings.openai import OpenAIEmbeddings
from langchain.vectorstores import FAISS
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain.llms import OpenAI
from langchain.chains import RetrievalQA

# 1. 准备知识库文档 (示例)
documents = [
    "LangChain is a framework for developing applications powered by language models.",
    "RAG (Retrieval-Augmented Generation) combines retrieval and generation for enhanced LLMs.",
    "Vector databases like FAISS are used for efficient similarity search."
]

# 2. 文档分段 (Chunking)
text_splitter = RecursiveCharacterTextSplitter(chunk_size=100, chunk_overlap=0)
texts = text_splitter.create_documents(documents)

# 3. 创建 OpenAI 嵌入模型
embeddings = OpenAIEmbeddings()

# 4. 构建向量数据库索引 (FAISS)
db = FAISS.from_documents(texts, embeddings)

# 5. 创建 OpenAI LLM 模型
llm = OpenAI()

# 6. 创建 RetrievalQA 链 (RAG 链)
qa_chain = RetrievalQA.from_chain_type(
    llm=llm,
    retriever=db.as_retriever() # 使用 FAISS 向量数据库作为检索器
)

# 7. 用户查询
query = "What is Retrieval-Augmented Generation?"

# 8. 执行 RAG 查询
result = qa_chain({"query": query})

# 9. 输出结果
print("Question:", query)
print("Answer:", result["result"]) # LLM 生成的增强答案
print("Source Documents:")
for doc in result["source_documents"]: # 检索到的源文档片段
    print(doc.page_content)
    print("-" * 20)

代码说明:

这个示例使用了 LangChain 库，这是一个流行的用于构建 LLM 应用的框架，简化了 RAG 的实现。
步骤 1-4: 构建向量数据库索引。使用 OpenAIEmbeddings 将文档片段向量化，并使用 FAISS 创建向量数据库索引。
步骤 5: 创建 OpenAI LLM 模型 (需要配置 OpenAI API Key)。
步骤 6: 使用 RetrievalQA.from_chain_type 创建 RAG 链，将 LLM 和向量数据库检索器连接起来。
步骤 7-9: 执行 RAG 查询。输入用户查询，RAG 链会自动进行检索和生成，输出增强的答案和检索到的源文档片段。

要运行此代码:

确保已安装 langchain, openai, faiss-cpu 等库: pip install langchain openai faiss-cpu
需要配置 OpenAI API Key，并设置环境变量 OPENAI_API_KEY。
将代码复制到 Python 环境中运行。

RAG (Retrieval-Augmented Generation) 是一种强大的技术，它通过结合信息检索和文本生成，显著提升了大语言模型的能力，使其能够更好地利用外部知识，生成更准确、更可靠、更丰富的文本。 RAG 在问答系统、聊天机器人、内容创作等领域都有广泛的应用前景，是构建下一代智能应用的关键技术之一。

希望这份详细的解析能够帮助深入理解 RAG 技术。如果还有其他问题，欢迎随时提出！

Elasticsearch 和 Milvus 在 RAG 架构中的角色：

Elasticsearch: 存储运维知识文档的元数据 (标题、内容、标签等)，并提供基于关键词的快速检索功能。
Milvus: 存储文档的向量表示 (embeddings)，并提供高效的向量相似度检索功能。

数据流：

数据准备： 运维知识文档被处理成结构化数据 (如 JSON 格式)，并提取文本内容。
文档索引：
- 文档元数据被索引到 Elasticsearch 中。
- 文档文本内容使用 Sentence Transformer 模型转换为向量表示，并存储到 Milvus 中。
用户查询： 用户输入查询 (自然语言)。
检索：
- 用户查询被转换为向量表示。
- Milvus 根据向量相似度检索最相关的文档向量。
- 根据 Milvus 返回的文档 ID，从 Elasticsearch 中检索文档元数据。
生成 (可选)： 检索到的文档内容和用户查询被输入到 LLM 中，生成最终答案。

关键技术点：

Sentence Embeddings: 使用 Sentence Transformer 模型将文本转换为向量表示，能够捕捉文本的语义信息。
向量相似度检索： Milvus 提供高效的向量相似度检索，支持多种距离度量 (如欧氏距离、余弦相似度)。
关键词检索： Elasticsearch 提供基于关键词的快速检索，可以作为向量检索的补充或过滤条件。
LLM 集成： (可选) 使用 LLM 生成更自然、更准确的答案。

5. 方案优点分析

检索效果好： 结合了关键词检索和语义检索的优势，能够更准确地找到相关文档。
性能高： Elasticsearch 和 Milvus 都针对检索进行了优化，能够快速响应用户查询。
可扩展性好： Elasticsearch 和 Milvus 都支持分布式部署，可以水平扩展以应对大规模数据。
灵活性强： 可以根据需要选择不同的 Sentence Transformer 模型和 LLM 模型。
支持语义理解： 基于向量的检索能够理解用户查询的语义，而不仅仅是关键词匹配。

6. 方案缺点分析

复杂性较高： 需要部署和维护多个组件 (Elasticsearch, Milvus, RAG 应用程序)，增加了系统的复杂性。
资源消耗： Elasticsearch 和 Milvus 都需要一定的计算和存储资源，特别是 Milvus 对内存的需求较高。
数据同步： 需要确保 Elasticsearch 和 Milvus 中的数据同步，避免数据不一致。
技术栈要求： 需要熟悉 Elasticsearch、Milvus、Sentence Transformer、Python 等技术。
冷启动问题: 需要预先加载和索引数据，对于新加入的文档，需要重新计算向量并更新索引。

7. 应用场景分析

适用场景：

大规模运维知识库： 适用于需要存储和检索大量运维文档的场景，例如 IT 运维、设备维护、故障排除等。
需要语义理解的问答系统： 能够理解用户查询的语义，提供更准确的答案。
需要结合关键词和语义检索的场景： 可以同时利用关键词检索和语义检索的优势。
对性能和可扩展性有要求的场景： Elasticsearch 和 Milvus 都支持分布式部署，可以满足高性能和可扩展性的需求。

不适用场景：

实时性要求极高的场景： RAG 架构的检索和生成过程需要一定的时间，不适合实时性要求极高的场景。
数据量非常小的场景： 对于数据量非常小的场景，可能不需要使用 RAG 架构，简单的关键词检索即可满足需求。
成本极其敏感的场景： Elasticsearch 和 Milvus 的部署和维护需要一定的成本，对于成本极其敏感的场景可能不适用。
无向量化模型或算力不足的场景：向量化计算需要合适的模型和算力支持。

RAG的关键点在哪里？

RAG（Retrieval-Augmented Generation）的关键在于它成功地融合了信息检索（Retrieval）和文本生成（Generation）这两个方面的优势，从而克服了传统方法各自的局限性。更具体地说，RAG的关键点可以总结为以下几个方面：

结合检索与生成： 这是RAG最核心的思想。传统的生成模型（如GPT系列）虽然能生成流畅的文本，但容易产生“幻觉”（hallucination），即生成的内容可能不真实、不准确或与事实不符。而传统的检索系统虽然能返回相关信息，但无法生成流畅、自然的答案。RAG通过先检索相关信息，再基于检索结果进行生成，既保证了答案的准确性，又保证了答案的流畅性。
向量表示（Embeddings）： RAG 架构通常依赖于向量数据库（如 Milvus）和预训练的语言模型（如 Sentence Transformers）。
- 向量数据库： 用于存储文档的向量表示，并提供高效的向量相似度检索。
- 预训练语言模型： 将文本（无论是文档还是用户查询）转换为向量表示，这些向量能够捕捉文本的语义信息。通过计算向量之间的相似度（如余弦相似度），可以找到语义上相关的文档。
检索的准确性与覆盖率： RAG的效果很大程度上取决于检索到的文档的质量。
- 准确性： 检索到的文档需要与用户查询高度相关。这要求向量表示能够准确捕捉语义信息，向量数据库的索引和搜索算法能够高效地找到最相关的文档。
- 覆盖率： 检索到的文档需要尽可能全面地覆盖与用户查询相关的信息。这要求文档库足够大，且包含足够多样的信息。
生成模型的选择与微调： RAG通常使用大型语言模型（LLM）作为生成器。
- 模型选择： 不同的LLM有不同的特点和优势。需要根据具体应用场景选择合适的LLM。
- 微调（Fine-tuning）： 可以使用特定领域的数据对LLM进行微调，使其更适应特定任务。
检索与生成的融合方式： RAG模型如何将检索到的信息与生成模型结合，也是一个关键点。
- 早期融合： 将检索到的文档与用户查询一起输入到生成模型中。
- 后期融合： 先让生成模型独立生成答案，再将检索到的文档作为补充信息。
- 迭代融合： 多次迭代检索和生成过程，不断优化答案。
Prompt Engineering: 如何构造输入给 LLM 的 prompt 非常关键。一个好的 prompt 可以引导 LLM 生成更符合要求的答案。在 RAG 中，prompt 通常包含用户查询和检索到的文档内容。
可解释性与可控性: RAG 相比单纯的生成模型，具有更好的可解释性，因为可以追踪答案的来源（检索到的文档）。这也带来了一定程度的可控性，可以通过调整检索策略或文档库来影响生成的结果。

总结起来，RAG 的关键在于：高质量的向量表示、高效的向量检索、强大的生成模型、以及检索与生成的有效融合。这些关键点共同作用，使得 RAG 能够在各种任务中取得优秀的性能。

Embedding模型的影响

Embedding 模型是影响 RAG 准确率的核心因素之一。选择合适的 Embedding 模型对于构建高效的 RAG 系统至关重要。以下是一些选择 Embedding 模型时需要考虑的关键因素和步骤：

1. 明确任务需求和数据集特点：

任务类型： 不同的 NLP 任务（如文本分类、问答、信息检索、语义相似度计算等）可能需要不同类型的 Embedding 模型。
领域： 的数据集是通用领域的（如新闻、维基百科）还是特定领域的（如医学、法律、金融）？特定领域的模型可能在特定领域的数据上表现更好。
语言： 的数据集是哪种语言？有些模型是多语言的，有些模型只支持特定语言。
文本长度： 的文本是短文本（如句子、标题）还是长文本（如段落、文章）？不同的模型对文本长度的处理能力不同。
数据集规模： 的数据集有多大？较大的数据集可能允许训练或微调更大的模型。

2. 考虑模型的性能指标：

准确率/召回率/F1 分数： 对于分类任务，这些是常用的评估指标。
MRR (Mean Reciprocal Rank) / NDCG (Normalized Discounted Cumulative Gain)： 对于信息检索任务，这些是常用的评估指标。
相关性/一致性： 对于语义相似度计算任务，可以使用人工评估或相关性数据集来评估。
推理速度： 模型生成 Embedding 的速度有多快？这对于实时应用很重要。
资源消耗： 模型需要多少内存和计算资源？这对于部署环境有限制的情况下很重要。

3. 了解可用的 Embedding 模型类型：

Word Embeddings (如 Word2Vec, GloVe, FastText)： 这些模型将单词映射到向量。它们通常用于捕捉单词级别的语义信息。
- 优点： 训练速度快，资源消耗较低。
- 缺点： 无法处理未登录词（OOV），无法捕捉上下文信息。
Sentence Embeddings (如 Sentence-BERT, Universal Sentence Encoder)： 这些模型将整个句子或段落映射到向量。
- 优点： 能够捕捉上下文信息，能够处理未登录词，更适合句子级别的语义相似度计算。
- 缺点： 训练速度较慢，资源消耗较高。
Transformer-based Models (如 BERT, RoBERTa, ELECTRA)： 这些模型基于 Transformer 架构，能够捕捉更复杂的语义信息。
- 可以提取句子特征, 也可以提取单词特征
- 优点： 性能通常更好，能够捕捉更长距离的依赖关系。
- 缺点： 训练速度更慢，资源消耗更高。

4. 评估和比较不同的模型：

使用公开的基准数据集： 在类似的任务的公开基准数据集上评估不同模型的性能。例如：
- SQuAD: 问答数据集。
- GLUE: 自然语言理解数据集。
- STS Benchmark: 语义文本相似度数据集。
- MTEB (Massive Text Embedding Benchmark): 包含多种任务和多种语言的数据集。
在的数据集上进行实验： 使用的数据集对不同模型进行微调或评估，选择在的数据集上表现最好的模型。
考虑模型的预训练数据： 了解模型是在什么数据上预训练的。如果模型的预训练数据与的数据集领域相似，则模型可能表现更好。
考虑社区的经验和推荐： 许多研究者和开发者会在博客、论坛、论文中分享他们使用不同 Embedding 模型的经验。

5. 其他考虑因素：

可解释性： 如果需要理解模型为什么做出某个预测，可以选择具有更好可解释性的模型。
可维护性： 选择易于部署和维护的模型。
社区支持： 选择有活跃社区支持的模型，以便在遇到问题时获得帮助。

具体模型推荐（一些例子）：

通用领域：
- Sentence-BERT (all-mpnet-base-v2, all-MiniLM-L6-v2)： 在许多任务上表现良好，是一个不错的通用选择。
- Universal Sentence Encoder (USE)： 由 Google 开发，在多种语言上表现良好。
特定领域：
- BioBERT: 在生物医学领域表现良好。
- FinBERT: 在金融领域表现良好。
- Legal-BERT: 在法律领域表现良好.

选择 Embedding 模型没有一刀切的解决方案。需要根据的具体任务需求、数据集特点和资源限制，进行综合考虑和实验，才能选择最合适的模型。可以先从一些通用的、性能较好的模型开始尝试，然后根据需要进行调整。

Embedding模型的比对（参考）

下面是对一些常用的 Embedding 模型进行更全面的优缺点对比，涵盖了 Word Embeddings、Sentence Embeddings 和 Transformer-based Models，以及一些特定领域的模型。

1. Word Embeddings:

模型	优点	缺点	适用场景
Word2Vec	训练速度快，资源消耗低；能够捕捉单词之间的语义关系（如同义词、反义词）；有大量的预训练模型可用。	无法处理未登录词（OOV）；无法捕捉上下文信息（一词多义）；忽略了词序。	单词级别的语义分析；词汇相似度计算；作为其他模型的输入特征。
GloVe	与 Word2Vec 类似，但训练目标不同（基于全局词共现矩阵）；在某些任务上可能比 Word2Vec 略好。	与 Word2Vec 类似。	与 Word2Vec 类似。
FastText	与 Word2Vec 类似，但考虑了字符级别的 n-gram 信息；能够处理未登录词；对于形态丰富的语言（如德语、俄语）效果更好。	训练速度比 Word2Vec 慢；模型大小比 Word2Vec 大。	词形变化丰富的语言；处理包含未登录词的文本；文本分类。

2. Sentence Embeddings:

模型	优点	缺点	适用场景
Sentence-BERT (SBERT)	能够捕捉句子级别的语义信息；在语义相似度任务上表现出色；有多种预训练模型可用（针对不同任务和语言）；可以使用不同的 Pooling 策略（如 CLS, MEAN, MAX）。	训练速度比 Word Embeddings 慢；资源消耗较高。	句子级别的语义相似度计算；文本聚类；信息检索；问答系统。
Universal Sentence Encoder (USE)	由 Google 开发；支持多种语言；有两种版本：基于 Transformer 的版本和基于 DAN (Deep Averaging Network) 的版本；DAN 版本速度更快，资源消耗更低；Transformer 版本精度更高。	DAN 版本在某些任务上可能不如 Transformer 版本准确；Transformer 版本资源消耗较高。	多语言文本相似度计算；文本分类；问答系统。
InferSent	由 Facebook 开发；基于 BiLSTM 架构；在一些自然语言推理任务上表现良好。	训练速度较慢；资源消耗较高；在某些任务上可能不如 Sentence-BERT。	自然语言推理；文本蕴含；句子关系判断。

3. Transformer-based Models:

模型	优点	缺点	适用场景
BERT	基于 Transformer 架构；能够捕捉深层次的语义信息；在多种 NLP 任务上取得了 SOTA 结果；有多种预训练模型可用（针对不同任务和语言）；可以进行微调。	训练速度慢；资源消耗高；对长文本的处理能力有限。	几乎所有 NLP 任务：文本分类、问答、命名实体识别、情感分析等。
RoBERTa	BERT 的改进版；使用了更大的训练数据和更长的训练时间；在一些任务上比 BERT 更好。	与 BERT 类似。	与 BERT 类似。
ELECTRA	使用了更高效的预训练方法（替换 Token 检测）；在相同计算资源下，性能通常比 BERT 更好。	与 BERT 类似。	与 BERT 类似。
ALBERT	BERT 的轻量级版本；使用了参数共享和矩阵分解等技术来减少模型大小和提高训练速度；在保持性能的同时，降低了资源消耗。	在某些任务上可能不如 BERT 或 RoBERTa。	对资源有限制的场景；需要快速训练或部署的场景。
DistilBERT	BERT 的蒸馏版本；模型更小，速度更快，同时保留了 BERT 的大部分性能。	性能略低于 BERT。	对资源有限制的场景；需要快速推理的场景。
XLNet	基于自回归的预训练方法；能够捕捉双向上下文信息；在一些任务上比 BERT 更好。	训练速度慢；资源消耗高。	需要捕捉长距离依赖关系的任务；生成任务。
T5 (Text-to-Text Transfer Transformer)	将所有 NLP 任务都转化为文本生成任务；可以使用相同的模型和训练流程处理多种任务；在一些任务上取得了 SOTA 结果。	模型较大；资源消耗高。	需要处理多种 NLP 任务的场景；生成任务。
MPNet	结合了 BERT 和 XLNet 的优点, 通过排列语言建模（Permutation Language Modeling）进行预训练, 提升效果和性能.	模型相对较大, 资源消耗高.	适用于广泛的自然语言处理任务，尤其是在需要良好平衡准确性和效率的情况下.
4. 特定领域模型:

模型	领域	优点	缺点	适用场景
BioBERT	生物医学	在生物医学领域 NLP 任务上表现出色；能够捕捉领域特定的语义信息。	仅适用于生物医学领域。	生物医学文本挖掘；问答。
FinBERT	金融	在金融领域 NLP 任务上表现出色。	仅适用于金融领域。	金融文本分析；情感分析。
Legal-BERT	法律	在法律领域 NLP 任务上表现出色。	仅适用于法律领域。	法律文本分析；合同审查。
SciBERT	科学	在科学文献 NLP 任务上表现出色。	仅适用于科学文献领域.	科学文献分析；问答.

总结:

如果资源有限，或者需要快速原型验证： 可以考虑 Word2Vec, GloVe, FastText, 或 DistilBERT。
如果需要捕捉句子级别的语义信息： 可以考虑 Sentence-BERT 或 Universal Sentence Encoder。
如果需要最好的性能： 可以考虑 BERT, RoBERTa, ELECTRA, XLNet, T5 或 MPNet，并根据具体任务进行微调。
如果处理特定领域的文本： 可以考虑使用领域特定的模型（如 BioBERT, FinBERT, Legal-BERT）。

请注意，这只是一个大致的对比，实际选择时还需要结合的具体情况进行实验和评估。建议从 huggingface models 库中搜索 “sentence-transformers” 标签，可以找到大量可直接使用的预训练 Sentence Transformer 模型, 并且附有详细的性能指标, 可以帮助你进行选择.

免责声明

本报告（“基于 Elasticsearch 和 Milvus 的 RAG 运维知识库(包含详尽的技术实现细节、可运行的示例代码、Embedding的参考比对）”）由[ViniJack.SJX] 根据公开可获得的信息以及作者的专业知识和经验撰写，旨在提供关于原理、技术、相关框架和工具的分析和信息。

1. 信息准确性与完整性：

作者已尽最大努力确保报告中信息的准确性和完整性，但不对其绝对准确性、完整性或及时性做出任何明示或暗示的保证。
报告中的信息可能随时间推移而发生变化，作者不承担更新报告内容的义务。
报告中引用的第三方信息（包括但不限于网站链接、项目描述、数据统计等）均来自公开渠道，作者不对其真实性、准确性或合法性负责。

2. 报告用途与责任限制：

本报告仅供参考和学习之用，不构成任何形式的投资建议、技术建议、法律建议或其他专业建议。
读者应自行判断和评估报告中的信息，并根据自身情况做出决策。
对于因使用或依赖本报告中的信息而导致的任何直接或间接损失、损害或不利后果，作者不承担任何责任。

3. 技术使用与合规性：

本报告中提及的任何爬虫框架、工具或技术，读者应自行负责其合法合规使用。
在使用任何爬虫技术时，读者应遵守相关法律法规（包括但不限于数据隐私保护法、知识产权法、网络安全法等），尊重网站的服务条款和robots协议，不得侵犯他人合法权益。
对于因读者违反相关法律法规或不当使用爬虫技术而导致的任何法律责任或纠纷，作者不承担任何责任。

4. 知识产权：

本报告的版权归作者所有，未经作者书面许可，任何人不得以任何形式复制、传播、修改或使用本报告的全部或部分内容。
报告中引用的第三方内容，其知识产权归原作者所有。

5. 其他：

本报告可能包含对未来趋势的预测，这些预测基于作者的判断和假设，不构成任何形式的保证。
作者保留随时修改本免责声明的权利。

请在使用本报告前仔细阅读并理解本免责声明。如果不同意本免责声明的任何条款，请勿使用本报告。

基于 Elasticsearch 和 Milvus 的 RAG 运维知识库的实现方法以及落地步骤

http://acorner.ac.cn/2025/02/28/基于 Elasticsearch 和 Milvus 的 RAG 运维知识库(包含详尽的技术实现细节、可运行的示例代码、Embedding的参考比对）/

作者

ViniJack.SJX

发布于

2025-02-28

更新于

2025-02-28

许可协议

#LLM 原理对比分析 RAG 食用文档

You need to set install_url to use ShareThis. Please set it in _config.yml.

基于 Elasticsearch 和 Milvus 的 RAG 运维知识库的实现方法以及落地步骤

1. 极其详细的部署步骤 (包含详尽的技术实现细节和分步骤、可运行的示例代码-也只能给示例代码)

1.1 环境准备

1.2 组件安装配置

1.2.1 Elasticsearch 安装配置

1.2.2 Milvus 安装配置

1.2.3 安装 Python 依赖

1.3 组件集成 (RAG 应用程序)

1.4 应用程序部署 (可选)

2. 技术栈需求分析

3. 机器配置建议与范围

4. 方案原理分析

RAG (Retrieval-Augmented Generation) 原理：

Elasticsearch 和 Milvus 在 RAG 架构中的角色：

5. 方案优点分析

6. 方案缺点分析

7. 应用场景分析

RAG的关键点在哪里？

Embedding模型的影响

Embedding模型的比对（参考）

作者

发布于

更新于

许可协议

喜欢这篇文章？打赏一下作者吧

评论

链接

订阅更新

follow.it

分类

最新文章

归档

标签