大模型学习

大模型 QA 功能实现

文档问答模式

传统的 prompt+context 模式

• 两阶段方法：将问答过程分为两个阶段。第一个阶段称为召回阶段，系统会根据用户的提问从文本库或知识库中检索相关的文本片段或知识点，利用传统的检索技术去召回可能的文档候选。第二个阶段称之为阅读理解阶段，会利用深度学习的机器阅读理解模型，从对应的候选文档里将答案抽取出来。
• 端到端方法：依旧是分为召回和阅读理解两个阶段，区别在于，它使用了向量检索的方式来替代传统的检索技术用于召回。优点是准确率非常高，缺点在于严重依赖于问答库。因此，这条路径非常适合处理高频出现的重复性问题。
• 无召回的方法：这类方法的代表是 GPT 模型，它通过训练大规模的语言模型来记忆知识，不需要外部的存储机制来存储索引，为了回答一般疑问句和解决拒绝回答的问题。基本流程大同小异：
  • 加载文件 -> 读取文本 -> 文本分割 -> 文本向量化 -> 问句向量化 -> 在文本向量中匹配出与问句向量最相似的 top k 个 -> 匹配出的文本作为上下文和问题一起添加到 prompt 中 -> 提交给 LLM 生成回答。
    

学习到的方法

• 基于向量数据库与 GPT3.5 的通用本地知识库方案
  • 基本流程 + 优化：
    • 问答拆分查询，直接将问题和答案做匹配准确率可能不高，如果在已经有大量的问答映射数据的情况下，问题直接搜索已经积累的问题集。
    • 抽取主题词生成向量数据，答案中有大量非答案的内容，可以通过抽取答案主题然后组合生成向量数据，也可以在一定程度上提升相似度，主题算法有 LDA、LSA 等。
    • 自训练的 Embedding 模型，openAI 的 Embedding 模型在太过于专业的问题上有可能出现查询数据不准确的情况。可以自己训练有针对性的模型 ，如 text2vec。
• 利用 ChatGPT 和 Milvus
  • 特点：使用语义相似度匹配；使用 OpenAI 的 embedding 模型将这些文档问题转化为特征向量，Milvus 将给这些特征向量分配一个向量 ID，感觉就相当于一个索引，可以反向获取获得原始文本。
  • 流程：当用户提出一个问题时，通过 OpenAI 的 embedding 模型将之转化为特征向量，在 Milvus 中对特征向量做相似度检索，得到与该问题最相似的标准问题的 id, 拿到这个数字向量后，再去自己的数据库进行检索，那么就可以得到一个结果集，这个结果集会根据匹配的相似度有个打分，分越高说明越匹配， 这样就可以按照匹配度倒序返回一个相关结果。
  • 缺点：
    • openai api 存在最大长度的限制，例如 chatgpt 的最大 token 数为 4096，此时直接对文档截断，存在上下文丢失的问题。
    • api 的调用费用和 token 长度成正比，tokens 数太大，则每次调用的成本都会很高。
• llama-index(gpt-index)对话式文档问答
  • 特点：针对文档问答设计“先检索再整合“。
  • 逻辑：将文档整理成纯文本格式并切分成小块，每个块都转成向量并存入向量数据库，首先准备好文档，并整理为纯文本的格式。把每个文档切成若干个小的 chunks，将问题同样转为向量，并检索向量数据库，得到相关性最高的一个或几个 chunk，将问题和 chunk 合并重写为一个新的请求发给 openai api，接下来就常规操作。
  • llama-index(gpt-index)：后 chatgpt 时代的对话式文档问答解决方案 - 知乎 (zhihu.com)
• Document_QA
  • 特点：使用 text-embedding-ada-002 接口生成特征向量，最近邻搜索返回最相似的文本列表。就是先把大量文本中提取相关内容，再进行回答，最终可以达到类似突破 token 限制的效果。
• chatweb
  • 特点：就是爬取网页提取正文，按照段落切分并生成向量。其他没啥特点，使用的是 gpt3.5 的 embeddingAPI 生成向量，gpt3.5 的 chatAPI 设计 prompt。
• chatpdf-minimal-demo
  • 特点：文章切片到段落，将文章拆分为几部分；把问题的 embedding 比较所有段落 embedding 得到近似程度并排序，把和提问（语义）最接近的一个或几个段落作为上下文，通过 OpenAI 的对话接口得到最终的答案。
  • GitHub - postor/chatpdf-minimal-demo
• llama_index 建立个人知识库的 GPT 问答
  • 【GPT】llama_index（一）快速建立个人知识库的GPT问答 - 知乎 (zhihu.com)
  • 使用各种向量数据库和 langchain，将它们组合起来使用。替代 llama_index。比如使用 chatgpt-retrieval-plugin 的向量搜索，使用 langchain 完成"prompt engineering"。
• ChatGLM-6B+langchain
  • 本项目中 Embedding 选用的是 text2vec-large-chinese，LLM 选用的是 ChatGLM-6B。其他类似。
• 阿里云 AnalyticDB(ADB) + LLM
  • 和上面类似。
• chatglm-qabot-v2: 从 q-d 匹配到 q-q 匹配
  • 特点：通过 document 生成一批候选的 question，当用户发来请求的时候，首先是把 query 和候选的 question 做匹配，进而找到相关的 document 片段，看作者的实例效果是有提升的。
• 基于 LangChain+CHATGPT 构建增强 QA
  • 基于 LangChain+LLM 构建增强 QA-阿里云开发者社区 (aliyun.com)
  • 特点：LLM 选择了商业化的 OpenAI，LangChain 提供了基于 LLM 的 SQLDatabaseChain，可以利用 LLM 的能力将自然语言的 query 转化为 SQL，连接 DB 进行查询，并利用 LLM 来组装润色结果，返回最终 answer。

除此之外 其他方向

• Text-to-SQL：把数据库领域下的自然语言问题，转化为在关系型数据库中可以执行的结构化查询语言。
• 多模态模型：结合多种模态（如文本、图像、视频）进行学习和生成。
• 模型压缩与加速：为了在资源有限的设备上运行大模型，需要研究模型压缩和加速技术。
• 分布式和并行计：由于大模型需要大量的计算资源和存储空间，因此分布式和并行计算方法变得尤为重要。
  

finetuning 模式

微调成本较大，还没具体看，先看 RAG， 这个待学习…

• 微调现存问题：
  • 首先，由于生成模型依赖于内在知识（权重），因此模型还是无法摆脱幻觉的产生，在对理解门槛高且准确性要求严格的场景下，这就是完全无法接受的，因为用户很难从回答的表面看出模型是否是在胡说八道。
  • 其次，在真实场景中，每时每刻都在产生大量数据，对一个事物的概念会迭代的飞快，如某个政策的解读、某个指标的调整等。而模型微调并不是一个简单的工作，无论是从数据准备、算力资源、微调效果、训练时间等各个角度来看，随时用新产生的数据来进行微调都是不现实的，且最终微调的效果也无法保证，能够做到每月更新一次都已经是很理想的状态。

RAG 架构

RAG 是一种在大模型中用于捕获长距离依赖关系的技术，它具有更强的表示能力，但可能需要更高的计算资源和训练成本。和 prompt+context 模式一样，两者都使用预先定义的提示（prompt）和上下文（context）作为输入。虽说是新模型架构，但感觉就是 prompt+context 模式的升级版。

• 优点：
  • RAG:
    • 能够捕获长距离依赖关系，这有助于提高模型的性能。
    • 允许模型在不同位置的 token 之间建立依赖关系，具有更强的表示能力。
  • Prompt+Context 模式:
    • 简单易懂，易于实现。可以用于各种 NLP 任务，例如文本摘要、问答等。
• 缺点：
  • RAG:
    • 计算复杂度较高，需要更多的计算资源和存储空间。
    • 可能引入额外的训练时间和成本。
  • Prompt+Context 模式:
    • 性能可能受到预先定义的提示和上下文的影响。
    • 无法捕获长距离依赖关系，可能导致模型的性能受限。
      

RAG 流程梳理

结合博主分享 RAG 阅读笔记

• 读懂 RAG 这一篇就够了，万字详述 RAG 的 5 步流程和 12 个优化策略_rag csdn-CSDN 博客
• 同济大学发布最新检索增强(RAG)的 LLM 生成技术综述-腾讯云开发者社区-腾讯云 (tencent.com)
• RAG 修炼手册｜一文讲透 RAG 背后的技术-腾讯云开发者社区-腾讯云 (tencent.com)
• 喂饭！RAG for LLM: A Survey 论文导读 - 知乎 (zhihu.com)
• 一文通透 Text Embedding 模型：从 text2vec、openai-text embedding 到 m3e、bge_text-embedding-ada-002-CSDN 博客
• 基于检索增强的文本生成调研 | 知识分享 (hustai.github.io)

改善模型生成效果的方法

RAG 的目的是为了改善大模型的生成效果，其他常见方法有：

• 提示工程，通过例如 few-shot prompt 的手段增强输出。
• RAG，检索增强。
• 微调，对模型进行微调。
• 综合手段，综合利用微调、提示工程和 RAG。

RAG 的本质：让模型获取正确的 Context(上下文)，利用 ICL (In Context Learning)的能力，输出正确的响应。综合利用固化在模型权重中的参数化知识和存在外部存储中的非参数化知识(知识库、数据库等)。

预备知识文档

• 需要使用专门的文档加载器（例如 PDF 提取器）或多模态模型（如 OCR 技术）处理成纯文本。
• 在这一过程优化改进的地方有：
  • 数据清洗：
    • 规范文本格式，去除特殊字符和不相关信息。除重复文档或冗余信息。
    • 实体解析：消除实体和术语的歧义以实现一致的引用。例如，将“LLM”、“大语言模型”和“大模型”标准化为通用术语。
    • 文档划分：合理地划分不同主题的文档，不同主题是集中在一处还是分散在多处？如果作为人类都不能轻松地判断出需要查阅哪个文档才能来回答常见的提问，那么检索系统也无法做到。
    • 数据增强：使用同义词、释义甚至其他语言的翻译来增加语料库的多样性。
    • 用户反馈循环：基于现实世界用户的反馈不断更新数据库，标记它们的真实性。
    • 时间敏感数据：对于经常更新的主题，实施一种机制来使过时的文档失效或更新。
  • 分块处理：
    • 保持语义上的连贯性的同时，尽可能减少嵌入内容中的噪声。
    • 固定大小的分块：简单直接高校；
    • 根据文档的具体内容进行分块，例如根据标点符号（如句号）分割。或者直接使用更高级的 NLTK 或者 spaCy 库提供的句子分割功能。
    • 递归分块：通过重复地应用分块规则来递归地分解文本，缺点：需要制定精细的规则来决定何时和如何分割文本。
    • 同一文档进行从大到小所有尺寸的分割，然后把不同大小的分块全部存进向量数据库，并保存每个分块的上下级关系，进行递归搜索。
  • 分块大小的选择：需要不断实验调整该参数，在一些测试中，128 大小的分块往往是最佳选择。

嵌入模型

• OpenAI 目前主打的新文本嵌入模型：text-embedding-3-small 和 text-embedding-3-large。
• Chinese Word Embeddings：text2vec-large-chinese，一个大型语言模型，并且特别针对 Chinese 语言进行了优化，所以它在许多 Chinese NLP 任务中可能具有很好的性能。
• bce-embedding：将 Chinese 单词转化为固定维度的向量表示的方法，这种表示可以捕捉单词的语义和语法信息，可以用于许多自然语言处理任务。
• BERT：这是一个基于 Transformer 的模型，引入自注意力机制的模型，在许多 Chinese NLP 任务中都有很好的表现。
• Tangshu：这是一个基于 Word2Vec 的模型，特别针对 Chinese 语言进行了优化。

向量数据库

向量数据库是专门设计用于存储和检索向量数据的数据库系统。在 RAG 系统中，通过嵌入模型生成的所有向量都会被存储在这样的数据库中。这种数据库优化了处理和存储大规模向量数据的效率，使得在面对海量知识向量时，我们能够迅速检索出与用户查询最相关的信息。
在这一过程优化改进的地方有：

• 元数据加索引（感觉就是加键）：将向量与元数据（即非向量化的数据）一同存储，为向量添加元数据标注是一种提高检索效率的有效策略，如日期、章节或小节的引用，文本的关键信息、小节标题或关键词等作为元数据，效果显著。
• 多重索引：元数据无法充分区分不同上下文类型的情况下，我们可以考虑进一步尝试多重索引技术。多重索引技术的核心思想是将庞大的数据和信息需求按类别划分，并在不同层级中组织，以实现更有效的管理和检索。这意味着系统不仅依赖于单一索引，而是建立了多个针对不同数据类型和查询需求的索引。为了引入多重索引技术，我们还需配套加入多级路由机制，多级路由机制确保每个查询被高效引导至最合适的索引。查询根据其特点（如复杂性、所需信息类型等）被路由至一个或多个特定索引。

查询检索

经过上述几个步骤的准备后，就可以开始进行处理用户查询。首先，用户的问题会被输入到嵌入模型中进行向量化处理。然后，系统会在向量数据库中搜索与该问题向量语义上相似的知识文本或历史对话记录并返回。
在这一过程优化改进的地方有：

• 暴力求解的 KNN 和近似求解的 ANN 算法：

  • 基于树：KDTree、Annoy；在 ANN 领域，最常见的两个问题是：如果我们想要 Top K 的点，但是该区域的点集数量不足 K，该怎么办？如果真实的 Top K 中部分点不在这个区域，该怎么办？作者用了两个技巧来解决这个问题：
    • 使用优先队列（priority queue）：将多棵树放入优先队列，逐一处理；并且通过阈值设定的方式，如果查询的点与二叉树中某个节点比较相似，那么就同时走两个分支，而不是只走一个分支；
    • 使用森林（forest of trees）：构建多棵树，采用多个树同时搜索的方式，得到候选集 Top M（M > K），然后对这 M 个候选集计算其相似度或者距离，最终进行排序就可以得到近似 Top K 的结果。
  • 基于哈希：LSH；位置敏感哈希算法：空间上距离较近的向量更有可能被分入同一个桶。这样在进行搜索时，只需获取目标向量的哈希值，找到相应的桶，并在该桶内进行搜索即可。上面两种牺牲搜索质量来提高搜索速度的方法，但除了搜索速度外，内存开销也是一个巨大挑战。
  • 基于量化：PQ；在聚类的方法之上改进一下，用每个簇的中心点来代替簇中的数据点。虽然这样我们会丢失向量的具体值信息，但考虑到聚类中心点和簇中向量相关程度，再加上可以不断增加簇的数量来减少信息损失，所以很大程度上我们可以保留原始点的信息。把向量用其所在的簇中心点表示的过程就是量化。
  • 基于图：NSW，HNSW；导航小世界（NSW）算法思路和“六度分割理论”类似。
  • 

• 对问题进行重写，以提升召回效果：

  • 结合历史对话的重新表述：在向量空间中，对人类来说看似相同的两个问题其向量大小并不一定很相似。我们可以直接利用 LLM 重新表述问题来进行尝试。此外，在进行多轮对话时，用户的提问中的某个词可能会指代上文中的部分信息，因此可以将历史信息和用户提问一并交给 LLM 重新表述。
  • 假设文档嵌入（HyDE）：HyDE 的核心思想是接收用户提问后，先让 LLM 在没有外部知识的情况下生成一个假设性的回复。然后，将这个假设性回复和原始查询一起用于向量检索。假设回复可能包含虚假信息，但蕴含着 LLM 认为相关的信息和文档模式，有助于在知识库中寻找类似的文档。
  • 退后提示（Step Back Prompting）：如果果原始查询太复杂或返回的信息太广泛，我们可以选择生成一个抽象层次更高的“退后”问题，与原始问题一起用于检索，以增加返回结果的数量。例如，原问题是“桌子君在特定时期去了哪所学校”，而退后问题可能是关于他的“教育历史”。这种更高层次的问题可能更容易找到答案。
  • 多查询检索/多路- 召回（Multi Query Retrieval）：使用 LLM 生成多个搜索查询，特别适用于一个问题可能需要依赖多个子问题的情况。

• 根据向量数据库的特定设置来优化一些检索参数：

  • 稀疏和稠密搜索权重： 稠密搜索即通过向量进行搜索稀疏搜索算法是最佳匹配 25（BM25），它基于统计输入短语中的单词频率，频繁出现的单词得分较低，而稀有的词被视为关键词，得分会较高。可以结合稀疏和稠密搜索得出最终结果。
  • 结果数量（topK）： 不能多也不能太少。
  • 相似度度量方法：欧式距离和 Jaccard 距离、余弦相似度。

• 高级检索策略：

  • 上下文压缩：我们提到过当文档文块过大时，可能包含太多不相关的信息，传递这样的整个文档可能导致更昂贵的 LLM 调用和更差的响应。上下文压缩的思想就是通过 LLM 的帮助根据上下文对单个文档内容进行压缩，或者对返回结果进行一定程度的过滤仅返回相关信息。
  • 句子窗口搜索：相反，文档文块太小会导致上下文的缺失。其中一种解决方案就是窗口搜索，该方法的核心思想是当提问匹配好分块后，将该分块周围的块作为上下文一并交给 LLM 进行输出，来增加 LLM 对文档上下文的理解。
  • 父文档搜索：无独有偶，父文档搜索也是一种很相似的解决方案，父文档搜索先将文档分为尺寸更大的主文档，再把主文档分割为更短的子文档两个层级，用户问题会与子文档匹配，然后将该子文档所属的主文档和用户提问发送给 LLM。
  • 自动合并：自动合并是在父文档搜索上更进一步的复杂解决方案。同样地，我们先对文档进行结构切割，比如将文档按三层树状结构进行切割，顶层节点的块大小为 1024，中间层的块大小为 512，底层的叶子节点的块大小为 128。而在检索时只拿叶子节点和问题进行匹配，当某个父节点下的多数叶子节点都与问题匹配上则将该父节点作为结果返回。
  • 多向量检索：多向量检索同样会给一个知识文档转化成多个向量存入数据库，不同的是，这些向量不仅包括文档在不同大小下的分块，还可以包括该文档的摘要，用户可能提出的问题等等有助于检索的信息。在使用多向量查询的情况下，每个向量可能代表了文档的不同方面，使得系统能够更全面地考虑文档内容，并在回答复杂或多方面的查询时提供更精确的结果。例如，如果查询与文档的某个具体部分或摘要更相关，那么相应的向量就可以帮助提高这部分内容的检索排名。
  • 多代理检索：多代理检索，简而言之就是选取优化策略中的部分交给一个智能代理合并使用。就比如使用子问题查询，多级索引和多向量查询结合，先让子问题查询代理把用户提问拆解为多个小问题，再让文档代理对每个字问题进行多向量或多索引检索，最后排名代理将所有检索的文档总结再交给 LLM。这样做的好处是可以取长补短，比如，子问题查询引擎在探索每个子查询时可能会缺乏深度，尤其是在相互关联或关系数据中。相反，文档代理递归检索在深入研究特定文档和检索详细答案方面表现出色，以此来综合多种方法解决问题。需要注意的是现在网络上存在不同结构的多代理检索，具体在多代理选取哪些优化步骤尚未有确切定论，我们可以结合使用场景进行探索。
  • Self - RAG：自反思搜索增强是一个全新 RAG 框架，其与传统 RAG 最大的区别在于通过检索评分（令牌）和反思评分（令牌）来提高质量。它主要分为三个步骤：检索、生成和批评。Self - RAG 首先用检索评分来评估用户提问是否需要检索，如果需要检索，LLM 将调用外部检索模块查找相关文档。接着，LLM 分别为每个检索到的知识块生成答案，然后为每个答案生成反思评分来评估检索到的文档是否相关，最后将评分高的事件相关内容对问题解答的有效性。

重排模型

重排模型通过对初始检索结果进行更深入的相关性评估和排序，确保最终展示给用户的结果更加符合其查询意图

生成回答

将用户提问和上一步中检索到的信息结合，构建出一个提示模版，输入到大语言模型中，得到模型输出答案。

优化：
& Prompt Engineering（提示工程）
设计提示词或问题的方式将直接影响模型预测下一个词的概率，使用少量样本（few-shot）的方法，将想要的问答例子加入提示词中，指导LLM如何利用检索到的知识，也是提升LLM生成内容质量的有效方法。这种方法不仅使模型的回答更加精准，也提高了其在特定情境下的实用性。

&大语言模型
LlamaIndex或LangChain框架，设计的核心理念在于简化大型语言模型（LLMs）与外部世界的交互过程。为各种LLMs提供了通用的接口，开发者能够灵活地集成不同的模型到各种应用中。

检索增强生成（RAG）相关文献笔记

• 《Retrieval-Augmented Generation for Large Language Models: A Survey》

  • 一篇综述。喂饭！RAG for LLM: A Survey 论文导读 - 知乎 (zhihu.com)
  • RAG 相较于 Fine - Tuning(微调)优缺点：
    

• 《AGuide on12 Tuning Strategies for Production-Ready RAG Applications》

  • 如何通过调整“超参数(hyperparameters)”和采用不同的调优策略来提高检索增强生成管道的性能。
  • 作者给出以下 RAG 优化的方向：
    • 数据清理(Data Cleaning)：这个阶段需要确保数据质量，包括基本的自然语言处理清理技术，确保信息一致性和事实准确性。
    • 分块(Chunking)：将文档分割成逻辑上连贯的信息片段，这可能涉及将长文档分割成较小部分或将较小片段组合成连贯段落。
    • 向量模型(Embedding Models)：向量模型是检索的核心，向量的质量极大影响检索结果。可以考虑使用不同的向量模型，有条件的话可以对特定用例进行微调。
    • 元数据(Metadata)：在向量数据库中存储向量时，可以添加元数据，以便于后续的搜索结果后处理。
    • 多索引（Multi - indexing）：如果元数据不足以提供额外信息以逻辑上分隔不同类型的上下文，可以尝试使用多个索引。
    • 索引算法（Indexing Algorithms）：选择和调整近似最近邻（ANN）搜索算法，比如 Facebook 的 Faiss、Spotify 的 Annoy、Google 的 ScaNN 和 HNSWLIB。
    • 推理阶段——检索和生成（Inferencing Stage——Retrieval & Generation）：推理阶段涉及检索和生成过程，主要关注如何改进检索结果的相关性和生成响应的质量。
      • 查询转换(Query Transformations)：如果搜索查询未产生满意的结果，可以尝试不同的查询转换技术，如重新措辞(Rephrasing)、假设文档嵌入(HyDE) 或 子查询(Sub - queries)。
      • 检索参数(Retrieval Parameters)：考虑是否需要语义搜索或混合搜索，并调整聚合稀疏和密集检索方法的权重。
      • 高级检索策略(Advanced Retrieval Strategies)：探索高级检索策略，如句子窗口检索或自动合并检索。
      • 重新排序模型(Re - ranking Models)：使用重新排序模型来消除不相关的搜索结果。
      • 大语言模型(LLMs): LLM 是生成响应的核心组件。可以根据需求选择不同的 LLM，并考虑针对特定用例进行微调。
      • 提示词工程(Prompt Engineering): 提示词的使用将显著影响 LLM 的完成情况。

• 《Improving Retrieval Performance in RAG Pipelines with Hybrid Search》

  • 讨论了如何通过结合传统的基于关键词的搜索和当下流行的向量搜索来找到更相关的搜索结果，以提高 RAG 管道的性能。作者提出混合搜索(Hybrid Search)策略。
  • 混合得分（Hybrid Score） = (1 - alpha) * 稀疏得分（Sparse Score） + alpha * 密集得分（Dense Score）
  • 通常，alpha 取值在 0 到 1 之间，其中：
    • alpha = 1：纯向量搜索(Pure Vector Search)
    • alpha = 0：纯关键词搜索(Pure Keyword Search)
  • 混合搜索通过结合两种搜索技术的优势，特别是在文本搜索用例中，可以显著提高搜索结果的相关性。

• 《SELF - RAG: Learning To Retrieve, Generate, and Critique Through Self - Reflection》

  • 源自：《SELF - RAG：通过自我反思学习检索、生成和自我批评》精华摘译 - 知乎 (zhihu.com)
  • 提出了一种称为自我反思检索增强生成（Self - RAG）的框架，其通过检索和自我反思来提高 LM 的质量和真实性。
  • Self - RAG 的实现主要分为三个步骤：按需检索、并行生成以及评价与选择。
    • 按需检索：首先，Self - RAG 依据检索令牌（retrieval token）以评估是否需要检索，并控制检索组件。如果需要检索，LM 将调用外部检索模块查找相关文档。
    • 并行生成：如果不需要检索，模型会预测下一个输出段，就像在标准 LM 中一样。如果需要检索，模型首先生成一个评论令牌[IsREL]来评估检索到的文档与问题是否相关，然后利用与问题相关的段落来生成后续内容。
    • 评价与选择：对于通过检索段落生成的内容，模型将生成另一个评论令牌[IsSUP]，用于评估生成内容收到检索段落的支持度。随后，综合所有评论令牌，选择优秀的生成内容作为本次片段的输出并继续处理下一片段。在所有片段生成完毕后，生成评论令牌[IsUSE]，用于评估整体内容对问题解答的有效性。
  • 但是可能有局限：
    

• 《Advanced RAG Techniques: an Illustrated Overview》

  • 内容差不多也是这些。

• 《RAPTOR: Recursive Abstractive ProcessingforTree - Organized Retrieval》

  • 《RAPTOR: Recursive Abstractive Processing for Tree - Organized Retrieval》精华摘译 - 知乎 (zhihu.com)
  • 检索增强型语言模型(Retrieval - augmented language models)能够适应世界的变化并包含更广泛的知识。但是，现有方法通常只能检索文档中的短文本段落，这限制了对文档整体上下文的深入理解。为了克服这个问题，本文提出了 RAPTOR 模型，它采用一种创新方法，通过递归地向量化、聚类和摘要文本，自下而上构建出一个包含不同级别摘要的树状结构。在使用时，RAPTOR 能够从这棵树中检索信息，有效整合长篇文档中的信息，覆盖不同的抽象层次。通过实验发现这种递归摘要的检索方式在多个任务上都优于传统的检索增强方法。特别是在需要复杂推理的问答任务上，结合 RAPTOR 和 GPT - 4 的使用将 QuALITY 基准测试的性能提高了 20%。

• 《ARAGOG: Advanced RAG Output Grading》

  • RAG 对于把外部知识融入大型语言模型 LLM 的输出中非常关键。虽然围绕 RAG 的研究文献逐渐增多，主要集中于系统地回顾和比较新的最先端（SoTA）技术及其前身，但在进行广泛的实验比较方面还存在不足。本项研究旨在通过评估不同 RAG 方法对检索精度和答案相似度的影响来填补这一空白。
  • 研究结果表明：
    • 假设性文档嵌入（Hypothetical Document Embedding，HyDE）和 LLM 的重排序能够显著提高检索精度。然而，最大边际相关性（Maximal Marginal Relevance，MMR）和 Cohere 的重排序并没有显示出相对于简单 RAG 系统的显著优势，多查询方法的效果也不尽如人意。句子窗口检索被证明是提高检索精度最有效的方法，尽管其在答案相似度方面的表现不够稳定。该研究还验证了文档摘要索引作为一个有效检索方式的可能性。

向量数据库

• milvus
  • 为 AI 而生的数据库：Milvus 详解及实战 (xjx100.cn)
  • 云原生向量数据库 Milvus 扫盲，看完这篇就够了 - 知乎 (zhihu.com)
  • $ pip3 install pymilvus
  • $ pip3 install pymilvus[model] # for milvus - model
  • 专为向量查询与检索设计。Milvus 在底层设计上就是为了处理由各种非结构化数据转换而来的 Embedding 向量而生。Milvus 支持在向量相似度检索过程中进行标量字段过滤，实现混合查询。
  • Milvus 使用 CPU 类型索引进行查询时会把所有 CPU 资源都占用掉,查询时需要确保服务器上没有运行其他高负载应用。

本地部署框架

通过对比，使用 ollama 部署是最简单的方法。安装方式比较多，本地部署比较方便。

探索学习阶段

本地模型下载

直接在 linus 中下载 ollama

• 下载遇到的问题：
  
  

  • 下载模型需要魔法上网，还是失败, 找了很久没找到原因，防火墙，ping 网站，换梯子都试了。于是使用 docker 装。

使用开源的应用容器引擎 docker

• 用的镜像下载也很慢：
  

安装dockers 和 ollama

sudo apt install docker-ce

sudo docker run -d -v /opt/ai/ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama

试运行

这表明Ollama服务已经在端口11434上开始监听请求，版本是0.1.32。

尝试下载模型qwen:0.5b

启动容器

sudo docker run -d -p 11434:11434 ollama/ollama
 docker run -d --restart=always -v /home/docker/ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama

sudo docker exec -it  loving_gagarin ollama run qwen:0.5b

报错，同上，原因未知

在使用vpn情况下，不管是本地windows下载ollama还是通过docker下载ollama, 在下载模型时候都会出现问题

最终方案 ： 解决无法从ollama下载模型问题 手动下载模型

1 windows 下载ollama
2访问huggingface下载模型

先测试qwen0.5b
访问huggingface下载qwen1_5-0_5b-chat-q5_k_m.gguf模型

创建一个名为 Modelfile 的文件，并使用 FROM 指令
参考官方提供的qwen14B模型的Modelfile的提示词和参数

FROM ./qwen1_5-0_5b-chat-q5_k_m.gguf

TEMPLATE """{{ if .System }}<|im_start|>system
{{ .System }}<|im_end|>{{ end }}<|im_start|>user
{{ .Prompt }}<|im_end|>
<|im_start|>assistant
"""

PARAMETER stop "<|im_start|>"
PARAMETER stop "<|im_end|>"

4、创建模型

ollama create qwen:0.5b -f Modelfile

5、运行模型

ollama run qwen:0.5b

6、0.5b模型速度超快，但是回答太飘了 又下了一个7B

ollama run qwen:7b

二、AnythingLLM 的使用
anythingllm特点

多用户支持和权限管理：允许多个用户同时使用，并可设置不同的权限。
支持多种文档类型：包括 PDF、TXT、DOCX 等。
简易的文档管理界面：通过用户界面管理向量数据库中的文档。
两种聊天模式：对话模式保留之前的问题和回答，查询模式则是简单的针对文档的问答
聊天中的引用标注：链接到原始文档源和文本。
简单的技术栈，便于快速迭代。
100% 云部署就绪。
“自带LLM”模式：可以选择使用商业或开源的 LLM。
高效的成本节约措施：对于大型文档，只需嵌入一次，比其他文档聊天机器人解决方案节省 90% 的成本。
完整的开发者 API：支持自定义集成。

可以直接在界面点点点就可以配置

尝试了qwen7B

导入了一篇本地文档，构建本地知识库

可以结合本地知识文件询问相关问题

三、本地部署了Qwen模型后，使用Jupyter环境进行应用开发
方法1搭建LangChain框架

使用方法

方法二 下载 ollama-python

2025.1.15更新