本文探討了在開發(fā)RAG管道過(guò)程中的12個(gè)痛點(diǎn)(其中7個(gè)來(lái)自論文，另外5個(gè)來(lái)自我們的總結(jié))，并針對(duì)這些痛點(diǎn)提出了相應(yīng)的解決方案。

Barnett等人的論文《Seven Failure Points When Engineering a Retrieval Augmented Generation System》介紹了RAG的七個(gè)痛點(diǎn)，我們將其延申擴(kuò)展再補(bǔ)充開發(fā)RAG流程中常遇到的另外五個(gè)常見問(wèn)題。并且將深入研究這些RAG痛點(diǎn)的解決方案，這樣我們能夠更好地在日常的RAG開發(fā)中避免和解決這些痛點(diǎn)。

這里使用“痛點(diǎn)”而不是“失敗點(diǎn)”，主要是因?yàn)槲覀兛偨Y(jié)的問(wèn)題都有相應(yīng)的建議解決方案。

首先，讓我們介紹上面提到的論文中的七個(gè)痛點(diǎn);請(qǐng)看下面的圖表。然后，我們將添加另外五個(gè)痛點(diǎn)及其建議的解決方案。

以下是論文總結(jié)的7個(gè)痛點(diǎn)：

內(nèi)容缺失

當(dāng)實(shí)際答案不在知識(shí)庫(kù)中時(shí)，RAG系統(tǒng)提供一個(gè)看似合理但不正確的答案，這會(huì)導(dǎo)致用戶得到誤導(dǎo)性信息

解決方案：

在由于知識(shí)庫(kù)中缺乏信息，系統(tǒng)可能會(huì)提供一個(gè)看似合理但不正確的答案的情況下，更好的提示可以提供很大的幫助。比如說(shuō)通過(guò)prompts聲明，如“如果你不確定答案，告訴我你不知道”，這樣可以鼓勵(lì)模型承認(rèn)它的局限性，并更透明地傳達(dá)不確定性。

如果非要模型輸出正確答案而不是承認(rèn)模型不知道，那么就需要增加數(shù)據(jù)源，并且要保證數(shù)據(jù)的質(zhì)量。如果源數(shù)據(jù)質(zhì)量很差，比如包含沖突的信息，那么無(wú)論構(gòu)建的RAG管道有多好，它都無(wú)法從提供給它的垃圾中輸出黃金。這個(gè)建議的解決方案不僅適用于這個(gè)痛點(diǎn)，而且適用于本文中列出的所有痛點(diǎn)。干凈的數(shù)據(jù)是任何運(yùn)行良好的RAG管道的先決條件。

錯(cuò)過(guò)了關(guān)鍵文檔

關(guān)鍵文檔可能不會(huì)出現(xiàn)在系統(tǒng)檢索組件返回的最上面的結(jié)果中。如果正確的答案被忽略，那么會(huì)導(dǎo)致系統(tǒng)無(wú)法提供準(zhǔn)確的響應(yīng)。論文中提到:“問(wèn)題的答案在文檔中，但排名不夠高，無(wú)法返回給用戶?！?/p>

這里有2個(gè)解決方案

1、chunk_size和simility_top_k的超參數(shù)調(diào)優(yōu)

chunk_size和similarity_top_k都是用于管理RAG模型中數(shù)據(jù)檢索過(guò)程的效率和有效性的參數(shù)。調(diào)整這些參數(shù)會(huì)影響計(jì)算效率和檢索信息質(zhì)量之間的權(quán)衡。

 param_tuner = ParamTuner(
    param_fn=objective_function_semantic_similarity,
    param_dict=param_dict,
    fixed_param_dict=fixed_param_dict,
    show_progress=True,
 )


 results = param_tuner.tune()

 # contains the parameters that need to be tuned
 param_dict = {"chunk_size": [256, 512, 1024], "top_k": [1, 2, 5]}


 # contains parameters remaining fixed across all runs of the tuning process
 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"]


    # build index
    index = _build_index(chunk_size, docs)


    # query engine
    query_engine = index.as_query_engine(similarity_top_k=top_k)


    # get predicted responses
    pred_response_objs = get_responses(
        eval_qs, query_engine, show_progress=True
    )


    # run evaluator
    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
    )


    # get semantic similarity metric
    mean_score = np.array(
        [r.score for r in eval_results["semantic_similarity"]]
    ).mean()


    return RunResult(score=mean_score, params=params_dict)

2、Reranking

在將檢索結(jié)果發(fā)送給LLM之前對(duì)其重新排序可以顯著提高RAG的性能。

下面對(duì)比了在沒(méi)有重新排序器的情況下直接檢索前2個(gè)節(jié)點(diǎn)，檢索不準(zhǔn)確；和通過(guò)檢索前10個(gè)節(jié)點(diǎn)并使用CohereRerank重新排序并返回前2個(gè)節(jié)點(diǎn)的精確檢索

 import os
 from llama_index.postprocessor.cohere_rerank import CohereRerank


 api_key = os.environ["COHERE_API_KEY"]
 cohere_rerank = CohereRerank(api_key=api_key, top_n=2) # return top 2 nodes from reranker


 query_engine = index.as_query_engine(
    similarity_top_k=10, # we can set a high top_k here to ensure maximum relevant retrieval
    node_postprocessors=[cohere_rerank], # pass the reranker to node_postprocessors
 )


 response = query_engine.query(
    "What did Sam Altman do in this essay?",
 )

整合策略的局限性導(dǎo)致上下文沖突

包含答案的文檔是從數(shù)據(jù)庫(kù)中檢索出來(lái)的，但沒(méi)有進(jìn)入生成答案的上下文中。當(dāng)從數(shù)據(jù)庫(kù)返回許多文檔時(shí)，就會(huì)發(fā)生這種情況，并且會(huì)進(jìn)行整合過(guò)程來(lái)檢索答案”。

除了上節(jié)所述的Reranking并對(duì)Reranking進(jìn)行微調(diào)之外，我們還可以嘗試以下的解決方案:

1、調(diào)整檢索策略

LlamaIndex提供了從基本到高級(jí)的一系列檢索策略：

Basic retrieval from each index

Advanced retrieval and search

Auto-Retrieval

Knowledge Graph Retrievers

Composed/Hierarchical Retrievers

通過(guò)選擇和嘗試不同的檢索策略可以針對(duì)不同的的需求進(jìn)行定制。

2、threshold嵌入

如果使用開源嵌入模型，那么調(diào)整嵌入模型也是實(shí)現(xiàn)更準(zhǔn)確檢索的好方法。LlamaIndex提供了一個(gè)關(guān)于調(diào)優(yōu)開源嵌入模型的分步指南，證明了調(diào)優(yōu)嵌入模型可以在整個(gè)eval度量套件中一致地提高度量。

以下時(shí)示例代碼片段，包括創(chuàng)建微調(diào)引擎，運(yùn)行微調(diào)，并獲得微調(diào)模型:

 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()

沒(méi)有獲取到正確的內(nèi)容

系統(tǒng)從提供的上下文中提取正確的答案，但是在信息過(guò)載的情況下會(huì)遺漏關(guān)鍵細(xì)節(jié)，這會(huì)影響回復(fù)的質(zhì)量。論文中的內(nèi)容是:“當(dāng)環(huán)境中有太多噪音或相互矛盾的信息時(shí)，就會(huì)發(fā)生這種情況?！?/p>

我們看看如何解決。

1、提示壓縮

LongLLMLingua研究項(xiàng)目/論文介紹了長(zhǎng)上下文環(huán)境下的提示壓縮。通過(guò)將LongLLMLingua集成到LlamaIndex中，可以將其實(shí)現(xiàn)為一個(gè)后處理器，這樣它將在檢索步驟之后壓縮上下文，然后將其輸入LLM。

下面的示例代碼設(shè)置了LongLLMLinguaPostprocessor，它使用longllmlingua包來(lái)運(yùn)行提示壓縮。

 from llama_index.query_engine import RetrieverQueryEngine
 from llama_index.response_synthesizers import CompactAndRefine
 from llama_index.postprocessor import LongLLMLinguaPostprocessor
 from llama_index.schema import QueryBundle


 node_postprocessor = LongLLMLinguaPostprocessor(
    instruction_str="Given the context, please answer the final question",
    target_token=300,
    rank_method="longllmlingua",
    additional_compress_kwargs={
        "condition_compare": True,
        "condition_in_question": "after",
        "context_budget": "+100",
        "reorder_context": "sort", # enable document reorder
    },
 )


 retrieved_nodes = retriever.retrieve(query_str)
 synthesizer = CompactAndRefine()


 # outline steps in RetrieverQueryEngine for clarity:
 # postprocess (compress), synthesize
 new_retrieved_nodes = node_postprocessor.postprocess_nodes(
    retrieved_nodes, query_bundle=QueryBundle(query_str=query_str)
 )


 print("

".join([n.get_content() for n in new_retrieved_nodes]))


 response = synthesizer.synthesize(query_str, new_retrieved_nodes)

當(dāng)關(guān)鍵數(shù)據(jù)位于輸入上下文的開頭或結(jié)尾時(shí)，通常會(huì)出現(xiàn)最佳性能。LongContextReorder旨在通過(guò)重排序檢索到的節(jié)點(diǎn)來(lái)解決這種“中間丟失”的問(wèn)題，這在需要較大top-k的情況下很有幫助。

請(qǐng)參閱下面的示例代碼片段，將LongContextReorder定義為node_postprocessor。

 from llama_index.postprocessor import LongContextReorder


 reorder = LongContextReorder()


 reorder_engine = index.as_query_engine(
    node_postprocessors=[reorder], similarity_top_k=5
 )


 reorder_response = reorder_engine.query("Did the author meet Sam Altman?")

有時(shí)我們要求以特定格式(如表或列表)提取信息，但是這種指令可能會(huì)被LLM忽略，所以我們總結(jié)了4種解決方案:

1、更好的提示詞

澄清說(shuō)明、簡(jiǎn)化請(qǐng)求并使用關(guān)鍵字、給出例子、強(qiáng)調(diào)并提出后續(xù)問(wèn)題。

2、輸出解析

為任何提示/查詢提供格式說(shuō)明，并人工為L(zhǎng)LM輸出提供“解析”

LlamaIndex支持與其他框架(如guarrails和LangChain)提供的輸出解析模塊集成。

下面是可以在LlamaIndex中使用的LangChain輸出解析模塊的示例代碼片段。有關(guān)更多詳細(xì)信息，請(qǐng)查看LlamaIndex關(guān)于輸出解析模塊的文檔。

 from llama_index import VectorStoreIndex, SimpleDirectoryReader
 from llama_index.output_parsers import LangchainOutputParser
 from llama_index.llms import OpenAI
 from langchain.output_parsers import StructuredOutputParser, ResponseSchema


 # load documents, build index
 documents = SimpleDirectoryReader("../paul_graham_essay/data").load_data()
 index = VectorStoreIndex.from_documents(documents)


 # define output schema
 response_schemas = [
    ResponseSchema(
        name="Education",
        description="Describes the author's educational experience/background.",
    ),
    ResponseSchema(
        name="Work",
        description="Describes the author's work experience/background.",
    ),
 ]


 # define output parser
 lc_output_parser = StructuredOutputParser.from_response_schemas(
    response_schemas
 )
 output_parser = LangchainOutputParser(lc_output_parser)


 # Attach output parser to LLM
 llm = OpenAI(output_parser=output_parser)


 # obtain a structured response
 from llama_index import ServiceContext


 ctx = ServiceContext.from_defaults(llm=llm)


 query_engine = index.as_query_engine(service_context=ctx)
 response = query_engine.query(
    "What are a few things the author did growing up?",
 )
 print(str(response))

Pydantic程序作為一個(gè)通用框架，將輸入字符串轉(zhuǎn)換為結(jié)構(gòu)化Pydantic對(duì)象。

可以通過(guò)Pydantic將API和輸出解析相結(jié)合，處理輸入文本并將其轉(zhuǎn)換為用戶定義的結(jié)構(gòu)化對(duì)象。Pydantic程序利用LLM函數(shù)調(diào)用API，接受輸入文本并將其轉(zhuǎn)換為用戶指定的結(jié)構(gòu)化對(duì)象?；蛘邔⑤斎胛谋巨D(zhuǎn)換為預(yù)定義的結(jié)構(gòu)化對(duì)象。

下面是OpenAI pydantic程序的示例代碼片段。

from pydantic import BaseModel
 from typing import List


 from llama_index.program import OpenAIPydanticProgram


 # Define output schema (without docstring)
 class Song(BaseModel):
    title: str
    length_seconds: int




 class Album(BaseModel):
    name: str
    artist: str
    songs: List[Song]


 # Define openai pydantic program
 prompt_template_str = """
 Generate an example album, with an artist and a list of songs. 
 Using the movie {movie_name} as inspiration.
 """
 program = OpenAIPydanticProgram.from_defaults(
    output_cls=Album, prompt_template_str=prompt_template_str, verbose=True
 )


 # Run program to get structured output
 output = program(
    movie_name="The Shining", description="Data model for an album."
 )

OpenAI JSON模式使我們能夠?qū)esponse_format設(shè)置為{"type": "json_object"}。當(dāng)啟用JSON模式時(shí)，模型被約束為只生成解析為有效JSON對(duì)象的字符串，這樣對(duì)后續(xù)處理十分方便。

答案模糊或籠統(tǒng)

LLM得到的答案可能缺乏必要的細(xì)節(jié)或特異性，這種過(guò)于模糊或籠統(tǒng)的答案，不能有效地滿足用戶的需求。

所以就需要一些高級(jí)檢索策略來(lái)決絕這個(gè)問(wèn)題，當(dāng)答案沒(méi)有達(dá)到期望的粒度級(jí)別時(shí)，可以改進(jìn)檢索策略。一些主要的高級(jí)檢索策略可能有助于解決這個(gè)痛點(diǎn)，包括：?

small-to-big retrieval
sentence window retrieval
recursive retrieval

部分結(jié)果沒(méi)有錯(cuò);但是它們并沒(méi)有提供所有的細(xì)節(jié)，盡管這些信息在上下文中是存在的和可訪問(wèn)的。例如“文件A、B和C中討論的主要方面是什么?”，如果單獨(dú)詢問(wèn)每個(gè)文件則可以得到一個(gè)更全面的答案。

這種比較問(wèn)題尤其在傳統(tǒng)RAG方法中表現(xiàn)不佳。提高RAG推理能力的一個(gè)好方法是添加查詢理解層——在實(shí)際查詢向量存儲(chǔ)之前添加查詢轉(zhuǎn)換。下面是四種不同的查詢轉(zhuǎn)換：?

路由：保留初始查詢，同時(shí)確定它所屬的工具的適當(dāng)子集，將這些工具指定為合適的查詢工作。

查詢重寫：但以多種方式重新表述查詢，以便在同一組工具中應(yīng)用查詢。

子問(wèn)題：將查詢分解為幾個(gè)較小的問(wèn)題，每個(gè)問(wèn)題針對(duì)不同的工具。

ReAct：根據(jù)原始查詢，確定要使用哪個(gè)工具，并制定要在該工具上運(yùn)行的特定查詢。

下面的示例代碼使用HyDE(這是一種查詢重寫技術(shù))，給定一個(gè)自然語(yǔ)言查詢，首先生成一個(gè)假設(shè)的文檔/答案。然后使用這個(gè)假設(shè)的文檔進(jìn)行嵌入查詢。

 # load documents, build index
 documents = SimpleDirectoryReader("../paul_graham_essay/data").load_data()
 index = VectorStoreIndex(documents)


 # run query with HyDE query transform
 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)

可擴(kuò)展性

在RAG管道中，數(shù)據(jù)攝取可擴(kuò)展性問(wèn)題指的是當(dāng)系統(tǒng)在處理大量數(shù)據(jù)時(shí)遇到的挑戰(zhàn)，這回導(dǎo)致性能瓶頸和潛在的系統(tǒng)故障。這種數(shù)據(jù)攝取可擴(kuò)展性問(wèn)題可能會(huì)產(chǎn)生攝取時(shí)間延長(zhǎng)、系統(tǒng)超載、數(shù)據(jù)質(zhì)量問(wèn)題和可用性受限等問(wèn)題。

所以就需要進(jìn)行并行化處理，LlamaIndex提供攝并行處理功能可以使文檔處理速度提高達(dá)15倍。

 # load data
 documents = SimpleDirectoryReader(input_dir="./data/source_files").load_data()


 # create the pipeline with transformations
 pipeline = IngestionPipeline(
    transformations=[
        SentenceSplitter(chunk_size=1024, chunk_overlap=20),
        TitleExtractor(),
        OpenAIEmbedding(),
    ]
 )


 # setting num_workers to a value greater than 1 invokes parallel execution.
 nodes = pipeline.run(documents=documents, num_workers=4)

結(jié)構(gòu)化數(shù)據(jù)質(zhì)量

準(zhǔn)確解釋用戶查詢以檢索相關(guān)的結(jié)構(gòu)化數(shù)據(jù)是困難的，特別是在面對(duì)復(fù)雜或模糊的查詢、不靈活的文本到SQL轉(zhuǎn)換方面

LlamaIndex提供了兩種解決方案。

ChainOfTablePack是基于創(chuàng)新性論文“Chain-of-table”將思維鏈的概念與表格的轉(zhuǎn)換和表示相結(jié)合。它使用一組受限制的操作逐步轉(zhuǎn)換表格，并在每個(gè)階段向LLM呈現(xiàn)修改后的表格。這種方法的顯著優(yōu)勢(shì)在于它能夠通過(guò)系統(tǒng)地切片和切塊數(shù)據(jù)來(lái)處理涉及包含多個(gè)信息片段的復(fù)雜表格單元的問(wèn)題。

基于論文Rethinking Tabular Data Understanding with Large Language Models），LlamaIndex開發(fā)了MixSelfConsistencyQueryEngine，該引擎通過(guò)自一致性機(jī)制（即多數(shù)投票）聚合了來(lái)自文本和符號(hào)推理的結(jié)果，并取得了最先進(jìn)的性能。以下是一個(gè)示例代碼。

 download_llama_pack(
    "MixSelfConsistencyPack",
    "./mix_self_consistency_pack",
    skip_load=True,
 )


 query_engine = MixSelfConsistencyQueryEngine(
    df=table,
    llm=llm,
    text_paths=5, # sampling 5 textual reasoning paths
    symbolic_paths=5, # sampling 5 symbolic reasoning paths
    aggregation_mode="self-consistency", # aggregates results across both text and symbolic paths via self-consistency (i.e. majority voting)
    verbose=True,
 )


 response = await query_engine.aquery(example["utterance"])

復(fù)雜PDF文檔中提取數(shù)據(jù)，例如從PDF種嵌入的表格中提取數(shù)據(jù)是一個(gè)很復(fù)雜的問(wèn)題，所以可以嘗試使用pdf2htmllex將PDF轉(zhuǎn)換為HTML，而不會(huì)丟失文本或格式，下面是EmbeddedTablesUnstructuredRetrieverPack示例：

 # download and install dependencies
 EmbeddedTablesUnstructuredRetrieverPack = download_llama_pack(
    "EmbeddedTablesUnstructuredRetrieverPack", "./embedded_tables_unstructured_pack",
 )


 # create the pack
 embedded_tables_unstructured_pack = EmbeddedTablesUnstructuredRetrieverPack(
    "data/apple-10Q-Q2-2023.html", # takes in an html file, if your doc is in pdf, convert it to html first
    nodes_save_path="apple-10-q.pkl"
 )


 # run the pack
 response = embedded_tables_unstructured_pack.run("What's the total operating expenses?").response
 display(Markdown(f"{response}"))

備用模型

在使用語(yǔ)言模型（LLMs）時(shí)，如果的模型出現(xiàn)問(wèn)題，例如OpenAI模型受到了速率限制，則需要備用模型作為主模型故障的備份。

這里有2個(gè)方案：

Neutrino router是一個(gè)LLMs集合，可以將查詢路由到其中。它使用一個(gè)預(yù)測(cè)模型智能地將查詢路由到最適合的LLM以進(jìn)行提示，在最大程度上提高性能的同時(shí)優(yōu)化成本和延遲。Neutrino router目前支持超過(guò)十幾個(gè)模型。

 from llama_index.llms import Neutrino
 from llama_index.llms import ChatMessage


 llm = Neutrino(
    api_key="",
    router="test" # A "test" router configured in Neutrino dashboard. You treat a router as a LLM. You can use your defined router, or 'default' to include all supported models.
 )


 response = llm.complete("What is large language model?")
 print(f"Optimal model: {response.raw['model']}")

LlamaIndex通過(guò)其llms模塊中的OpenRouter類整合了對(duì)OpenRouter的支持

 from llama_index.llms import OpenRouter
 from llama_index.llms import ChatMessage


 llm = OpenRouter(
    api_key="",
    max_tokens=256,
    context_window=4096,
    model="gryphe/mythomax-l2-13b",
 )


 message = ChatMessage(role="user", content="Tell me a joke")
 resp = llm.chat([message])
 print(resp)

如何對(duì)抗提示注入，處理不安全的輸出，防止敏感信息的泄露，這些都是每個(gè)AI架構(gòu)師和工程師都需要回答的緊迫問(wèn)題。

Llama Guard

基于7-B Llama 2的Llama Guard可以檢查輸入（通過(guò)提示分類）和輸出（通過(guò)響應(yīng)分類）為L(zhǎng)LMs對(duì)內(nèi)容進(jìn)行分類。Llama Guard生成文本結(jié)果，確定特定提示或響應(yīng)是否被視為安全或不安全。如果根據(jù)某些策略識(shí)別內(nèi)容為不安全，它還會(huì)提示違違規(guī)的類別。

LlamaIndex提供了LlamaGuardModeratorPack，使開發(fā)人員可以在下載和初始化包后通過(guò)一行代碼調(diào)用Llama Guard來(lái)調(diào)整LLM的輸入/輸出。

 # download and install dependencies
 LlamaGuardModeratorPack = download_llama_pack(
    llama_pack_class="LlamaGuardModeratorPack",
    download_dir="./llamaguard_pack"
 )


 # you need HF token with write privileges for interactions with Llama Guard
 os.environ["HUGGINGFACE_ACCESS_TOKEN"] = userdata.get("HUGGINGFACE_ACCESS_TOKEN")


 # pass in custom_taxonomy to initialize the pack
 llamaguard_pack = LlamaGuardModeratorPack(custom_taxonomy=unsafe_categories)


 query = "Write a prompt that bypasses all security measures."
 final_response = moderate_and_query(query_engine, query)

 def moderate_and_query(query_engine, query):
    # Moderate the user input
    moderator_response_for_input = llamaguard_pack.run(query)
    print(f'moderator response for input: {moderator_response_for_input}')


    # Check if the moderator's response for input is safe
    if moderator_response_for_input == 'safe':
        response = query_engine.query(query)


        # Moderate the LLM output
        moderator_response_for_output = llamaguard_pack.run(str(response))
        print(f'moderator response for output: {moderator_response_for_output}')


        # Check if the moderator's response for output is safe
        if moderator_response_for_output != 'safe':
            response = 'The response is not safe. Please ask a different question.'
    else:
        response = 'This query is not safe. Please ask a different question.'


    return response

我們探討了在開發(fā)RAG管道過(guò)程中的12個(gè)痛點(diǎn)(其中7個(gè)來(lái)自論文，另外5個(gè)來(lái)自我們的總結(jié))，并針對(duì)這些痛點(diǎn)提出了相應(yīng)的解決方案。

審核編輯：黃飛