開發RAG管道過程中的12個痛點

本文探討了在開發RAG管道過程中的12個痛點(其中7個來自論文，另外5個來自我們的總結)，并針對這些痛點提出了相應的解決方案。

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

這里使用“痛點”而不是“失敗點”，主要是因為我們總結的問題都有相應的建議解決方案。

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

以下是論文總結的7個痛點：

內容缺失

當實際答案不在知識庫中時，RAG系統提供一個看似合理但不正確的答案，這會導致用戶得到誤導性信息

解決方案：

在由于知識庫中缺乏信息，系統可能會提供一個看似合理但不正確的答案的情況下，更好的提示可以提供很大的幫助。比如說通過prompts聲明，如“如果你不確定答案，告訴我你不知道”，這樣可以鼓勵模型承認它的局限性，并更透明地傳達不確定性。

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

錯過了關鍵文檔

關鍵文檔可能不會出現在系統檢索組件返回的最上面的結果中。如果正確的答案被忽略，那么會導致系統無法提供準確的響應。論文中提到:“問題的答案在文檔中，但排名不夠高，無法返回給用戶?！?/p>

這里有2個解決方案

1、chunk_size和simility_top_k的超參數調優

chunk_size和similarity_top_k都是用于管理RAG模型中數據檢索過程的效率和有效性的參數。調整這些參數會影響計算效率和檢索信息質量之間的權衡。

 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

在將檢索結果發送給LLM之前對其重新排序可以顯著提高RAG的性能。

下面對比了在沒有重新排序器的情況下直接檢索前2個節點，檢索不準確；和通過檢索前10個節點并使用CohereRerank重新排序并返回前2個節點的精確檢索

 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?",
 )

整合策略的局限性導致上下文沖突

包含答案的文檔是從數據庫中檢索出來的，但沒有進入生成答案的上下文中。當從數據庫返回許多文檔時，就會發生這種情況，并且會進行整合過程來檢索答案”。

除了上節所述的Reranking并對Reranking進行微調之外，我們還可以嘗試以下的解決方案:

1、調整檢索策略

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

Basic retrieval from each index

Advanced retrieval and search

Auto-Retrieval

Knowledge Graph Retrievers

Composed/Hierarchical Retrievers

通過選擇和嘗試不同的檢索策略可以針對不同的的需求進行定制。

2、threshold嵌入

如果使用開源嵌入模型，那么調整嵌入模型也是實現更準確檢索的好方法。LlamaIndex提供了一個關于調優開源嵌入模型的分步指南，證明了調優嵌入模型可以在整個eval度量套件中一致地提高度量。

以下時示例代碼片段，包括創建微調引擎，運行微調，并獲得微調模型:

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

沒有獲取到正確的內容

系統從提供的上下文中提取正確的答案，但是在信息過載的情況下會遺漏關鍵細節，這會影響回復的質量。論文中的內容是:“當環境中有太多噪音或相互矛盾的信息時，就會發生這種情況?！?/p>

我們看看如何解決。

1、提示壓縮

LongLLMLingua研究項目/論文介紹了長上下文環境下的提示壓縮。通過將LongLLMLingua集成到LlamaIndex中，可以將其實現為一個后處理器，這樣它將在檢索步驟之后壓縮上下文，然后將其輸入LLM。

下面的示例代碼設置了LongLLMLinguaPostprocessor，它使用longllmlingua包來運行提示壓縮。

 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)

當關鍵數據位于輸入上下文的開頭或結尾時，通常會出現最佳性能。LongContextReorder旨在通過重排序檢索到的節點來解決這種“中間丟失”的問題，這在需要較大top-k的情況下很有幫助。

請參閱下面的示例代碼片段，將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?")

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

1、更好的提示詞

澄清說明、簡化請求并使用關鍵字、給出例子、強調并提出后續問題。

2、輸出解析

為任何提示/查詢提供格式說明，并人工為LLM輸出提供“解析”

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

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

 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程序作為一個通用框架，將輸入字符串轉換為結構化Pydantic對象。

可以通過Pydantic將API和輸出解析相結合，處理輸入文本并將其轉換為用戶定義的結構化對象。Pydantic程序利用LLM函數調用API，接受輸入文本并將其轉換為用戶指定的結構化對象?；蛘邔⑤斎胛谋巨D換為預定義的結構化對象。

下面是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模式使我們能夠將response_format設置為{"type": "json_object"}。當啟用JSON模式時，模型被約束為只生成解析為有效JSON對象的字符串，這樣對后續處理十分方便。

答案模糊或籠統

LLM得到的答案可能缺乏必要的細節或特異性，這種過于模糊或籠統的答案，不能有效地滿足用戶的需求。

所以就需要一些高級檢索策略來決絕這個問題，當答案沒有達到期望的粒度級別時，可以改進檢索策略。一些主要的高級檢索策略可能有助于解決這個痛點，包括：?

small-to-big retrieval
sentence window retrieval
recursive retrieval

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

這種比較問題尤其在傳統RAG方法中表現不佳。提高RAG推理能力的一個好方法是添加查詢理解層——在實際查詢向量存儲之前添加查詢轉換。下面是四種不同的查詢轉換：?

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

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

子問題：將查詢分解為幾個較小的問題，每個問題針對不同的工具。

ReAct：根據原始查詢，確定要使用哪個工具，并制定要在該工具上運行的特定查詢。

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

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

可擴展性

在RAG管道中，數據攝取可擴展性問題指的是當系統在處理大量數據時遇到的挑戰，這回導致性能瓶頸和潛在的系統故障。這種數據攝取可擴展性問題可能會產生攝取時間延長、系統超載、數據質量問題和可用性受限等問題。

所以就需要進行并行化處理，LlamaIndex提供攝并行處理功能可以使文檔處理速度提高達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)

結構化數據質量

準確解釋用戶查詢以檢索相關的結構化數據是困難的，特別是在面對復雜或模糊的查詢、不靈活的文本到SQL轉換方面

LlamaIndex提供了兩種解決方案。

ChainOfTablePack是基于創新性論文“Chain-of-table”將思維鏈的概念與表格的轉換和表示相結合。它使用一組受限制的操作逐步轉換表格，并在每個階段向LLM呈現修改后的表格。這種方法的顯著優勢在于它能夠通過系統地切片和切塊數據來處理涉及包含多個信息片段的復雜表格單元的問題。

基于論文Rethinking Tabular Data Understanding with Large Language Models），LlamaIndex開發了MixSelfConsistencyQueryEngine，該引擎通過自一致性機制（即多數投票）聚合了來自文本和符號推理的結果，并取得了最先進的性能。以下是一個示例代碼。

 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"])

復雜PDF文檔中提取數據，例如從PDF種嵌入的表格中提取數據是一個很復雜的問題，所以可以嘗試使用pdf2htmllex將PDF轉換為HTML，而不會丟失文本或格式，下面是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}"))

備用模型

在使用語言模型（LLMs）時，如果的模型出現問題，例如OpenAI模型受到了速率限制，則需要備用模型作為主模型故障的備份。

這里有2個方案：

Neutrino router是一個LLMs集合，可以將查詢路由到其中。它使用一個預測模型智能地將查詢路由到最適合的LLM以進行提示，在最大程度上提高性能的同時優化成本和延遲。Neutrino router目前支持超過十幾個模型。

 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通過其llms模塊中的OpenRouter類整合了對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)

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

Llama Guard

基于7-B Llama 2的Llama Guard可以檢查輸入（通過提示分類）和輸出（通過響應分類）為LLMs對內容進行分類。Llama Guard生成文本結果，確定特定提示或響應是否被視為安全或不安全。如果根據某些策略識別內容為不安全，它還會提示違違規的類別。

LlamaIndex提供了LlamaGuardModeratorPack，使開發人員可以在下載和初始化包后通過一行代碼調用Llama Guard來調整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

我們探討了在開發RAG管道過程中的12個痛點(其中7個來自論文，另外5個來自我們的總結)，并針對這些痛點提出了相應的解決方案。

審核編輯：黃飛