|
| 1 | +## 1 如何让大模型回答专业领域的问题 |
| 2 | +### 1.1 微调大模型 |
| 3 | +在现有大模型的基础上,使用小规模的特定任务数据进行再次训练,调整模型参数,让模型更精确地处理特定领域或任务的数据。 |
| 4 | +更新需重新训练,计算资源和时间成本高。 |
| 5 | +- 优点:一次会话只需一次模型调用,速度快,在特定任务上性能更高,准确性也更高。 |
| 6 | +- 缺点:知识更新不及时,模型训成本高、训练周期长。 |
| 7 | +- 应用场景:适合知识库稳定、对生成内容准确性和风格要求高的场景,如对上下文理解和语言生成质量要求高的文学创作、专业文档生成等。 |
| 8 | + |
| 9 | +### 1.2 RAG |
| 10 | +**R**etrieval-**A**ugmented **G**eneration 检索增强生成 |
| 11 | +将原始问题以及提示词信息发送给大语言模型之前,先通过外部知识库检索相关信息,然后将检索结果和原始问题一起发送给大模型, |
| 12 | +大模型依据外部知识库再结合自身的训练数据,组织自然语言回答问题。通过这种方式,大语言模型可以获取到特定领域的相关信息,并能够利用这些信息进行回复。 |
| 13 | +- 优点:数据存储在外部知识库,可以实时更新,不依赖对模型自身的训练,成本更低 |
| 14 | +- 缺点:需要两次查询:先查询知识库,然后再查询大模型,性能不如微调大型 |
| 15 | +- 应用场景:适用于知识库规模大月题繁更新的场景,如企业客服、实时新闻查询、法律和医疗领域的最新知识问答等, |
| 16 | + |
| 17 | +### 1.3 RAG常用方法 |
| 18 | +- **全文(关键词)搜索**,这种方法通过将问题和提示词中的关键词与知识库文档数据库进行匹配来搜索文档。根据这些关键词在每个文档中的出现频率和相关性对搜索结果进行排序。 |
| 19 | +- 向量搜索 ,也被称为“语义搜索”。文本通过**嵌入模型**被转换为**数字向量**。然后,它根据查询向量与文档向量之间的余弦相似度或其他相似性/距离度量来查找和排序文档, |
| 20 | +从而捕捉更深层次的语义含义。 |
| 21 | +- 混合搜索。结合多种搜索方法(例如,全文搜索+向量搜索)通常可以提高搜索的效果。 |
| 22 | + |
| 23 | +## 2 向量搜索 vector search |
| 24 | +### 2.1 向量 Vectors |
| 25 | +可以将向量理解为从空间中的一个点到另一个点的移动。例如,在下图中,我们可以看到一些二维空间中的向量: |
| 26 | +a是一个从 (100,50) 到 (-50,-50)的向量,b 是一个从(0,0)到 (100,-50)的向量 |
| 27 | + |
| 28 | +很多时候,我们处理的向量是从原点(0,0)开始的,比如b。这样我们可以省略向量起点部分,直接说b是向量(100,-50)。 |
| 29 | +如何将向量的概念扩展到非数值实体上呢(例如文本)? |
| 30 | + |
| 31 | +### 2.2维度 Dimensions |
| 32 | +如我们所见,每个数值向量都有x和y坐标(或者在多维系统中是x、y2,….)。x、y、.….,是这个向量空间的轴,称为维度。 |
| 33 | +对于我们想要表示为向量的一些非数值实体,我们首先需要决定这些维度,并为每个实体在每个维度上分配一个值。 |
| 34 | +例如,在一个交通工具数据集中,我们可以定义四个维度:“轮子数量”、“是否有发动机”、“是否可以在地上开动"和“最大乘客数”。 然后我们可以将一些车辆表示为: |
| 35 | + |
| 36 | + |
| 37 | +因此,我们的汽车Car向量将是(4,yes,yes,5),或者用数值表示为 (4,1,1,5) (将 yes 设为 1,no 设为 0) |
| 38 | +向量的每个维度代表数据的不同特性,维度越多对事务的描述越精确,我们可以使用“是否有翅膀”、“是否使用柴油”、“最高速度”、“平均重量”、“价格”等等更多的维度信息。 |
| 39 | + |
| 40 | +### 2.3 相似度 Similarity |
| 41 | +如果用户搜索 **“轿车Car”** 你希望能够返回所有与`"汽车automobile"`和 `“车辆vehicle"` 等信息相关的结果。向量搜索就是实现这个目标的一种方法。 |
| 42 | +**如何确定哪些是最相似的?** |
| 43 | +每个向量都有一个长度和方向。例如,在这个图中,p和a指向相同的方向,但长度不同。p和b正好指向相反的方向,但有相同的长度,然后还有c,长度比p短一点,方向不完全相同,但很接近。 |
| 44 | + |
| 45 | + |
| 46 | +那么,哪一个最接近p呢? |
| 47 | +如果“相似”仅仅意味着指向相似的方向,那么a是最接近p的。接下来是c。b是最不相似的,因为它正好指向与p相反的方向。如果“相似“仅仅意味着相似的长度,那么b是最接近p的(因为它有相同的长度),接下来是c,然后是 a。 |
| 48 | +由于向量通常用于描述语义意义,仅仅看长度通常无法满足需求。<font color = 'red'>大多数相似度测量要么仅依赖于方向,要么同时考虑方向和大小。</font> |
| 49 | + |
| 50 | +### 2.4 相似度测量 Measures of similarity |
| 51 | +相似度测量即相似度计算。四种常见的向量相似度计算方法(这里不展开讨论): |
| 52 | +- 欧几里得距离 Euclidean distance |
| 53 | +- 曼哈顿距离 Manhattan distance |
| 54 | +- 点积 Dot product |
| 55 | +- 余弦相似度 Cosine similarity |
| 56 | + |
| 57 | +## 3 RAG的过程 |
| 58 | +### 3.1 索引阶段 |
| 59 | +在索引阶段,对知识库文档进行预处理,可实现检索阶段的高效搜索。 |
| 60 | +- 以下是索引阶段的简化图: |
| 61 | +加载知识库文档 ==> 将文档中的<font color = 'red'>文本分段</font> => 利用<font color = 'red'>向量大模型</font>将分段后的<font color = 'red'>文本转换成向量</font> =>将向量<font color = 'red'>存入向量数据库</font> |
| 62 | + |
| 63 | +**<font color = 'red'>为什么要进行文本分段?</font>** |
| 64 | +大语言模型(LLM)的上下文窗口有限,所以整个知识库可能无法全部容纳其中。 |
| 65 | + - 你在提问中提供的信息越多,大语言模型处理并做出回应所需的时间就越长。 |
| 66 | + - 你在提问中提供的信息越多,所花费也就越多。 |
| 67 | + - 提问中的无关信息可能会干扰大语言模型,增加产生幻觉(生成错误信息)的几率。 |
| 68 | +我们可以通过将知识库分割成更小、更易于理解的片段来解决这些问题。 |
| 69 | + |
| 70 | +### 3.2 检索阶段 |
| 71 | +- 以下是检索阶段的简化图 |
| 72 | +通过向量模型<font color = 'red'>将用户查询转换成向量</font>==>在向量数据库中根据用户查询进行<font color = 'red'>相似度匹配</font>==>将用户查询和向量数据库中匹配到的相关内容一起交给LLM处理 |
| 73 | + |
| 74 | + |
| 75 | +## 4 文档加载器 Document Loader |
| 76 | +### 4.1、常见文档加载器 |
| 77 | +- `来自 langchain4j 模块的文件系统文档加载器(FileSystemDocumentLoader)` |
| 78 | +- 来自 langchain4j 模块的类路径文档加载器(classPathDocumentLoader) |
| 79 | +- 来自 langchain4j 模块的网址文档加载器(UrlDocumentLoader) |
| 80 | +- 来自 langchain4j-document-loader-amazon-s3 模块的亚马逊 $3 文档加载器(Amazns3DocumentLoader) |
| 81 | +- 来自 langchain4j-document-loader-azure-storage-blob 模块的 Azure Blob 存储文档加载器(AzureBlobStorageDocumentLoader) |
| 82 | +- 来自 langchain4j-document-loader-github 模块的 GitHub 文档加载器(GitHubDocumentLoader) |
| 83 | +- 来自 langchain4j-document-loader-google-cloud-storage 模块的谷歌云存储文档加载器(GoogleCloudStorageDocumentLoader) |
| 84 | +- 来自 langchain4i-document-loader-selenium 模块的 Selenium 文档加载器(SeleniumDocumentLoader) |
| 85 | +- 来自 langchain4i-document-loader-tencent-cos 模块的腾讯云对象存储文档加载器(TencentCosDocumentLoader) |
| 86 | + |
| 87 | +### 4.2、测试文档加载 |
| 88 | +``` java |
| 89 | +@Test |
| 90 | + public void testReadDocument() { |
| 91 | + // 加载单个文件 |
| 92 | + Document document = FileSystemDocumentLoader.loadDocument("D:\\file\\测试.txt"); |
| 93 | + System.out.println(document.text()); |
| 94 | + |
| 95 | + // 从一个目录中加载所有文档 |
| 96 | + List<Document> documents = FileSystemDocumentLoader.loadDocuments("D:\\file"); |
| 97 | + for (Document document1 : documents) { |
| 98 | + System.out.println("====================="); |
| 99 | + System.out.println(document1.metadata()); |
| 100 | + System.out.println(document1.text()); |
| 101 | + } |
| 102 | + |
| 103 | + // 从一个目录中加载所有的.txt文档 |
| 104 | + PathMatcher pathMatcher = FileSystems.getDefault().getPathMatcher("glob:*.txt"); |
| 105 | + List<Document> documents1 = FileSystemDocumentLoader.loadDocuments("D:\\file", pathMatcher, new TextDocumentParser()); |
| 106 | + |
| 107 | + // 从一个目录及子目录中加载所有文档 |
| 108 | + List<Document> documents2 = FileSystemDocumentLoader.loadDocumentsRecursively("D:\\file", new TextDocumentParser()); |
| 109 | + } |
| 110 | +``` |
| 111 | +## 5 文档解析器 Document Parser |
| 112 | +### 5.1 常见文档解析器 |
| 113 | +文档可以是各种格式的文件,比如 PDF、DOC、TXT等等。为了解析这些不同格式的文件,有一个“文档解析器”(Documentparser)接口,并且我们的库中包含了该接口的几种实现方式: |
| 114 | +- `来自 langchain4j模块的文本文档解析器(TextDocumentParser),它能够解析纯文本格式的文件(例如 TXT、HTML、MD 等)。` |
| 115 | +- 来自langchain4j- document parser-apache-pdfbx 模块的 Apache PDFBox 文档解析器(ApachePdfBoxDocumentParser),它可以解析 PDF 文件 |
| 116 | +- 来自 langchain4j-document parserapache-poi模块的 Apache POI 文档解析器(ApachePoiDocumentParser),它能够解析微软办公软件的文件格式(例如 DOC、DOCX、PPT、PPTX、XLS、XLSX等)。 |
| 117 | +- 来自 langchain4j-document-parser-apache-tika 模块的 Apache Tika 文档解析器(ApacheTikaDocumentParser),它可以自动检测并解析几乎所有现有的文件格式。 |
| 118 | + |
| 119 | +假设如果我们想解析PDF文档,那么原有的 `TextDocumentParser` 就无法工作了,我们需要引入 `langchain4i-document-parser-apache-pdfbox` |
| 120 | + |
| 121 | +### 5.2 添加依赖 |
| 122 | +```xml |
| 123 | +<!--解析pdf文档--> |
| 124 | +<dependency> |
| 125 | + <groupId>dev.langchain4j</qroupId> |
| 126 | + <artifactId>langchain4j-document-parser-apache-pdfbox</artifactId> |
| 127 | +</dependency> |
| 128 | +``` |
0 commit comments