在过去的一年里，检索增强生成（RAG）已经成为一种基于LLM的流行架构，旨在解决在基于知识的LLM最常见的挑战之一，可怕的幻觉。
一、RAG如何解决幻觉？
RAG Pipeline包括两个关键组件：（1）检索器：选择和过滤数据（2）LLM推理：指示LLM使用过滤后的数据回答问题。这两个步骤对需要利用私人知识（如一组合同、财务分析或客户支持数据）的企业来说尤其有效。
二、证据验证
RAG工作流程中有一个关键的第三步，最近越来越受到关注，那就是LLM推理后发生的事情，特别是：对于潜在的大规模LLM推理，系统如何验证LLM响应是否与引用的特定来源相对应？最终，这是RAG系统的真正回报，但需要一个集成的管道，该管道捕获导致LLM提示的各种输入，然后集成所有LLM推理数据，以实现后处理、源验证、持续审查和审计，并创建一个持续改进的循环。
在这个博客中，我们将展示一系列强大的技术，作为RAG工作流中的第三步后处理，提供来源验证和自动来源引用。我们将使用llmware（https://www.github.com/llmware-ai/llmware.git），一个用于开发验证LLM应用程序的领先开源框架，来构建RAG工作流，该工作流提供基本的合同分析，然后与合同中的源段落相比，验证LLM响应的准确性。
LLMware在Prompt类中提供了几种现成的工具，用于简单直观的验证RAG工作流中的来源和证据，具体如下：
·evidence_check_numbers——检查一组提示响应对象，并验证llm_response中的数字是否在提供的源材料中；
·evidence_check_sources——审查llm响应和整个证据，以“确定”最有可能的文本片段、它们的文档和页码，这些文本片段构成llm响应的“源”参考书目；
·evidence_comparison_stats——提供快速的token比较，来分析响应与证据中的令牌以及已确认和未确认的令牌的总体匹配；
·classification_not_found_response——提供三个不同的函数来评估llm_response是否可能被归类为“未找到”响应，以便在工作流中正确处理（包括丢弃）；
·save_state——提示状态可以保存整个管道捕获llm事务的各种信息，可能还有一系列事务，并将其保存到一个包装良好的jsonl字典中进行离线分析，或方便地插入到文档数据存储中。该状态还可以用于快速生成微调数据集。
三、代码实现
3.1 安装llmware包
pip install llmware
3.2 使用Setup（）命令来下拉一组数百个有用的示例文档，这些文档打包在llmware公共repo中
from llmware.setup import Setupsample_files_path=Setup().load_sample_files()contracts_path = os.path.join(sample_files_path, "Agreements")
在本演示中，我们将使用“Agreements”文件夹中的一些高管雇佣协议样本，当然也可以使用客户用户数据。
一旦有了样本合同文件，我们就可以开始构建RAG工作流程了。
让我们看一下代码的每个组件，然后将所有部分放在一起。
Step1：创建Prompt对象——在llmware中，Prompt是处理端到端提示交互的主要类，RAG过程的所有步骤都可以在特定的提示中处理。提示将处理加载模型、包装和过滤源材料、应用提示说明以及后期处理生命周期。
在第一步中，我们要做的就是实例化一个提示对象，并附加我们选择的模型。
prompter = Prompt().load_model(“gpt-4”, api_key=open_api_key)
在这个演示中，我们将使用“gpt-4”，您可以直接传递api_key，也可以将其加载到os.environ变量中：
openai_api_key = os.environ.get(“OPENAI_API_KEY”,””)
（顺便说一句，我们鼓励您尝试其他模型，包括基于Huggingface的开源LLM模型，如单独的教程中所述。llmware的功能之一是可以通过简单地更改模型字符串名称并传递其api密钥来快速交换另一个模型。）
Step2：创建源材料——这是RAG工作流程中的关键一步，我们将把“add_source_document”方法指向我们的合同文件夹和特定的合同，然后这个方法将找出文档类型，通过解析文档特定的格式（例如PDF或Word文档）来提取内容，对文本进行分组，然后可以应用一个可选的过滤器，然后作为一个“上下文”进行批处理和打包，为推理做好准备，这样我们就不必再考虑它，也不必进行所有的数据操作——所有这些都是在这个强大的方法调用的幕后处理的。Llmware用一句简单的俏皮话让这一步变得轻而易举：
source = prompter.add_source_document(exec_emp_fp, contract, query=”base salary”)
在这种情况下，我们将分析所选文件夹中的合同，无论文件类型如何，然后我们将基于“base salary”主题进行进一步筛选，并将其打包为具有元数据的源，以包含在LLM的提示中。
Step3：运行推理——这是主要的处理步骤，将上一步准备的原料加载到提示中，通过查询、提示指令和温度设置来调用LLM并获得LLM响应。
responses = prompter.prompt_with_source(“What is the executive’s base salary?”, prompt_name = “just_the_facts”, temperature=0.3)
推理的输出是一个标准的响应字典，其中包括一个或多个llm响应，根据输入上下文的大小，它将自动将上下文分为多个批，并在需要时运行几个推理。
Step4：源数据检查——这是提示完成后的最后一个主要步骤，即响应字典的后期处理。如上所述，提供了几种来源和自动证据检查工具：
ev_numbers = prompter.evidence_check_numbers(responses)ev_sources = prompter.evidence_check_sources(responses)ev_stats = prompter.comparison_stats(responses)not_found_status = prompter.classify_not_found_response(responses, parse_response=True, evidence_match=True,ask_the_model=False)
一旦我们运行代码，我们将查看这些方法中每一个的输出。
综合来看，以下是我们将运行的完整代码（也可以在llmware repo中完整找到）：
from llmware.prompts import Promptfrom llmware.configs import LLMWareConfigimport osos.environ["USER_MANAGED_OPENAI_API_KEY"] = "insert-your-openai-key"
def contract_analysis_w_fact_checking (model_name):contracts_path = "/path/to/your/sample/documents/"# create prompt objectprompter = Prompt().load_model(model_name)research = {"topic": "base salary", "prompt": "What is the executive's base salary?"}for i, contract in enumerate(os.listdir(contracts_path)):print("\nAnalyzing Contract - ", str(i+1), contract)print("Question: ", research["prompt"])# contract is parsed, text-chunked, and then filtered by "base salary'source = prompter.add_source_document(contracts_path, contract, query=research["topic"])# calling the LLM with 'source' information from the contract automatically packaged into the promptresponses = prompter.prompt_with_source(research["prompt"], prompt_name="just_the_facts", temperature=0.3)# run several fact checksev_numbers = prompter.evidence_check_numbers(responses)ev_sources = prompter.evidence_check_sources(responses)ev_stats = prompter.evidence_comparison_stats(responses)z = prompter.classify_not_found_response(responses, parse_response=True, evidence_match=True,ask_the_model=False)for r, response in enumerate(responses):print("LLM Response: ", response["llm_response"])print("Numbers: ",ev_numbers[r]["fact_check"])print("Sources: ", ev_sources[r]["source_review"])print("Stats: ", ev_stats[r]["comparison_stats"])print("Not Found Check: ", z[r])# We're done with this contract, clear the source from the promptprompter.clear_source_materials()# Save jsonl report to jsonl to /prompt_history folderprint("\nupdate: prompt state saved at: ", os.path.join(LLMWareConfig.get_prompt_path(),prompter.prompt_id))prompter.save_state()
运行脚本并在控制台中，将很快看到与每个合同文档的分析相对应的一系列输出，每个文档的代表性输出类似于以下内容：
Analyzing Contract -1 Nyx EXECUTIVE EMPLOYMENT AGREEMENT.docxQuestion:What is the executive's base salary?LLM Response:$200,000.Numbers:[{'fact': '$200,000,', 'status': 'Confirmed', 'text': ' ... pay Executive a base salary at the annual rate of $200,000, payable semimonthly in accordance with Employer's normal payroll practices.... ', 'page_num': '3', 'source': 'Nyx EXECUTIVE EMPLOYMENT AGREEMENT.docx'}]Sources:[{'text': 'pay Executive a base salary at the annual rate of $200000 payable semimonthly in accordance with Employer's normal payroll practices ', 'match_score': 1.0, 'source': 'Nyx EXECUTIVE EMPLOYMENT AGREEMENT.docx', 'page_num': '4'}]Stats:{'percent_display': '100.0%', 'confirmed_words': ['200000'], 'unconfirmed_words': [], 'verified_token_match_ratio': 1.0, 'key_point_list': [{'key_point': '$200,000.', 'entry': 0, 'verified_match': 1.0}]}Not Found Check:{'parse_llm_response': False, 'evidence_match': False, 'not_found_classification': False}Numbers:[{'fact': '$200,000,', 'status': 'Confirmed', 'text': ' ... pay Executive a base salary at the annual rate of $200,000, payable semimonthly in accordance with Employer’s normal payroll practices.... ', 'page_num': '3', 'source': 'Nyx EXECUTIVE EMPLOYMENT AGREEMENT.docx'}]
让我们更详细地解释每一个事实核查。
Numbers——这将审查LLM响应，识别响应中的任何数字，然后在源材料中查找匹配的数字值，如果提供，则会提供一个包含已确认事实的词典，显示事实、状态，以及提供确认的源和页码文本片段。提供了基本的正则表达式处理（例如，删除“$”、逗号等）以及浮点值比较（例如，12.00与12相同），以增强检查的稳健性。
Sources——该方法审查上下文中提供的所有来源，并根据匹配标记的密度提供统计衍生的审查，以确定llm输出最可能的特定来源，包括来源文档和页码。
Stats–这是一个非常有用的快速检查，也是识别潜在问题响应的最可靠的简单方法之一–它显示了按token匹配的百分比（不包括停止词和基本格式项），并显示了已确认和未确认的关键token的列表。
Not Found Classification——根据经验，这是RAG处理中最重要、也是最不被理解的检查之一。在几乎任何RAG自动化中，都会出现许多情况，其中特定的段落被包含在上下文中，并且该段落不足以回答目标问题或分析。这些时候往往是错误的最高风险，因为模型试图通过结合上下文中的信息来创建答案来“提供帮助”，即使上下文并不具体适用。此外，当工作流最有用的输出是“未找到”的分类时，模型在回答这些问题时往往会冗长地解释为什么它不能提供答案，从而将特定的推理事务排除在进一步分析之外。在这种情况下，“False”表示双重否定，例如，事务“not”是“not found”事务。
Prompt State–最后，所有经过检查的llm响应对象都保存在控制台输出底部链接的提示状态历史记录中。更多信息可以查看此.jsonl文件，该文件提供了特定LLM事务的所有元数据的完整视图，这些元数据可用于多种目的：
·对总体准确性和错误/幻觉率的分析；
·不同模型的比较；
·审计和合规活动；
·持续改进以识别常见问题。
这五种机制（包括numbers, sources, stats, not-found, and prompt state）的结合为几乎所有RAG工作流提供了一个强大的工具包，可以快速识别潜在的错误和风险暴露。
参考文献：
[1] https://medium.com/@darrenoberst/using-llmware-for-rag-evidence-verification-8611abf2dbeb
[2] https://www.github.com/llmware-ai/llmware.git
[3] https://www.huggingface.co/llmware/
