1. 项目概述：从问题到答案的智能引擎

最近在折腾大模型应用落地的朋友，估计没少被“幻觉”问题困扰。你问它一个具体的技术细节，它可能给你编造一段看似合理但完全错误的答案。为了解决这个痛点，RAG（检索增强生成）技术应运而生，成了当前让大模型“靠谱”起来的最热门路径之一。而在这个领域，LlamaIndex作为一个专门为构建RAG应用而生的框架，以其清晰的设计和强大的功能，迅速成为了许多开发者的首选工具。

简单来说，这个项目要探讨的，就是如何利用LlamaIndex搭建一套完整的RAG系统工作流程。这不仅仅是调用几个API，而是从用户提出一个问题开始，到系统返回一个准确、有据可依的答案为止，中间所经历的一系列精密“工序”。这个过程涉及如何把你的知识（比如公司内部文档、产品手册、技术资料）有效地“喂”给大模型，如何在用户提问时快速找到最相关的信息片段，以及如何引导大模型基于这些片段生成最终回答。对于任何想基于私有数据构建智能问答、知识库助手或客服机器人的团队来说，掌握这套流程是迈出实质性一步的关键。无论你是后端工程师、算法同学还是产品经理，理解这套机制都能帮你更好地设计、评估和优化你的AI应用。

2. LlamaIndex RAG 核心工作流程全拆解

一套健壮的RAG系统，其核心在于“检索”与“生成”的无缝衔接与相互增强。LlamaIndex将这个过程抽象为一个清晰、可插拔的管道（Pipeline），我们可以将其拆解为五个核心阶段。理解每个阶段的输入、输出和设计考量，是构建高效应用的基础。

2.1 第一阶段：数据加载与预处理——为知识“备料”

任何RAG系统的根基都是数据。这个阶段的目标是将各种格式的原始数据（如PDF、Word、网页、数据库）转化为系统可以处理的标准化文档对象。LlamaIndex提供了丰富的 数据连接器（Data Connectors） ，也称为 Reader ， 用于从不同来源拉取数据。

关键操作与考量：

  1. 选择连接器 ：根据数据源类型选择。例如，用 SimpleDirectoryReader 读取本地文件夹下的多种文件，用 BeautifulSoupWebReader 爬取网页内容，用数据库连接器读取结构化数据。
  2. 处理复杂格式 ：对于PDF，重点处理文本提取的准确性和版面分析；对于PPT，需区分标题和正文；对于网页，则要过滤广告和导航栏等噪音。这一步的质量直接决定了后续检索的“原料”是否纯净。
  3. 文档分块（Chunking）策略初显 ：虽然精细化的分块通常在下一阶段，但在加载时就需要有初步考虑。例如，一个超长的PDF是应该按页、按节还是按固定字符数切割？这需要结合后续的检索模型和内容特性来提前规划。

注意 ：数据加载不是简单的文件读取。对于扫描版PDF，需要集成OCR（如Tesseract）；对于有访问权限的Confluence或Notion页面，需要处理身份认证。务必在加载阶段就确保文本内容被完整、正确地提取出来，否则后续步骤都是徒劳。

2.2 第二阶段：索引构建——建立知识的“图书馆卡片系统”

这是RAG系统的“记忆”形成阶段。目标是将上一步得到的文档，转换成一种便于快速、准确检索的结构化表示。LlamaIndex的核心抽象—— 索引（Index） ，正是在此阶段创建。

核心步骤解析：

  1. 文本分块（Chunking） ：这是本阶段最关键的一步。你不能把整本书扔给检索器，需要将其切成大小适中的片段。常见的策略有：

    • 固定大小分块 ：按字符数或token数切割。简单，但可能割裂完整的语义单元（如一个句子或段落）。
    • 基于分隔符分块 ：按照段落、标题等自然分隔符切割。更符合人类阅读习惯，能保持上下文完整性。
    • 语义分块 ：使用嵌入模型计算句子间的相似度，在语义变化处进行切割。更智能，但计算开销较大。
    • LlamaIndex的实践 ：通常会采用分层或重叠分块。例如，先按段落分块，对于过长的段落再按句子切分，并在块之间保留一部分重叠字符（如100-200字符），以防止关键信息恰好被割裂在边界。

  2. 向量化（Embedding） ：将每个文本块通过一个 嵌入模型（Embedding Model） 转换为一个高维向量（例如1536维）。这个向量就是该文本块语义的数学表示。语义相近的文本，其向量在空间中的距离也更近。

    • 模型选择 ：可以选择OpenAI的 text-embedding-ada-002 ， 开源模型如 BGE-M3 、 text2vec ， 或Cohere的嵌入模型。选择时需权衡效果、速度、成本和数据隐私。

  3. 存储到向量数据库 ：将（向量， 文本块， 元数据）这个三元组存储到专门的 向量数据库（Vector Database） 中，如Pinecone、Chroma、Weaviate、Qdrant或Milvus。向量数据库的核心能力是进行 近似最近邻搜索（ANN） ， 能在毫秒级时间内从百万级向量中找出与问题向量最相似的几个。

  4. 可选：构建摘要索引或关键词索引 ：除了主流的向量索引，LlamaIndex还支持其他索引类型作为补充。例如，为每个文档块生成一个摘要，构建一个“摘要索引”，用于快速进行高层次的主题匹配；或者提取关键词构建倒排索引，用于精确的关键词召回。

2.3 第三阶段：查询与检索——在图书馆中“找书”

当用户提出一个问题（Query）时，系统需要从构建好的“图书馆”中找出最相关的“书籍段落”。这个阶段的核心是 检索器（Retriever） 。

工作流程与策略：

  1. 查询转换 ：有时用户的原始问题可能不够精确。LlamaIndex可以提供查询转换功能，例如：
    • 查询扩写 ：利用LLM将简短问题扩写成多个相关查询，以提高召回率。例如，“Python多线程”可能被扩写为“Python多线程编程指南”、“Python threading模块用法”、“Python GIL与多线程”。
    • 查询重写 ：将口语化问题重写成更正式、更适合检索的语句。
  2. 向量检索 ：将用户问题同样通过嵌入模型向量化，然后在向量数据库中进行相似度搜索（通常使用余弦相似度或点积），返回Top-K个最相似的文本块。这是最核心的检索路径。
  3. 多路召回与混合检索 ：单一检索方式可能有局限。高级的RAG系统会采用混合检索：
    • 向量检索 + 关键词检索 ：向量检索负责语义匹配，关键词检索（如BM25）负责精确词项匹配。两者结果通过算法（如RRF）进行融合重排。
    • 多向量检索 ：对同一个查询，使用不同的嵌入模型进行检索，融合结果，以抵消单一模型可能存在的偏差。
  4. 上下文压缩/重排序（Reranking） ：初步检索到的Top-K个块可能数量较多或包含冗余信息。可以引入一个 重排序模型 （如Cohere Rerank、BGE Reranker）， 对候选片段与问题的相关性进行更精细的评分和重新排序，只保留最相关的少量片段（如Top-3）送给生成阶段。这能显著提升答案质量并减少上下文长度。

2.4 第四阶段：响应生成——基于证据“组织答案”

检索到相关上下文后，需要将其与用户问题一起，构造成一个清晰的提示（Prompt）， 交给大语言模型（LLM）生成最终答案。这个阶段的核心是 响应合成器（Response Synthesizer） 。

提示工程与合成模式：

  1. 提示模板构建 ：设计一个结构化的提示词，通常包含：
    • 系统指令 ：定义LLM的角色和回答要求（如“你是一个专业的助手，请严格根据提供的上下文信息回答问题。”）。
    • 上下文信息 ：将检索到的文本块，以清晰的方式（如用“参考内容1：...”分隔）插入提示中。
    • 用户问题 ：原始问题。
    • 回答格式指令 ：要求模型注明答案来源的片段编号，对于无法回答的情况明确说“不知道”。
  2. 合成模式选择 ：LlamaIndex提供了几种合成策略：
    • Refine ：迭代式生成。先基于第一个上下文块生成一个初始答案，然后依次用后续的上下文块去优化、精炼这个答案。适合信息分散、需要整合的场景，质量高但速度慢。
    • Tree Summarize ：树状归纳。将多个上下文块两两合并摘要，层层向上，最终合成一个答案。适合需要深度理解大量文档的场景。
    • Simple ：最常用。将所有上下文和问题一次性送给LLM，直接生成答案。速度快，但当上下文很长时可能超出模型窗口或导致模型注意力分散。
    • Compact ： Simple 的优化版。会智能地将上下文填充到模型上下文窗口的最大限制内，如果一次填不满，会分批调用模型再整合结果。
  3. LLM调用 ：将构造好的提示发送给LLM（如GPT-4、Claude、本地部署的Llama 3等）， 获取生成的文本响应。

2.5 第五阶段：评估与迭代——让系统“越用越聪明”

一个RAG系统上线并非终点，必须建立评估闭环，持续优化。评估主要围绕三个核心维度：

评估维度与方法：

  1. 检索质量评估 ：
    • 命中率（Hit Rate） ：在Top-K个检索结果中，至少包含一个能回答问题的相关片段的比例。
    • 平均精度均值（MAP） ：考虑相关片段在检索结果列表中的排序位置。
    • 工具 ：可以使用像 RAGAS 、 TruLens 这样的专门评估框架，自动化计算这些指标。
  2. 生成质量评估 ：
    • 忠实度（Faithfulness） ：生成的答案是否严格基于提供的上下文，有没有“胡编乱造”（幻觉）。这是RAG的核心价值所在。
    • 答案相关性（Answer Relevance） ：生成的答案是否直接、完整地回应了原始问题。
    • 可以通过LLM-as-a-Judge ：用另一个更强大的LLM（如GPT-4）来对生成答案的忠实度和相关性进行评分。
  3. 端到端评估 ：
    • 人工评估 ：准备一批测试问题，由领域专家对答案的准确性、有用性进行打分，这是黄金标准。
    • A/B测试 ：在线上对不同的分块策略、检索器或提示模板进行对比测试，看哪个版本的用户满意度更高、任务完成率更好。

迭代优化点 ：根据评估结果，你可能需要回头调整分块大小、重叠窗口、尝试不同的嵌入模型、增加重排序模块、优化提示词模板，甚至补充或清洗数据源。这是一个持续的过程。

3. 关键组件深度解析与选型建议

理解了流程，我们再来深入看看流程中几个关键“齿轮”的选型与调优，这直接决定了系统的性能和成本。

3.1 嵌入模型：语义理解的“标尺”

嵌入模型是将文本映射到向量空间的桥梁，它的质量决定了检索的精度。

  • 闭源 vs 开源 ：
    • 闭源（如OpenAI, Cohere） ：通常效果稳定、领先，且易于使用，但存在API调用成本、数据出境顾虑和潜在延迟。
    • 开源（如BGE系列、text2vec） ：可私有化部署，数据安全可控，零调用成本。当前顶尖的开源模型（如BGE-M3）在MTEB等基准测试上已接近甚至超越部分闭源模型，是许多企业的首选。
  • 维度选择 ：常见维度有384、768、1024、1536等。更高维度通常能承载更丰富的语义信息，但也会增加向量存储和计算开销。对于绝大多数通用场景，768或1024维的模型已经足够。
  • 领域适配 ：如果你的数据是高度专业化的（如法律、医疗），可以考虑使用在该领域语料上继续训练过的嵌入模型，或者使用像 FlagEmbedding 框架提供的针对代码、法律等场景的专用模型。

3.2 向量数据库：海量向量的“管家”

向量数据库负责高效存储和检索向量。

  • 选型考量点 ：
    • 性能 ：查询速度（QPS）、支持的最大向量规模、索引构建速度。
    • 功能 ：是否支持元数据过滤（如按日期、作者筛选）、动态更新、持久化存储。
    • 部署与运维 ：云托管服务（Pinecone, Weaviate Cloud） vs 自托管（Chroma, Qdrant, Milvus）。云服务省心但贵且锁供应商；自托管灵活可控但需要运维投入。
    • 社区与生态 ：是否与LlamaIndex/LangChain集成良好，文档是否齐全。
  • 轻量级入门首选 ： Chroma 。它设计简单，内存+持久化模式切换方便，API与LlamaIndex无缝集成，非常适合原型开发和中小规模项目。
  • 生产级推荐 ： Qdrant 或 Weaviate 。Qdrant用Rust编写，性能优异，资源利用率高，功能全面。Weaviate不仅是一个向量数据库，更是一个“知识图谱向量数据库”，原生支持将数据对象、向量和图关系结合在一起，适合复杂场景。

3.3 LLM选择：答案的“总设计师”

生成答案的最终效果，很大程度上取决于LLM的能力。

  • 闭源大模型（GPT-4, Claude-3） ：在推理、遵循指令和生成质量上通常表现最佳，是追求效果的标杆。但成本高、延迟可能不稳定，且需考虑数据隐私政策。
  • 开源大模型（Llama 3, Qwen2, DeepSeek） ：近年来进步神速，70B参数级别的模型在多项基准上已可比肩GPT-4。通过量化技术（如GGUF, AWQ）可以在消费级显卡上运行。优势是数据完全私有、可控，长期成本低。挑战是需要一定的部署和运维知识。
  • 本地部署工具链 ： Ollama 极大简化了开源模型的下载、运行和管理，是本地实验的绝佳工具。 vLLM 或 TGI 则提供了生产级别的高性能推理服务框架。
  • 选型建议 ：从快速验证开始，可以使用GPT-3.5 Turbo或Claude Haiku这类性价比高的闭源模型。进入生产环节时，如果数据敏感、流量大，强烈建议评估并部署一个优秀的开源模型（如Qwen2-72B-Instruct或Llama 3 70B）， 结合vLLM提供服务，在效果、成本和可控性上取得平衡。

4. 实战构建：一个基于本地化技术的RAG问答系统

理论说得再多，不如动手搭一个。下面我们构建一个完全本地化、可私有部署的RAG问答系统，用于查询技术文档。我们将使用 Chroma （向量库）、 BGE-M3 （嵌入模型）和 Qwen2-7B-Instruct （LLM）， 通过 Ollama 来运行LLM。

4.1 环境准备与依赖安装

首先，创建一个干净的Python环境（推荐3.9+），并安装核心库。

# 创建并激活虚拟环境（可选但推荐）
python -m venv rag_env
source rag_env/bin/activate  # Linux/Mac
# rag_env\Scripts\activate  # Windows

# 安装核心库
pip install llama-index-core
# 安装LlamaIndex的官方集成包，这些包包含了对应组件的专用类
pip install llama-index-vector-stores-chroma  # Chroma向量存储集成
pip install llama-index-embeddings-huggingface  # HuggingFace嵌入模型集成
pip install llama-index-llms-ollama  # Ollama LLM集成

# 安装底层依赖
pip install chromadb pypdf sentence-transformers  # Chroma客户端、PDF解析、嵌入模型框架

注意 ： llama-index 包现在是一个“元包”，通常建议安装 llama-index-core 和具体需要的集成包，这样依赖更清晰。 pypdf 用于解析PDF文档， sentence-transformers 是运行BGE等模型的基础。

4.2 数据加载与索引构建实战

假设我们有一个 docs 文件夹，里面存放了若干PDF格式的技术文档。我们将它们加载、分块、向量化并存储到Chroma中。

import os
from llama_index.core import VectorStoreIndex, SimpleDirectoryReader, StorageContext
from llama_index.core.node_parser import SentenceSplitter
from llama_index.vector_stores.chroma import ChromaVectorStore
from llama_index.embeddings.huggingface import HuggingFaceEmbedding
import chromadb
from chromadb.config import Settings

# 1. 初始化嵌入模型 - 使用BGE-M3，这是一个强大的中英文开源模型
embed_model = HuggingFaceEmbedding(
    model_name="BAAI/bge-m3",  # HuggingFace模型ID
    trust_remote_code=True  # 该模型需要此参数
)

# 2. 初始化Chroma向量数据库客户端
# 持久化到本地目录 `./chroma_db`
chroma_client = chromadb.PersistentClient(path="./chroma_db", settings=Settings(allow_reset=True))
chroma_collection = chroma_client.get_or_create_collection(name="tech_docs")

# 将Chroma集合包装成LlamaIndex能识别的VectorStore
vector_store = ChromaVectorStore(chroma_collection=chroma_collection)

# 3. 配置文本分块器
# 这里采用基于句子的分块，并设置块大小和重叠
node_parser = SentenceSplitter(
    chunk_size=512,  # 每个块的token数目标
    chunk_overlap=100,  # 块之间重叠的token数，防止语义割裂
    separator=" ",  # 分隔符
)

# 4. 加载文档
documents = SimpleDirectoryReader("./docs").load_data()
print(f"已加载 {len(documents)} 个文档")

# 5. 构建索引
# 将文档解析成节点（Node），每个节点对应一个文本块
nodes = node_parser.get_nodes_from_documents(documents)
# 创建存储上下文，指定向量存储
storage_context = StorageContext.from_defaults(vector_store=vector_store)
# 创建向量索引，传入节点、存储上下文和嵌入模型
index = VectorStoreIndex(
    nodes=nodes,
    storage_context=storage_context,
    embed_model=embed_model,
)
print("索引构建完成！")

关键参数解读 ：

  • chunk_size=512 ：这个值需要权衡。太小（如128）会丢失上下文，导致检索到的片段信息不完整；太大（如2048）则可能包含过多无关信息，稀释核心语义，且增加LLM处理负担。对于技术文档，512-1024是一个常见的起点。
  • chunk_overlap=100 ：重叠是为了避免一个完整的句子或概念被硬生生切在两块中间。例如，一个关键定义可能跨了两个块，重叠部分能确保它在两个块中都出现，提高被检索到的概率。
  • BAAI/bge-m3 ：这是北京智源研究院开源的模型，在中文和英文的检索任务上表现都非常出色，且支持多向量检索模式。首次运行时会从HuggingFace下载模型，请确保网络通畅。

4.3 配置本地LLM并创建查询引擎

索引建好后，我们需要配置一个LLM来生成答案。这里使用Ollama运行Qwen2-7B-Instruct模型。

from llama_index.llms.ollama import Ollama
from llama_index.core import Settings

# 1. 配置全局的LLM和Embedding模型
# 确保Ollama服务正在运行，并且已经拉取了qwen2:7b-instruct模型
# 在终端执行：`ollama run qwen2:7b-instruct`
llm = Ollama(model="qwen2:7b-instruct", request_timeout=60.0)

# 将LLM和Embedding模型设置为全局默认，这样创建查询引擎时就不需要每次都指定
Settings.llm = llm
Settings.embed_model = embed_model

# 2. 从持久化的索引中加载查询引擎
# 注意：这里我们直接从存储上下文和向量存储加载索引，避免重新向量化
index_loaded = VectorStoreIndex.from_vector_store(
    vector_store=vector_store, embed_model=embed_model
)
# 创建查询引擎，可以配置检索和生成参数
query_engine = index_loaded.as_query_engine(
    similarity_top_k=5,  # 检索时返回最相似的5个片段
    response_mode="compact",  # 使用compact模式生成响应，会智能处理长上下文
    verbose=True  # 打印详细的检索和生成日志，便于调试
)

# 3. 进行查询
response = query_engine.query("在LlamaIndex中，如何对PDF文档进行分块？")
print("问题：", "在LlamaIndex中，如何对PDF文档进行分块？")
print("答案：", response)
print("\n--- 检索到的来源 ---")
for i, source_node in enumerate(response.source_nodes):
    print(f"[片段 {i+1}]， 相似度得分：{source_node.score:.4f}")
    print(f"内容预览：{source_node.text[:200]}...\n")

执行流程解析 ：

  1. 我们初始化了Ollama LLM，指向本地运行的 qwen2:7b-instruct 模型。 request_timeout 设置为60秒，给模型充足的推理时间。
  2. Settings 类用于管理全局默认配置，这样在代码其他地方创建组件时会更简洁。
  3. from_vector_store 方法从已有的Chroma集合中重建索引对象，无需重新计算向量，速度很快。
  4. 创建 query_engine 时， similarity_top_k=5 表示检索5个相关片段。 response_mode="compact" 是推荐选项，它会自动处理可能超出模型上下文窗口的情况。
  5. 执行查询后，我们不仅打印答案，还输出了每个答案片段的来源和相似度得分，这对于验证答案的可信度至关重要。

4.4 进阶：实现重排序（Reranking）以提升精度

基础检索可能返回一些相关但并非最精准的片段。引入一个重排序模型，可以对Top-K的初步结果进行二次精排，选出最相关的Top-N个送给LLM。

from llama_index.core.postprocessor import SentenceTransformerRerank
from llama_index.core import QueryBundle
from llama_index.core.retrievers import VectorIndexRetriever

# 1. 初始化重排序器（使用一个较小的重排序模型，如BGE的交叉编码器）
rerank = SentenceTransformerRerank(
    model="BAAI/bge-reranker-base",  # 专门用于重排序的模型
    top_n=3  # 从初步结果中选出最相关的3个
)

# 2. 创建自定义检索器
retriever = VectorIndexRetriever(
    index=index_loaded,
    similarity_top_k=10  # 第一步：向量检索召回10个
)

# 3. 自定义查询函数，集成重排序
def query_with_rerank(question):
    # 第一步：检索
    nodes = retriever.retrieve(question)
    print(f"初步检索到 {len(nodes)} 个节点")
    
    # 第二步：重排序
    query_bundle = QueryBundle(query_str=question)
    reranked_nodes = rerank.postprocess_nodes(nodes, query_bundle=query_bundle)
    print(f"重排序后保留 {len(reranked_nodes)} 个节点")
    
    # 第三步：用精排后的节点生成答案
    # 需要手动将这些节点和问题构造给LLM
    from llama_index.core import get_response_synthesizer
    synthesizer = get_response_synthesizer(response_mode="compact")
    response = synthesizer.synthesize(question, reranked_nodes)
    
    return response

# 4. 使用增强后的流程查询
response = query_with_rerank("解释一下LlamaIndex中索引（Index）的概念")
print("答案：", response)

重排序的价值 ：向量检索基于“语义相似度”，而重排序模型（通常是交叉编码器）会同时看问题和候选段落，进行更精细的“相关性”计算。它能够有效将那些“语义相近但并非直接回答问题”的片段排到后面，确保送给LLM的都是“干货”，从而大幅降低幻觉概率，提升答案精准度。

5. 生产环境部署与性能优化考量

当原型验证通过，准备投入生产时，以下几个方面的考量至关重要。

5.1 系统架构设计

一个生产级的RAG系统通常不是单机脚本，而是一个服务。

  • API服务化 ：使用 FastAPI 或 Flask 将核心的查询功能封装成RESTful API。接口至少应包含 /query 端点，接收问题，返回答案和引用来源。
  • 异步处理 ：对于索引构建（尤其是处理大量文档）和可能耗时的LLM调用，使用 asyncio 或 Celery 进行异步任务处理，避免阻塞主请求线程。
  • 缓存层 ：引入 Redis 缓存高频问题的检索结果或生成的答案，能极大降低响应延迟和LLM调用成本。
  • 监控与日志 ：集成 Prometheus 和 Grafana 监控API性能指标（QPS、延迟、错误率）。使用结构化日志（如JSON格式）记录每一次查询的请求、检索片段、生成结果，便于后续分析和问题排查。

5.2 索引更新与增量处理

知识库不是静态的。需要有机制处理新增、更新或删除的文档。

  • 增量更新 ：LlamaIndex支持向已有索引插入新的文档节点。关键是确保新文档的分块和向量化策略与之前一致。对于已修改的文档，一个简单的策略是先删除其对应的所有旧节点（需要元数据记录文档ID），再插入新节点。
  • 版本化管理 ：对于文档频繁更新的场景，可以考虑为索引打标签或版本号。查询时，可以指定版本，或者合并多个版本的结果。
  • 调度任务 ：使用 Apache Airflow 或 Celery Beat 设置定时任务，定期扫描数据源目录或数据库，自动触发索引更新流程。

5.3 性能与成本优化

  • 嵌入模型优化 ：
    • 量化 ：对于开源嵌入模型，可以使用 sentence-transformers 提供的量化功能，将模型从FP32转换为INT8，在几乎不损失精度的情况下大幅提升推理速度和减少内存占用。
    • 批量推理 ：对文档进行向量化时，务必使用批量处理，而不是单条循环，这能充分利用GPU/CPU的并行计算能力。
  • LLM调用优化 ：
    • 提示词压缩 ：在将检索到的上下文送给LLM前，可以尝试用一个小模型或摘要模型对长上下文进行压缩，只保留核心信息，减少token消耗。
    • 流式响应 ：对于生成长答案的场景，启用LLM的流式输出（Streaming），可以让用户更快地看到首个token，提升体验。
    • 缓存重复问题 ：如前所述，利用Redis缓存完全相同的查询。
  • 检索优化 ：
    • 元数据过滤 ：在检索时加入元数据过滤条件（如“文档类型=用户手册”、“发布日期>2023年”），可以快速缩小搜索范围，提升检索速度和准确率。这需要在构建索引时就将相关元数据（文件名、日期、作者等）存入向量数据库。
    • 混合检索调参 ：调整向量检索和关键词检索的权重比例，找到最适合你数据集的平衡点。

5.4 安全与合规

  • 数据隐私 ：如果使用闭源LLM API，务必仔细阅读服务商的数据使用政策。对于高度敏感数据，坚持使用本地化部署的开源模型。
  • 输入输出过滤 ：在API层面对用户输入进行清洗和过滤，防止Prompt注入攻击。对LLM的输出内容也应有基本的审核或过滤机制，避免生成不当内容。
  • 访问控制 ：为RAG API设计认证和授权机制，确保只有授权用户或系统可以访问。如果知识库本身有权限划分，需要在检索时集成权限过滤。

构建一个成熟的RAG系统是一次从算法、工程到运维的全面实践。LlamaIndex提供了优秀的抽象和工具链，让开发者能聚焦于流程设计和业务逻辑。从简单的脚本开始，逐步迭代加入重排序、缓存、服务化、监控等组件，最终你将能得到一个稳定、高效且智能的私有知识问答系统。记住，评估和迭代永无止境，持续用真实用户的问题去测试和优化你的系统，是它保持“聪明”的唯一秘诀。

# RAG
Logo
亚马逊云科技技术品牌专区

更多推荐

cover

别再只聊大模型！AI的下一场革命，藏在“身体”里

avatar 亚马逊云科技技术品牌专区
cover

别再只聊大模型！人工智能的下一场革命，藏在“身体”里

avatar 亚马逊云科技技术品牌专区
cover

别再只聊大模型！AI的下一场革命，藏在“身体”里

avatar 亚马逊云科技技术品牌专区