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

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

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

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

以下是論文總結(jié)的7個痛點：

內(nèi)容缺失

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

解決方案：

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

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

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

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

這里有2個解決方案

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

chunk_size和similarity_top_k都是用于管理RAG模型中數(shù)據(jù)檢索過程的效率和有效性的參數(shù)。調(diào)整這些參數(shù)會影響計算效率和檢索信息質(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之前對其重新排序可以顯著提高RAG的性能。

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

 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ù)庫中檢索出來的，但沒有進入生成答案的上下文中。當(dāng)從數(shù)據(jù)庫返回許多文檔時，就會發(fā)生這種情況，并且會進行整合過程來檢索答案”。

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

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

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

Basic retrieval from each index

Advanced retrieval and search

Auto-Retrieval

Knowledge Graph Retrievers

Composed/Hierarchical Retrievers

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

2、threshold嵌入

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

以下時示例代碼片段，包括創(chuàng)建微調(diào)引擎，運行微調(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()

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

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

我們看看如何解決。

1、提示壓縮

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

下面的示例代碼設(shè)置了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)

當(dāng)關(guān)鍵數(shù)據(jù)位于輸入上下文的開頭或結(jié)尾時，通常會出現(xiàn)最佳性能。LongContextReorder旨在通過重排序檢索到的節(jié)點來解決這種“中間丟失”的問題，這在需要較大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忽略，所以我們總結(jié)了4種解決方案:

1、更好的提示詞

澄清說明、簡化請求并使用關(guān)鍵字、給出例子、強調(diào)并提出后續(xù)問題。

2、輸出解析

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

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

下面是可以在LlamaIndex中使用的LangChain輸出解析模塊的示例代碼片段。有關(guān)更多詳細信息，請查看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程序作為一個通用框架，將輸入字符串轉(zhuǎn)換為結(jié)構(gòu)化Pydantic對象。

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

下面是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模式時，模型被約束為只生成解析為有效JSON對象的字符串，這樣對后續(xù)處理十分方便。

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

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

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

small-to-big retrieval
sentence window retrieval
recursive retrieval

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

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

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

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

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

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

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

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

所以就需要進行并行化處理，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)

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

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

LlamaIndex提供了兩種解決方案。

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

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

 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ù)是一個很復(fù)雜的問題，所以可以嘗試使用pdf2htmllex將PDF轉(zhuǎn)換為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）時，如果的模型出現(xiàn)問題，例如OpenAI模型受到了速率限制，則需要備用模型作為主模型故障的備份。

這里有2個方案：

Neutrino router是一個LLMs集合，可以將查詢路由到其中。它使用一個預(yù)測模型智能地將查詢路由到最適合的LLM以進行提示，在最大程度上提高性能的同時優(yōu)化成本和延遲。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架構(gòu)師和工程師都需要回答的緊迫問題。

Llama Guard

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

LlamaIndex提供了LlamaGuardModeratorPack，使開發(fā)人員可以在下載和初始化包后通過一行代碼調(diào)用Llama Guard來調(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管道過程中的12個痛點(其中7個來自論文，另外5個來自我們的總結(jié))，并針對這些痛點提出了相應(yīng)的解決方案。

審核編輯：黃飛