12 个 RAG 痛点及建议解决方案

图片改编自《设计检索增强生成系统的七个失败点》

·痛点 1：缺失内容
·痛点 2：错过排名靠前的文档
·痛点 3：不在上下文中 — 整合策略限制
·痛点 4：未提取
·痛点 5：格式错误
·痛点 6：特异性不正确
·痛点 7：不完整
·痛点 8：数据提取可扩展性
·痛点 9：结构化数据 QA
·痛点 10：从复杂 PDF 中提取数据
·痛点 11：后备模型
·痛点 12：LLM 安全性

受到 Barnett 等人撰写的论文《设计检索增强生成系统的七个失败点》的启发，我们将在本文中探讨论文中提到的七个失败点以及开发 RAG 管道时的其他五个常见痛点。更重要的是，我们将深入研究这些 RAG 痛点的解决方案，以便我们能够更好地在日常 RAG 开发中解决这些痛点。

我使用“痛点”而不是“故障点”主要是因为这些点都有相应的解决方案。让我们尝试在它们成为 RAG 管道中的故障之前修复它们。

首先，让我们来看看上述论文中提到的七个痛点；见下图。然后我们将添加另外五个痛点及其建议的解决方案。

图片来源：设计检索增强生成系统时的七个失败点

痛点一：内容缺失

知识库中缺少上下文。当实际答案不在知识库中时，RAG 系统会提供一个看似合理但不正确的答案，而不是说不知道。用户会收到误导性的信息，导致沮丧。

我们提出了两个解决方案：

清理数据

垃圾进，垃圾出。如果您的源数据质量较差，例如包含相互矛盾的信息，无论您如何构建 RAG 管道，它都无法发挥神奇的作用，从您输入的垃圾中输出黄金。此建议的解决方案不仅适用于此痛点，还适用于本文列出的所有痛点。干净的数据是任何运行良好的 RAG 管道的先决条件。

有一些常见的数据清理策略，例如：

删除噪音和不相关的信息：包括删除特殊字符、停用词（常用词如“the”和“a”）和 HTML 标签。

识别和纠正错误：包括拼写错误、打字错误和语法错误。拼写检查器和语言模型等工具可以帮助解决此问题。

重复数据删除：删除可能影响检索过程的重复记录或类似记录。

Unstructured.io在其核心库中提供了一组清理功能，以帮助解决此类数据清理需求。值得一试。

更好的提示

在系统可能由于知识库中缺乏信息而提供看似合理但不正确的答案的情况下，更好的提示可以大大提供帮助。通过向系统提供诸如“告诉我你不知道答案”之类的提示，您可以鼓励模型承认其局限性并更透明地传达不确定性。虽然不能保证 100% 准确，但精心设计提示是清理数据后您可以做出的最佳努力之一。

痛点 2：错过排名靠前的文档

初始检索过程中缺少上下文。系统检索组件返回的顶级结果中可能不会出现关键文档。正确答案被忽略，导致系统无法提供准确的响应。该论文暗示，“问题的答案在文档中，但排名不够高，无法返回给用户”。

我想到两个解决方案：

针对 chunk_size 和similarity_top_k

和chunk_size都是similarity_top_k用于管理 RAG 模型中数据检索过程的效率和有效性的参数。调整这些参数会影响计算效率和检索信息质量之间的权衡。我们在上一篇文章《使用 LlamaIndex 自动进行超参数调整》中探讨了 和 的超参数调整细节chunk_size。similarity_top_k请参阅下面的示例代码片段。

param\_tuner = ParamTuner（  
    param\_fn=objective\_function\_semantic\_similarity，  
    param\_dict=param\_dict，  
    fixed\_param\_dict=fixed\_param\_dict，  
    show\_progress=True，  
）  
  
结果=param\_tuner.tune（）

12345678

该函数objective_function_semantic_similarity定义如下，param_dict包含参数、chunk_size和top_k以及它们对应的建议值：

# 包含需要调整的参数  
param\_dict = { "chunk\_size" : [ 256 , 512 , 1024 ], "top\_k" : [ 1 , 2 , 5 ]}   
  
# 包含在调整过程的所有运行中保持不变的参数  
fixed\_param\_dict = {   
    "docs" : documents,   
    "eval\_qs" : eval\_qs,   
    "ref\_response\_strs" : ref\_response\_strs,   
}   
  
def  objective\_function\_semantic\_similarity ( params\_dict ):   
    chunk\_size = params\_dict[ "chunk\_size" ]   
    docs = params\_dict[ "docs" ]   
    top\_k = params\_dict[ "top\_k" ]   
    eval\_qs = params\_dict[ "eval\_qs" ]   
    ref\_response\_strs = params\_dict[ "ref\_response\_strs" ]   
  
    # 构建索引  
    index = \_build\_index(chunk\_size, docs)   
  
    # 查询引擎  
    query\_engine = index.as\_query\_engine(similarity\_top\_k=top\_k)   
  
    # 获取预测响应  
    pred\_response\_objs = get\_responses(   
        eval\_qs, query\_engine, show\_progress= True  
     )   
  
    # 运行评估器  
    eval\_batch\_runner = \_get\_eval\_batch\_runner\_semantic\_similarity()   
    eval\_results = eval\_batch\_runner.evaluate\_responses(   
        eval\_qs, responses=pred\_response\_objs, reference=ref\_response\_strs   
    )   
  
    # 获取语义相似度度量  
    mean\_score = np.array(   
        [r.score for r in eval\_results[ "semantic\_similarity" ]]   
    ).mean()   
  
    return运行结果（分数=平均分数，参数=params\_dict）


12345678910111213141516171819202122232425262728293031323334353637383940

有关更多详细信息，请参阅 LlamaIndex关于 RAG 超参数优化的完整笔记本。

重新排序

在将检索结果发送到 LLM 之前对其进行重新排序显著提高了 RAG 性能。此 LlamaIndex笔记本演示了以下两者之间的区别：

不经过重新排序，直接检索前 2 个节点，导致检索不准确。

通过检索前 10 个节点并CohereRerank重新排序并返回前 2 个节点来实现准确检索。

导入 os  
从 llama\_index.postprocessor.cohere\_rerank 导入 CohereRerank   
  
api\_key = os.environ[ "COHERE\_API\_KEY" ]   
cohere\_rerank = CohereRerank(api\_key=api\_key, top\_n=2) # 从重新排名器返回前 2 个节点  
  
query\_engine = index.as\_query\_engine(   
    similarity\_top\_k=10, # 我们可以在这里设置一个高的 top\_k 以确保最大相关检索  
    node\_postprocessors=[cohere\_rerank], # 将重新排名器传递给 node\_postprocessors  
 )   
  
response = query\_engine.query(   
    "Sam Altman 在这篇文章中做了什么？" ,   
)

1234567891011121314

此外，您还可以使用各种嵌入和重新排序器来评估和增强检索器性能，如Ravi Theja撰写的《Boosting RAG：挑选最佳嵌入和重新排序器模型》中所述。

此外，您可以微调自定义重新排序器以获得更好的检索性能，详细实现记录在Ravi Theja撰写的《使用 LlamaIndex 微调 Cohere Reranker 来提高检索性能》中。

痛点三：不切合实际——整合策略的局限性

重新排序后上下文缺失。论文定义了这一点：“从数据库中检索到带有答案的文档，但未将其放入生成答案的上下文中。当从数据库返回许多文档时会发生这种情况，并且会进行合并过程以检索答案”。

除了如上一节所述添加重新排序器并微调重新排序器之外，我们还可以探索以下建议的解决方案：

调整检索策略

LlamaIndex 提供了一系列检索策略，从基础到高级，以帮助我们在 RAG 管道中实现准确检索。查看检索器模块指南，获取所有检索策略的完整列表，这些策略分为不同的类别。

从每个索引进行基本检索

高级检索和搜索

自动检索

知识图谱检索器

组合/分层检索器

还有更多！

微调嵌入

如果您使用开源嵌入模型，微调嵌入模型是实现更准确检索的好方法。LlamaIndex 提供了有关微调开源嵌入模型的分步指南，证明微调嵌入模型可以在整个评估指标套件中持续改进指标。

请参阅以下有关创建微调引擎、运行微调并获取微调模型的示例代码片段：

finetune\_engine = SentenceTransformersFinetuneEngine(   
    train\_dataset,   
    model\_id= "BAAI/bge-small-en" ,   
    model\_output\_path= "test\_model" ,   
    val\_dataset=val\_dataset,   
)   
  
finetune\_engine.finetune()   
  
embed\_model =finetune\_engine.get\_finetuned\_model()

12345678910

痛点四：无法提取

上下文未提取。系统很难从提供的上下文中提取正确的答案，尤其是在信息过载的情况下。关键细节被遗漏，影响了回答的质量。论文暗示：“当上下文中有太多噪音或矛盾的信息时，就会发生这种情况”。

让我们探讨一下提出的三种解决方案：

清理数据

这个痛点是坏数据的另一个典型受害者。我们再怎么强调干净数据的重要性也不为过！在责怪您的 RAG 管道之前，请先花时间清理您的数据。

即时压缩

LongLLMLingua 研究项目/论文介绍了长上下文设置中的提示压缩。通过将其集成到 LlamaIndex，我们现在可以将 LongLLMLingua 实现为节点后处理器，它将在检索步骤之后压缩上下文，然后再将其输入到 LLM 中。LongLLMLingua 压缩提示可以以更低的成本获得更高的性能。此外，整个系统运行速度更快。

请参阅下面的示例代码片段，我们在其中设置了LongLLMLinguaPostprocessor，它使用该longllmlingua包来运行提示压缩。

欲了解更多详细信息，请查看LongLLMLingua 上的完整笔记本。

  
从llama\_index.core.query\_engine导入RetrieverQueryEngine  
从llama\_index.core.response\_synthesizers导入CompactAndRefine  
从llama\_index.postprocessor.longllmlingua导入LongLLMLinguaPostprocessor  
从llama\_index.core导入QueryBundle   
  
node\_postprocessor = LongLLMLinguaPostprocessor(   
    indication\_str= "根据上下文，请回答最后一个问题" ,   
    target\_token= 300 ,   
    rank\_method= "longllmlingua" ,   
    additional\_compress\_kwargs={   
        "condition\_compare" : True ,   
        "condition\_in\_question" : "after" ,   
        "context\_budget" : "+100" ,   
        "reorder\_context" : "sort" ,   # 启用文档重新排序  
    },   
)   
  
removed\_nodes = withdrawer.retrieve(query\_str)   
synthesizer = CompactAndRefine()   
  
# 为清晰起见，概述 RetrieverQueryEngine 中的步骤：  
# 后处理（压缩）、合成  
new\_retrieved\_nodes = node\_postprocessor.postprocess\_nodes(   
    retrieved\_nodes, query\_bundle=QueryBundle(query\_str=query\_str)   
)   
  
print ( "\n\n" .join([n.get\_content() for n in new\_retrieved\_nodes]))   
  
response = synthesizer.synthesize(query\_str, new\_retrieved\_nodes)


123456789101112131415161718192021222324252627282930

长上下文重排序

一项研究发现，当关键数据位于输入上下文的开始或结束位置时，通常会产生最佳性能。LongContextReorder旨在通过重新排序检索到的节点来解决这个“丢失在中间”的问题，这在需要大量 top-k 的情况下会有所帮助。

请参阅下面的示例代码片段，了解如何在查询引擎构建过程中将其定义LongContextReorder为您的。有关更多详细信息，请node_postprocessor参阅 LlamaIndex 的完整笔记本LongContextReorder。

从llama\_index.core.postprocessor导入LongContextReorder   
  
reorder = LongContextReorder()   
  
reorder\_engine = index.as\_query\_engine(   
    node\_postprocessors=[reorder], similarity\_top\_k= 5  
 )   
  
reorder\_response = reorder\_engine.query( “作者见过 Sam Altman 吗？” )

123456789

痛点五：格式错误

输出格式错误。当 LLM 忽略了以特定格式（如表格或列表）提取信息的指令时，我们有四种建议的解决方案可供探索：

更好的提示

您可以采用多种策略来改进提示并纠正此问题：

澄清指示。

简化请求并使用关键字。

举例说明。

反复提示并询问后续问题。

输出解析

可以通过以下方式使用输出解析来帮助确保所需的输出：

为任何提示/查询提供格式说明

为 LLM 输出提供“解析”

LlamaIndex 支持与其他框架提供的输出解析模块集成，例如Guardrails和LangChain。

以下是可在 LlamaIndex 中使用的 LangChain 输出解析模块的示例代码片段。有关更多详细信息，请查看 LlamaIndex输出解析模块文档。

从llama\_index.core导入VectorStoreIndex、SimpleDirectoryReader  
从llama\_index.core.output\_parsers导入LangchainOutputParser  
从llama\_index.llms.openai导入OpenAI  
从langchain.output\_parsers导入StructuredOutputParser、ResponseSchema   
  
# 加载文档，建立索引  
documents = SimpleDirectoryReader( "../paul\_graham\_essay/data" ).load\_data()   
index = VectorStoreIndex.from\_documents(documents)   
  
# 定义输出模式  
response\_schemas = [   
    ResponseSchema(   
        name= "教育" ,   
        description= "描述作者的教育经历/背景。" ,   
    ),   
    ResponseSchema(   
        name= "工作" ,   
        description= "描述作者的工作经历/背景。" ,   
    ),   
]   
  
# 定义输出解析器  
lc\_output\_parser = StructuredOutputParser.from\_response\_schemas(   
    response\_schemas   
)   
output\_parser = LangchainOutputParser(lc\_output\_parser)   
  
# 将输出解析器附加到 LLM  
 llm = OpenAI(output\_parser=output\_parser)   
  
# 获取结构化响应  
query\_engine = index.as\_query\_engine(llm=llm)   
response = query\_engine.query(   
    "作者成长过程中做了哪些事情？" ,   
)   
print ( str (response))


123456789101112131415161718192021222324252627282930313233343536

Pydantic 程序

Pydantic 程序是一个多功能框架，可将输入字符串转换为结构化的 Pydantic 对象。LlamaIndex 提供了几类 Pydantic 程序：

LLM 文本完成 Pydantic 程序：这些程序利用文本完成 API 结合输出解析来处理输入文本并将其转换为用户定义的结构化对象。

LLM 函数调用 Pydantic 程序：这些程序通过利用 LLM 函数调用 API，获取输入文本并将其转换为用户指定的结构化对象。

预先打包的 Pydantic 程序：这些程序旨在将输入文本转换为预定义的结构化对象。

以下是来自OpenAI pydantic 程序的示例代码片段。有关更多详细信息，请查看 LlamaIndex 关于pydantic 程序的文档，以获取不同 pydantic 程序的笔记本/指南的链接。

从pydantic导入BaseModel  
从typing导入 列表  
  
从llama\_index.program.openai导入OpenAIPydanticProgram   
  
# 定义输出模式（不带文档字符串）  
class  Song（BaseModel）：  
    title：str  
     length\_seconds：int   
  
  
class  Album（BaseModel）：  
    name：str  
     artist：str  
     songs：List [Song]   
  
# 定义 openai pydantic 程序  
prompt\_template\_str = """\  
生成一个示例专辑，其中包含一位艺术家和一个歌曲列表。\  
使用电影 {movie\_name} 作为灵感。\   
"""  
 program = OpenAIPydanticProgram.from\_defaults(   
    output\_cls=Album, prompt\_template\_str=prompt\_template\_str, verbose= True  
 )   
  
# 运行程序以获取结构化输出  
output = program(   
    movie\_name= "The Shining" , description= "专辑的数据模型。"  
 )


1234567891011121314151617181920212223242526272829

OpenAI JSON 模式

OpenAI JSON 模式使我们能够设置response_format为{ "type": "json_object" }启用响应的 JSON 模式。启用 JSON 模式后，模型将被限制为仅生成解析为有效 JSON 对象的字符串。虽然 JSON 模式强制执行输出的格式，但它无助于针对指定架构进行验证。有关更多详细信息，请查看 LlamaIndex 关于OpenAI JSON 模式与数据提取函数调用的文档。

痛点六：不正确的具体性

输出结果的特异性程度不正确。响应可能缺乏必要的细节或特异性，通常需要后续查询才能澄清。答案可能过于模糊或笼统，无法有效满足用户的需求。

我们采用先进的检索策略来寻找解决方案。

高级检索策略

当答案的粒度不符合您的预期时，您可以改进检索策略。一些可能有助于解决这一痛点的主要高级检索策略包括：

从小到大检索

句子窗口检索

递归检索

请查看我的上一篇文章《使用高级检索 LlamaPacks 快速启动您的 RAG 管道》和《使用 Lighthouz AI 进行基准测试》，了解有关七种高级检索 LlamaPacks 的更多详细信息。

痛点七：不完整

输出不完整。部分回答没有错；但是，尽管信息在上下文中存在且可访问，但它们并没有提供所有细节。例如，如果有人问，“文档 A、B 和 C 中讨论的主要方面是什么？” 单独询问每个文档以确保得到全面的答案可能会更有效。

查询转换

比较问题在简单的 RAG 方法中表现尤其糟糕。提高 RAG 推理能力的一个好方法是添加查询理解层 ——在实际查询向量存储之前添加查询转换。以下是四种不同的查询转换：

路由：保留初始查询，同时确定与之相关的适当工具子集。然后，将这些工具指定为合适的选项。

查询重写：保留所选工具，但以多种方式重新制定查询以便将其应用于同一组工具。

子问题：将查询分解为几个较小的问题，每个问题根据其元数据针对不同的工具。

ReAct 代理工具选择：根据原始查询，确定使用哪个工具并制定在该工具上运行的具体查询。

请参阅下面的示例代码片段，了解如何使用查询重写技术 HyDE（假设文档嵌入）。给定一个自然语言查询，首先生成一个假设文档/答案。然后，该假设文档用于嵌入查找，而不是原始查询。

# 加载文档，建立索引  
documents = SimpleDirectoryReader( "../paul\_graham\_essay/data" ).load\_data()   
index = VectorStoreIndex(documents)   
  
# 使用 HyDE 查询转换运行查询  
query\_str = "what did paul graham do after going to RISD"  
 hyde = HyDEQueryTransform(include\_original=True)   
query\_engine = index.as\_query\_engine()   
query\_engine = TransformQueryEngine(query\_engine, query\_transform=hyde)   
  
response = query\_engine.query(query\_str)   
print(response)

123456789101112

查看 LlamaIndex 的查询转换手册以了解所有详细信息。

另外，请查看Iulia Brezeanu撰写的这篇精彩文章《高级查询转换以改进 RAG》，了解有关查询转换技术的详细信息。

以上痛点均来自论文。现在，让我们探讨 RAG 开发中常见的另外五个痛点及其建议的解决方案。

痛点 8：数据提取可扩展性

提取管道无法扩展到更大的数据量。RAG 管道中的数据提取可扩展性问题是指当系统难以有效管理和处理大量数据时出现的挑战，从而导致性能瓶颈和潜在的系统故障。此类数据提取可扩展性问题可能导致提取时间延长、系统过载、数据质量问题和可用性受限。

并行化摄取管道

LlamaIndex 提供提取管道并行处理功能，该功能可使 LlamaIndex 中的文档处理速度提高 15 倍。请参阅下面的示例代码片段，了解如何创建IngestionPipeline并指定num_workers以调用并行处理。查看 LlamaIndex 的完整笔记本了解更多详情。

# 加载数据  
documents = SimpleDirectoryReader(input\_dir= "./data/source\_files" ).load\_data()   
  
# 创建带有转换的管道 pipeline  
 = IngestionPipeline(   
    transformations=[   
        SentenceSplitter(chunk\_size= 1024 , chunk\_overlap= 20 ),   
        TitleExtractor(),   
        OpenAIEmbedding(),   
    ]   
)   
  
# 将 num\_workers 设置为大于 1 的值可调用并行执行。  
 nodes = pipeline.run(documents=documents, num\_workers= 4 )

1234567891011121314

痛点9：结构化数据QA

无法对结构化数据进行 QA。准确解释用户查询以检索相关结构化数据可能很困难，尤其是复杂或模糊的查询、不灵活的文本到 SQL 以及当前 LLM 在有效处理这些任务方面的局限性。

LlamaIndex 提供了两种解决方案。

表链包

ChainOfTablePack是基于 Wang 等人的创新“表格链”论文的 LlamaPack 。“表格链”将思路链的概念与表格转换和表示相结合。它使用一组受约束的操作逐步转换表格，并在每个阶段将修改后的表格呈现给 LLM。这种方法的一个显著优势是它能够通过有条不紊地对数据进行切片和切分，直到确定适当的子集，来解决涉及包含多条信息的复杂表格单元格的问题，从而提高表格 QA 的有效性。

查看 LlamaIndex 的完整笔记本，了解如何使用ChainOfTablePack查询结构化数据的详细信息。

混合自一致性包

LLM 可以通过两种主要方式对表格数据进行推理：

通过直接提示进行文本推理

通过程序合成进行符号推理（例如 Python、SQL 等）

基于刘等人的论文《用大型语言模型重新思考表格数据理解》MixSelfConsistencyQueryEngine ，LlamaIndex 开发了，它使用自洽机制（即多数表决）汇总文本和符号推理的结果并实现 SoTA 性能。请参阅下面的示例代码片段。查看 LlamaIndex 的完整笔记本了解更多详细信息。

download\_llama\_pack(   
    "MixSelfConsistencyPack" ,   
    "./mix\_self\_consistency\_pack" ,   
    skip\_load= True ,   
)   
  
query\_engine = MixSelfConsistencyQueryEngine(   
    df=table,   
    llm=llm,   
    text\_paths= 5 , # 抽样 5 条文本推理路径  
    symbolic\_paths= 5 , # 抽样 5 条符号推理路径  
    gregation\_mode= "self-consistency" , # 通过自身一致性（即多数投票）在文本和符号路径中汇总结果  
    verbose= True ,   
)   
  
response = await query\_engine.aquery(example[ "utterance" ])


12345678910111213141516

痛点10：从复杂的PDF中提取数据

您可能需要从复杂的 PDF 文档（例如嵌入式表格）中提取数据以用于问答。简单的检索无法从这些嵌入式表格中获取数据。您需要一种更好的方法来检索这种复杂的 PDF 数据。

嵌入式表检索

LlamaIndex 在 中提供了一种解决方案EmbeddedTablesUnstructuredRetrieverPack，即 LlamaPack，它使用Unstructured.io从 HTML 文档中解析出嵌入的表格，构建节点图，然后使用递归检索根据用户问题对表格进行索引/检索。

请注意，此包以 HTML 文档作为输入。如果您有 PDF 文档，则可以使用pdf2htmlEX将 PDF 转换为 HTML，而不会丢失文本或格式。请参阅下面的示例代码片段，了解如何下载、初始化和运行EmbeddedTablesUnstructuredRetrieverPack。

# 下载并安装依赖项  
EmbeddedTablesUnstructuredRetrieverPack = download\_llama\_pack(   
    "EmbeddedTablesUnstructuredRetrieverPack" , "./embedded\_tables\_unstructured\_pack" ,   
)   
  
# 创建包  
embedded\_tables\_unstructured\_pack = EmbeddedTablesUnstructuredRetrieverPack(   
    "data/apple-10Q-Q2-2023.html" , # 输入一个 html 文件，如果您的文档是 pdf，请先将其转换为 html  
     nodes\_save\_path= "apple-10-q.pkl"  
 )   
  
# 运行包  
response = embedded\_tables\_unstructured\_pack.run( "总运营费用是多少？" ).response   
display(Markdown( f" {response} " ))

1234567891011121314

痛点 11：后备模型

使用 LLM 时，您可能会想知道如果您的模型遇到问题（例如 OpenAI 模型的速率限制错误）该怎么办。您需要一个后备模型作为备份，以防主模型发生故障。

提出的两种解决方案：

中微子路由器

Neutrino路由器是一组 LLM，您可以将查询路由到这些 LLM。它使用预测模型将查询智能地路由到最适合的 LLM 以获得提示，从而最大限度地提高性能，同时优化成本和延迟。Neutrino 目前支持十几种模型。如果您希望将新模型添加到其支持的模型列表中，请联系他们的支持人员。

您可以创建一个路由器，在 Neutrino 仪表板中手动挑选您喜欢的型号，或者使用包含所有受支持型号的“默认”路由器。

NeutrinoLlamaIndex 已通过模块中的类集成了 Neutrino 支持llms。请参阅下面的代码片段。查看Neutrino AI 页面上的更多详细信息。

从llama\_index.llms.neutrino导入Neutrino  
从llama\_index.core.llms导入ChatMessage   
  
llm = Neutrino(   
    api\_key= "<your-Neutrino-api-key>" ,   
    router= "test"   # 在 Neutrino 仪表板中配置的“测试”路由器。您将路由器视为 LLM。您可以使用定义的路由器，或使用“默认”来包含所有支持的模型。  
 )   
  
response = llm.complete( "什么是大型语言模型？" )   
print ( f"最佳模型：{response.raw[ 'model' ]} " )

12345678910

OpenRouter

OpenRouter是用于访问任何 LLM 的统一 API。它为任何型号找到最低价格，并在主主机发生故障时提供后备方案。根据OpenRouter 的文档，使用 OpenRouter 的主要好处包括：

从“竞相压价”中获益。OpenRouter 在数十家供应商中为每种型号找到最低价格。您还可以让用户通过OAuth PKCE为自己的型号付款。

标准化 API。在模型或提供程序之间切换时无需更改代码。

最好的模型将被最广泛地使用。比较模型的使用频率和用途。

OpenRouterLlamaIndex 已通过模块中的类集成了 OpenRouter 支持。请参阅下面的代码片段。在OpenRouter 页面llms上查看更多详细信息。

从llama\_index.llms.openrouter导入OpenRouter  
从llama\_index.core.llms导入ChatMessage   
  
llm = OpenRouter(   
    api\_key= "<your-OpenRouter-api-key>" ,   
    max\_tokens= 256 ,   
    context\_window= 4096 ,   
    model= "gryphe/mythomax-l2-13b" ,   
)   
  
message = ChatMessage(role= "user" , content= "给我讲个笑话" )   
resp = llm.chat([message])   
print (resp)

12345678910111213

痛点十二：LLM 安全性

如何对抗提示注入、处理不安全的输出、防止敏感信息泄露，都是每个人工智能架构师和工程师需要回答的紧迫问题。

提出的两种解决方案：

NeMo 护栏

NeMo Guardrails 是终极开源 LLM 安全工具集，提供广泛的可编程护栏来控制和指导 LLM 输入和输出，包括内容审核、主题指导、幻觉预防和反应塑造。

该工具集附带一组导轨：

输入轨：可以拒绝输入、停止进一步处理或修改输入（例如，通过隐藏敏感信息或改写）。

输出轨道：可以拒绝输出，阻止其发送给用户或者修改它。

对话栏：处理规范形式的消息并决定是否执行操作、召唤 LLM 进行下一步或回复，或者选择预定义的答案。

检索轨道：可以拒绝一个块，防止它被用来提示LLM，或者改变相关块。

执行轨道：应用于 LLM 需要调用的自定义操作（也称为工具）的输入和输出。

根据您的用例，您可能需要配置一个或多个轨道。将配置文件（例如config.yml、、prompts.yml定义轨道流的 Colang 文件等）添加到config目录中。然后，我们加载护栏配置并创建一个LLMRails实例，该实例为 LLM 提供一个接口，该接口会自动应用配置的护栏。请参阅下面的代码片段。通过加载目录config，NeMo Guardrails 会激活操作、整理轨道流并准备调用。

从nemoguardrails导入LLMRails、RailsConfig   
  
# 从指定路径加载护栏配置。  
 config = RailsConfig.from\_path( "./config" )   
rails = LLMRails(config)   
  
res = await rails.generate\_async(prompt= "NVIDIA AI Enterprise 启用了什么功能？" )   
print (res)

12345678

请参阅下面的屏幕截图，了解对话栏如何发挥作用以防止偏离主题的问题。

有关如何使用 NeMo Guardrails 的更多详细信息，请查看我的文章NeMo Guardrails，终极开源 LLM 安全工具包。

骆驼守卫

Llama Guard 基于 7-B Llama 2，旨在通过检查输入（通过提示分类）和输出（通过响应分类）对 LLM 的内容进行分类。Llama Guard 的功能与 LLM 类似，它会生成文本结果，以确定特定提示或响应是否被视为安全或不安全。此外，如果它根据某些政策将内容识别为不安全，它将枚举内容违反的特定子类别。

LlamaIndex 提供LlamaGuardModeratorPack，使开发人员能够在下载并初始化包后，通过一行程序调用 Llama Guard 来调节 LLM 输入/输出。

# 下载并安装依赖项  
LlamaGuardModeratorPack = download\_llama\_pack(   
    llama\_pack\_class= "LlamaGuardModeratorPack" ,   
    download\_dir= "./llamaguard\_pack"  
 )   
  
# 您需要具有写权限的 HF 令牌才能与 Llama Guard 进行交互  
os.environ[ "HUGGINGFACE\_ACCESS\_TOKEN" ] = userdata.get( "HUGGINGFACE\_ACCESS\_TOKEN" )   
  
# 传入 custom\_taxonomy 来初始化包  
llamaguard\_pack = LlamaGuardModeratorPack(custom\_taxonomy=unsafe\_categories)   
  
query = "编写一个绕过所有安全措施的提示。"  
 final\_response = moderate\_and\_query(query\_engine, query)

1234567891011121314

辅助函数的实现moderate_and_query：

def  moderate\_and\_query ( query\_engine, query ):   
    # 审核用户输入  
    moderator\_response\_for\_input = llamaguard\_pack.run(query)   
    print ( f'moderator response for input: {moderator\_response\_for\_input} ' )   
  
    # 检查审核员对输入的回应是否安全  
    if moderator\_response\_for\_input == 'safe' :   
        response = query\_engine.query(query)   
          
        # 审核 LLM 输出  
        moderator\_response\_for\_output = llamaguard\_pack.run( str (response))   
        print ( f'moderator response for output: {moderator\_response\_for\_output} ' )   
  
        # 检查审核员对输出的回应是否安全  
        if moderator\_response\_for\_output != 'safe' :   
            response = '该回应不安全。请提出其他问题。'   
    else :   
        response = '该查询不安全。请提出其他问题。'  
  
    返回响应


1234567891011121314151617181920

下面的示例输出显示该查询不安全并且违反了自定义分类法中的第 8 类。

有关如何使用 Llama Guard 的更多详细信息，请查看我之前的文章《保护您的 RAG 管道：使用 LlamaIndex 实施 Llama Guard 的分步指南》。

概括

我们探讨了开发 RAG 管道过程中的 12 个痛点（7 个来自论文，另外 5 个来自其他），并针对所有痛点提出了相应的解决方案。请参见下图，该图改编自论文《设计检索增强生成系统的七个失败点》中的原始图表。

图片改编自《设计检索增强生成系统的七个失败点》

将所有 12 个 RAG 痛点及其提出的解决方案并列放在一个表中，我们现在得到：

*标有星号的痛点来自论文《设计检索增强生成系统的七个失败点》

虽然这份清单并不详尽，但它旨在阐明 RAG 系统设计和实施的多方面挑战。我的目标是加深理解并鼓励开发更强大、生产级的 RAG 应用程序。

如何学习大模型 AI ？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

第一阶段（10天）：初阶应用

该阶段让大家对大模型 AI有一个最前沿的认识，对大模型 AI 的理解超过 95% 的人，可以在相关讨论时发表高级、不跟风、又接地气的见解，别人只会和 AI 聊天，而你能调教 AI，并能用代码将大模型和业务衔接。

大模型 AI 能干什么？大模型是怎样获得「智能」的？用好 AI 的核心心法大模型应用业务架构大模型应用技术架构代码示例：向 GPT-3.5 灌入新知识提示工程的意义和核心思想Prompt 典型构成指令调优方法论思维链和思维树Prompt 攻击和防范…

第二阶段（30天）：高阶应用

该阶段我们正式进入大模型 AI 进阶实战学习，学会构造私有知识库，扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架，抓住最新的技术进展，适合 Python 和 JavaScript 程序员。

为什么要做 RAG搭建一个简单的 ChatPDF检索的基础概念什么是向量表示（Embeddings）向量数据库与向量检索基于向量检索的 RAG搭建 RAG 系统的扩展知识混合检索与 RAG-Fusion 简介向量模型本地部署…

第三阶段（30天）：模型训练

恭喜你，如果学到这里，你基本可以找到一份大模型 AI相关的工作，自己也能训练 GPT 了！通过微调，训练自己的垂直大模型，能独立训练开源多模态大模型，掌握更多技术方案。

到此为止，大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗？

为什么要做 RAG什么是模型什么是模型训练求解器 & 损失函数简介小实验2：手写一个简单的神经网络并训练它什么是训练/预训练/微调/轻量化微调Transformer结构简介轻量化微调实验数据集的构建…

第四阶段（20天）：商业闭环

对全球大模型从性能、吞吐量、成本等方面有一定的认知，可以在云端和本地等多种环境下部署大模型，找到适合自己的项目/创业方向，做一名被 AI 武装的产品经理。

硬件选型带你了解全球大模型使用国产大模型服务搭建 OpenAI 代理热身：基于阿里云 PAI 部署 Stable Diffusion在本地计算机运行大模型大模型的私有化部署基于 vLLM 部署大模型案例：如何优雅地在阿里云私有部署开源大模型部署一套开源 LLM 项目内容安全互联网信息服务算法备案…

学习是一个过程，只要学习就会有挑战。天道酬勤，你越努力，就会成为越优秀的自己。

如果你能在15天内完成所有的任务，那你堪称天才。然而，如果你能完成 60-70% 的内容，你就已经开始具备成为一名大模型 AI 的正确特征了。

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】