从零开始搭建当地安全 AI 大模型攻防知识库

本文将体系分享从零开始搭建当地大模型问答知识库过程中所遇到的问题及其办理方案。
1 概述
目前，搭建大语言问答知识库能接纳的方法主要包括微调模型、再次训练模型以及增强检索天生（RAG，Retrieval Augmented Generation）三种方案。
而我们的目标是希望能搭建一个低资本、快速响应的问答知识库。由于微调/训练大语言模型需要耗费大量资源和时间，因此我们选择使用开源的当地大型语言模型团结RAG方案。经过测试，我们发现llama3:8b和qwen2:7b这种体量的大语言模型能快速响应用户的提问，比力符合我们搭建问答知识库的需求。
我们花了一段时间，对RAG各个步调的原理细节和改进方案进行了一些研究，下面将按照RAG的步调进行解说。
1.1 简述RAG原理

首先，我们来解说一下RAG的原理。假设我们有三个文本和三个问题，如下所示：

1. context = [  
2.     "北京，上海，杭州",  
3.     "苹果，橘子，桃子",  
4.     "太阳，月亮，星星"  
5. ]  
6. questions = ["城市", "水果", "天体"]

复制代码

接下来使用ollama的mxbai-embed-large模型，把三个文本和三个问题都转化为向量的体现形式，代码如下所示：

1. vector = []  
2. model = "mxbai-embed-large"  
3. for c in context:  
4.     r = self.engine.embeddings(c, model=model)  
5.     vector += [r]  
6.     print("r =", r)  
7. '''  
8. r = [-0.4238928556442261, -0.037000998854637146, ......  
9. '''  
10. qVector = []  
11. for q in questions:  
12.     r = self.engine.embeddings(q, model=model)  
13.     qVector += [r]  
14.     print("r =", r)  
15. '''  
16. q = [-0.3943982422351837,  
17. '''

复制代码

接下来使用numpy模块来编写一个函数，计算向量的相似度，代码如下所示：

1. def cosine_similarity(self, a, b):  
2.     return np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b))  
3. for i in range(3):  
4.     for j in range(3):  
5.         similar = self.engine.cosine_similarity(qVector[i], vector[j])  
6.         print(f"{questions[i]}和{context[j]}的相似度为：{similar}")  
7. '''  
8. 城市和北京，上海，杭州的相似度为：0.6192201604133171  
9. 城市和苹果，橘子，桃子的相似度为：0.6163859899608889  
10. 城市和太阳，月亮，星星的相似度为：0.5885895914816769  
11.   
12. 水果和北京，上海，杭州的相似度为：0.6260800765574224  
13. 水果和苹果，橘子，桃子的相似度为：0.6598514846105531  
14. 水果和太阳，月亮，星星的相似度为：0.619382129127254  
15.   
16. 天体和北京，上海，杭州的相似度为：0.5648588692973202  
17. 天体和苹果，橘子，桃子的相似度为：0.6756043740633552  
18. 天体和太阳，月亮，星星的相似度为：0.75651740246562  
19. '''

复制代码

从上面的示例可以看出，计算出的结果值越大，体现两个文本之间的相似度越高。上述过程是RAG原理的简化版。
有肯定基础的都知道，大语言模型本质上就是计算概率，因此它只能回答训练数据中包罗的内容。假如要搭建一个问答知识库，并且该知识库的内容是公开的，那么这些内容很大概已经包罗在大模型的训练数据集中。在这种情况下，不需要进行任何额外操纵，可以直接使用大模型进行问答，这也是目前大多数人使用大语言模型的普遍方式。
然而，我们要搭建的当地知识库大部分包罗私有数据，这些内容并不存在于当前大语言模型的训练数据集中。在这种情况下，可以考虑对大模型进行微调或重新训练，但这种方案既费时又费钱。
因此，更常用的方案是将知识库的内容放入到prompt中，让大语言模型通过我们提供的内容来进行回答。但是该方案存在一个问题，那就是token的长度限制（上下文长度限制）。比如，当地大语言模型中的qwen2:7b，token的最大长度为128k，体现输入的上下文通过AutoTokenizer计算出的长度不能凌驾128k，但是正常情况下，知识库的巨细凌驾128k是很正常的。我们不大概把全部的知识库内容都放入到prompt中，因此就有了RAG方案。
RAG的方案步调如下所示：

• 对知识库根据肯定的巨细进行分片处置惩罚。
  
• 使用embedding大模型对分片后的知识库进行向量化处置惩罚。
  
• 使用embedding大模型对用户的问题也进行向量化处置惩罚。
  
• 把用户问题的向量和知识库的向量数据进行相似度匹配，找出相似度最高的k个结果。
  
• 把这k个结果作为上下文放入到prompt当中，跟着用户的问题进行提问。
  

在开头的例子中，context变量相当于知识库的内容，"城市"就相当于用户提出的问题，接着通过相似度计算，"北京，上海"是最接近的信息，以是接着把该信息作为提问的上下文提供给GPT进行问答。
一个简单的prompt示例如下所示：

1. prompt = [  
2.   {  
3.       "role": "user",  
4.       "content": f"""当你收到用户的问题时，请编写清晰、简洁、准确的回答。  
5. 你会收到一组与问题相关的上下文，请使用这些上下文，请使用中文回答用户的提问。不允许在答案中添加编造成分，如果给定的上下文没有提供足够的信息，就回答"##no##"。  
6. 不要提供与问题无关的信息，也不要重复。  
7. > 上下文：  
8. >>>  
9. {context}  
10. >>>  
11. > 问题：{question}  
12. """  
13.   }  
14. ]

复制代码

1.2 使用redis-search计算相似度

在上述的例子中，是自行编写了一个cosine_similarity函数来计算相似度，但是在现实的应用场景中，知识库的数据会非常大，这会导致计算相似度的速度非常慢。
经过研究发现，能对向量进行存储并且快速计算相似度的工具有：

• redis-search
  
• chroma
  
• elasticsearch
  
• opensearch
  
• lancedb
  
• pinecone
  
• qdrant
  
• weaviate
  
• zilliz
  

下面分享一个使用redis-search的KNN算法来快速找到最相似的k个内容的方案。
首先搭建redis-search情况，可以使用docker一键搭建，如下所示：

1. $ docker pull redis/redis-stack  
2. $ docker run --name redis -p6379:6379 -itd redis/redis-stack

复制代码

接着编写相关python代码，如下所示：

1. # 首先定义一个redis相关操作的类  
2. import redis  
3. from redis.commands.search.query import Query  
4. from redis.commands.search.field import TextField, VectorField  
5.   
6. class RedisCache:  
7.     def __init__(self, host: str = "localhost", port: int = 6379):  
8.         self.cache = redis.Redis(host=host, port=port)  
9.   
10.     def set(self, key: str, value: str):  
11.         self.cache.set(key, value)  
12.   
13.     def get(self, key: str):  
14.         return self.cache.get(key)  
15.   
16.     def TextField(self, name: str):  
17.         return TextField(name=name)  
18.   
19.     def VectorField(self, name: str, algorithm: str, attributes: dict):  
20.         return VectorField(name=name, algorithm=algorithm, attributes=attributes)  
21.   
22.     def getSchema(self, name: str):  
23.         return self.cache.ft(name)  
24.   
25.     def createIndex(self, index, schema):  
26.         try:  
27.             index.info()  
28.         except redis.exceptions.ResponseError:  
29.             index.create_index(schema)  
30.   
31.     def dropIndex(self, index):  
32.         index.dropindex(delete_documents=True)  
33.   
34.     def hset(self, name: str, map: dict):  
35.         self.cache.hset(name=name, mapping=map)  
36.   
37.     def query(self, index, base_query: str, return_fields: list, params_dict: dict, num: int, startnum: int = 0):  
38.         query = (  
39.             Query(base_query)  
40.             .return_fields(*return_fields)  
41.             .sort_by("similarity")  
42.             .paging(startnum, num)  
43.             .dialect(2)  
44.         )  
45.         return index.search(query, params_dict)  
46.   
47. # 初始化类  
48. redis = RedisCache()  
49. # 定义一个文本类型，用来储存知识库内容  
50. info = TextField("info")  
51. # 建立一个向量类型，使用HNSW算法  
52. name="embedding"  
53. algorithm="HNSW"  
54. # DIM计算方法  
55. r = self.engine.embeddings(q, model=model)  
56. DIM = len(r)  
57. attributes={  
58.     "TYPE": "FLOAT32",  
59.     "DIM": DIM,  
60.     "DISTANCE_METRIC": "COSINE"  
61. }  
62. embed = VectorField(  
63.     name=name, algorithm=algorithm, attributes=attributes  
64. )  
65. # 创建索引  
66. scheme = (info, embed)  
67. index = redis.getSchema(self.redisIndexName)  
68. redis.createIndex(index, scheme)  
69.   
70. # 接着把所有知识库内容进行向量化后储存进redis中  
71. def insertData(self, model):  
72.     j = 0  
73.     for file in self.filesPath:  
74.         for i in file.content:  
75.             # i就是分片后的知识库内容  
76.             embed = self.engine.embeddings(i, model = model)  
77.             emb = numpy.array(embed, dtype=numpy.float32).tobytes()  
78.             im = {  
79.                 "info": i,  
80.                 "embedding": emb,  
81.             }  
82.             name = f"{self.redisIndexName}-{j}"  
83.             j += 1  
84.             self.redis.hset(name, im)  
85.   
86. # 查询  
87. # 取最接近的10个结果  
88. k = 10  
89. base_query = f"* => [KNN {k} @embedding $query_embedding AS similarity]"  
90. return_fields = ["info", "similarity"]  
91. # question为用户的问题  
92. qr = self.engine.embeddings(question, model = model)  
93. params_dict = {"query_embedding": np.array(qr, dtype=np.float32).tobytes()}  
94. index = self.redis.getSchema(self.redisIndexName)  
95. result = self.redis.query(index, base_query, return_fields, params_dict, k)  
96. for _, doc in enumerate(result.docs):  
97.     # 查看相似度值和上下文内容  
98.     print(doc.info, doc.similarity)

复制代码

2 RAG知识库难点
在了解了RAG的原理后，我们就可以尝试编写相关代码，搭建一个当地问答知识库。但是在我们开始举措后，就会发现事变并不会按照我们所预料的发展。
2.1 难点一：大语言模型本领不足

在我们的假想中，问答知识库是这样工作的：

• 根据用户的提问，在知识库中找到最相似k个的内容。
  
• 把这k个内容作为上下文，提供给大模型。
  
• 大模型根据用户提问的上下文，给出准确的答案。
  

但是在现实应用的过程中，步伐却无法按照我们的意愿运行，首先是问答的大语言模型本领不足，究竟我们使用的是qwen2:7b这种小体积的大模型，无法和GPT4这类的大模型相比力。但是修改一下提问的方式大概上下文和问题之间的顺序，还是能比力好的到达我们预期的效果。
但是更重要的是embed大模型的本领同样存在不足，这里用开头例子进行说明，我们把context的内容简单修改一下，如下所示：

1. context = [  
2.     "北京，上海，杭州",  
3.     "苹果，橘子，梨",  
4.     "太阳，月亮，星星"  
5. ]

复制代码

然后再计算一次相似度，如下所示：

1. 城市和北京，上海，杭州的相似度为：0.6192201604133171  
2. 城市和苹果，橘子，梨的相似度为：0.6401285511286077  
3. 城市和太阳，月亮，星星的相似度为：0.5885895914816769  
4.   
5. 水果和北京，上海，杭州的相似度为：0.6260800765574224  
6. 水果和苹果，橘子，梨的相似度为：0.6977096659034031  
7. 水果和太阳，月亮，星星的相似度为：0.619382129127254  
8.   
9. 天体和北京，上海，杭州的相似度为：0.5648588692973202  
10. 天体和苹果，橘子，梨的相似度为：0.7067548826946035  
11. 天体和太阳，月亮，星星的相似度为：0.75651740246562

复制代码

我们发现，"城市"竟然和"苹果，橘子，梨"是最相似的。固然这只是一个简单的例子，但是在现实的应用中经常会遇到这类的情况，通过用户提问的内容找到的知识库中最相似的内容有大概跟问题并不相关。
这是否是当地embed大模型的问题？OpenAI的embed大模型效果怎样？接着我们找了一些当地embed大模型和OpenAI的text-embedding-3-small、text-embedding-ada-002、text-embedding-3-large进行一个简单的测试，判定通干涉题找到的最相似的知识库上下文，是否是预期的内容。
最终的结果是，不管是当地的大模型还是OpenAI的大模型，成功率都在50%-60%之间。embed大模型的本领差是普遍存在的问题，并不但仅是当地embed大模型的问题。
该问题经过我们一段时间的研究，找到了“将就”能用的办理方案，将会在后文细说。
2.2 难点二：提问的复杂性

理想中的问答知识库是能处置惩罚复杂问题，并且能进行多轮对话，而不是一轮提问就竣事。
以Seebug Paper作为知识库，提出的问题具体到某一篇文章，并且多轮对话之间的问题是相互独立的，这种情况是最容易实现的。比如：

1. user: 帮我总结一下CVE-2024-22222漏洞。  
2. assistant: ......   
3. user: CVE-2023-1111漏洞的危害如何？  
4. assistant: ......   
5. ......

复制代码

但是想要让问答知识库成为一个好用的产品，不大概把目标仅限于此，在现实的应用中还会产生多种复杂的问题。
1.范围搜索性提问
参考以下几种问题：
   2024年的文章有哪些？
CTF相关的文章有哪些？
跟libc有关的文章有哪些？
…
  拿第一个问题举例，问题为：2024年的文章有哪些？。
接着问答知识库的流程为：

• 通过embed模型对问题进行向量化。
  
• 通过redis搜索出问题向量数据最接近的k个知识库内容。(假设k=10)
  
• 然后把这10个知识库内容作为上下文，让GPT进行回答。
  

假如按照上面的逻辑来进行处置惩罚，最优的情况就是，问答大模型根据提供的10个知识库上下文成功的回答了10篇2024年的文章。
这样问题就产生了，假如2024年的文章有20篇呢？也许我们可以进步k值的巨细，但是k值进步的同时也会增加运算时间。固然看似暂时办理了问题，但是却产生了新问题，k值进步到多少？进步到20？那假如2024年的文章有50篇。进步到100？那假如2024年的文章假如只有1篇，该方案就浪费了大量运算时间，同时大概会凌驾大语言模型的token限制，假如使用的是商业GPT(比如OpenAI)，那么token就是金钱，这就浪费了大量资金。假如使用的是开源大语言模型，token同样有限制，并且在token增加的同时，大语言模型的本领也会相应的降落。
2.多轮对话
参考以下多轮提问：
   user: 2024年的文章有哪些？
assistant: …
user: 尚有吗？
  问答知识库在处置惩罚第二个提问的流程为：

• 通过embed模型对"尚有吗？"问题进行向量化。
  
• 通过redis搜索出问题向量数据最接近的k个知识库内容。(假设k=10)
  
• …
  

问题产生了，根据"尚有吗？"搜索出的相似上下文会是我们需要的上下文吗？根本上不大概是。
该问题经过我们一段时间的研究，同样是找到了“将就”能用，但是并不优雅的办理方案，将会在后文细说。
2.3 难点三：文本的处置惩罚

在使用Seebug Paper搭建问答知识库的过程中，发现两个问题：

• 文章中的图片怎么处置惩罚？
  
• 文章长度一般在几k到几十k之间，因此是需要分片处置惩罚的，那么怎样分片？
  

关于图片处置惩罚勉强尚有一些办理方案：

• 使用OCR识别将图片转换为文字。（效果不太好，因为有些图片重要的不是文字。）
  
• 使用llava这类的大模型来对图片进行形貌和概括（llava效果不太好，不外gpt4的效果会好很多）。
  
• 直接加上如下图所示，并且在prompt中告诉GPT，让其需要用到图片时，直接返回图片的链接。
  

但是分片的问题却不是很好处置惩罚，假如要进行分片，那么怎样分片呢？研究了llama_index和langchain框架，根本都是根据长度来进行分片。
比如在llama_index中，对数据进行分片的代码如下所示：

1. from llama_index import SimpleDirectoryReader  
2. from llama_index.node_parser import SimpleNodeParser  
3.   
4. documents = SimpleDirectoryReader(input_dir="./Documents").load_data()  
5. node_parser = SimpleNodeParser.from_defaults(chunk_size=514, chunk_overlap=80)  
6. nodes = node_parser.get_nodes_from_documents(documents)

复制代码

在上面的示例代码中，设置了chunk_size的值为514，但是在Paper中，经常会有内嵌的代码段长度大于514，这样就把一段相关联的上下文分在了多个不同的chunk当中。
假设一个相关联的代码段被分成了chunk1和chunk2，但是根据用户问题搜索出相似度前10的内容中只有chunk2并没有chunk1，最终GPT只能获取到chunk2的上下文内容，缺失了chunk1的上下文内容，这样就无法做出精确的回答。
不但仅是代码段，假如只是通过长度进行分片，那么有大概相关联的内容被分成了多个chunk。
3 将就能用的办理方案
下面分享一些针对上面提出的难点研究出的办理方案，但是仅仅只是将就能用的方案，都是通过时间换准确率，暂时没找到完美的办理方案。
3.1 rerank模型

通过研究QAnything项目，发现可以使用rerank模型来提拔embed模型的准确率。
举个例子，比如你想取前10相似的内容作为提问的上下文。那么可以通过redis获取到前20相似的内容，接着通过rerank模型对这20个内容进行重打分，最后获取前10分数最高的内容。相关代码示例如下所示：

1. from BCEmbedding import RerankerModel  
2.   
3. # 初始化rerank模型  
4. rerankModel = RerankerModel(model_name_or_path="maidalun1020/bce-reranker-base_v1", local_files_only=True)  
5.   
6. ......  
7. # 搜索出知识库中与用户问题相似度最高的前20个内容  
8. k = 20  
9. result = self.redis.query(index, base_query, return_fields, params_dict, k)  
10. passages = []  
11. for _, doc in enumerate(result.docs):  
12.     passages += [doc.info]  
13. # 根据用户提问，对这20个内容进行重打分  
14. rerank_results = rerankModel.rerank(question, passages)  
15. info = rerank_results["rerank_passages"]  
16. last_result = info[:10]

复制代码

rerank模型本质上就是训练出了一个专门打分的大语言模型，让该模型对问题和答案进行打分。该方案肯定水平上可以提拔搜索出内容的准确度，但是仍然无法完美办理难点一的问题。
3.2 上下文压缩

通过研究LLMLingua和langchain项目，发现了上下文压缩方案。
在上面的例子中，都是以k=10来举例的，那么k的值等于多少才合适呢，这需要根据知识库分片的巨细和大语言模型的本领来调解。
首先，要求上下文的长度加上prompt的内容不能凌驾大语言模型token长度的限制。其次，根本全部的大语言模型都会随着上下文的增加导致本领降落。以是需要根据使用的大语言模型找到一个长度阙值，来设置k的巨细。
在现实应用中，会发现前k个上下文中大概大部分内容都跟用户的提问无关，因此可以使用上下文压缩技能，去除无用的内容，减小上下文体积，增加k值巨细。
由于LLMLingua项目使用的模型有点大，跑起来费时费电（跑不起来），以是根据其原理，实现了一个低级版本的压缩代码，如下所示：

1. def compress(self, question: str, context: list[str], maxToken: int = 1024) -> list[str]:  
2.         template = f"下面将会提供问题和上下文，请判断上下文信息是否和问题相关，如果不相关，请回复##no##，如果相关，请提取出和上下文相关的内容。*注意*：请直接提取出上下文的关键内容，请*不要*自行发挥，*不要*进行任何修改或者压缩删减操作。\n\n> 问题：{question}\n> 上下文:\n>>>\n%s\n>>>"  
3.         result = []  
4.         for c in context:  
5.             qs = template%c  
6.             answer = self.engine.chat(qs)  
7.             # print(c, answer)  
8.             # input()  
9.             if "##no##" not in answer:  
10.                 result += [answer]  
11.         newContent = "\n".join(result)  
12.         question = f"你是一个去重机器人，下面将会提供一组上下文，请你对上下文进行去重处理。*注意*，请*不要*自行发挥，*不要*进行任何添加修改，请直接在上下文内容中进行去重。\n上下文：>>>\n{newContent}\n>>>"  
13.         answer = self.engine.chat(question)  
14.         return answer

复制代码

由于有了上下文压缩方案，我们可以考虑设置k的值为一个非常大的值，然后分析计算出的相似度的值，比如我发现在我的案例中，redis搜索结果相似度大于0.4的内容就完全跟提问无关，rerank重打分分数小于0.5的内容完全跟提问无关，以是可以做出以下修改：

1. k = 1000  
2. ......  
3. passages = []  
4. for _, doc in enumerate(result.docs):  
5.     # 只取相似度小于0.4的内容  
6.     if float(doc.similarity) > 0.4:  
7.         break  
8.     passages += [doc.info]  
9. rerank_results = rerankModel.rerank(questionHistory, passages)  
10. info = rerank_results["rerank_passages"]  
11. score = rerank_results["rerank_scores"]  
12. contexts_list = []  
13. for i in range(len(info)):  
14.     # 只取重打分后分数大于0.5的  
15.     if float(score[i]) > 0.5:  
16.         contexts_list += [info[i]]  
17.     else:  
18.         break  
19. # 上下文压缩  
20. contexts = self.compress(question, contexts_list)

复制代码

通过以上方案，肯定水平上办理了范围性搜索提问的困难。同样，我们可以尝试寻找一个相似度分数的阙值，来办理多轮对话的困难，因为"尚有吗？"这类的多轮对话问题和知识库的相关性非常低，得到的分数都会非常低。这样当我们最终获取到的上下文内容为空时，表明当前为多轮对话，再按照对轮对话的逻辑进行处置惩罚。
3.3 知识库分片处置惩罚

经过研究，目前没找到完美的分片方案，我认为针对不同格式的知识库设计针对性的分片方案会比力好。
针对Seebug Paper的情况，我们考虑根据一级标题来进行分片，每个chunk中还需要包罗当前文章的基础信息，比如文章名称。假如有代码段，则需要根据token的巨细来进一步分片。
在一些框架中，不同chunk之前会有一部分重叠内容，但是我们研究后发现这种处置惩罚方案不会让最终的效果有较大的提拔。
经过研究，我们发现固定格式的文档是最佳的知识库素材，例如漏洞应急简报，每篇简报的内容巨细适中，并且接纳Markdown格式便于匹配和处置惩罚。我们能根据漏洞概述、漏洞复现、漏洞影响范围、防护方案、相关链接来进行分片，每部分的相关性都不大。
4 总结
我们盼望的问答知识库是大语言模型能根据我们提供的知识库快速、准确的回答用户的提问。目前来看是还是不存在理想中的问答知识库，一方面是由于大语言模型本领的限制，在当前的大语言模型中，快速响应和精准响应还是一对反义词。
使用embed大语言模型寻找相关文档的准确率太低，大部分的优化方案都是通过时间换取准确率。以是还是寄希望于天生式大语言模型未来的发展，是否能达成真人工智能。
目前的问答知识库和RAG类的框架效果相差不大，都是属于先把框架建好，把大语言模型分割开来，能随意更换各类大语言模型，因此这类框架的本领取决于使用的是什么大语言模型。相当于建造一个机器人，把身材都给搭建好了，但是还缺少一颗良好的脑子。
怎样学习大模型 AI ？

由于新岗位的生产效率，要优于被取代岗位的生产效率，以是现实上整个社会的生产效率是提拔的。
但是具体到个人，只能说是：
“最先掌握AI的人，将会比力晚掌握AI的人有竞争上风”。
这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。
我在一线互联网企业工作十余年里，引导过不少同行后辈。资助很多人得到了学习和成长。
我意识到有很多经验和知识值得分享给大家，也可以通过我们的本领和经验解答大家在人工智能学习中的很多困惑，以是在工作繁忙的情况下还是对峙各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法得到精确的资料得到学习提拔，故此将并将重要的AI大模型资料包括AI大模型入门学习头脑导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

第一阶段（10天）：初阶应用

该阶段让大家对大模型 AI有一个最前沿的认识，对大模型 AI 的理解凌驾 95% 的人，可以在相关讨论时发表高级、不跟风、又接地气的见解，别人只会和 AI 聊天，而你能调教 AI，并能用代码将大模型和业务衔接。

• 大模型 AI 醒目什么？
  
• 大模型是怎样得到「智能」的？
  
• 用好 AI 的核心心法
  
• 大模型应用业务架构
  
• 大模型应用技能架构
  
• 代码示例：向 GPT-3.5 灌入新知识
  
• 提示工程的意义和核心思想
  
• Prompt 典型构成
  
• 指令调优方法论
  
• 头脑链和头脑树
  
• Prompt 攻击和防范
  
• …
  

第二阶段（30天）：高阶应用

该阶段我们正式进入大模型 AI 进阶实战学习，学会构造私有知识库，扩展 AI 的本领。快速开辟一个完整的基于 agent 对话机器人。掌握功能最强的大模型开辟框架，捉住最新的技能希望，适合 Python 和 JavaScript 步伐员。

• 为什么要做 RAG
  
• 搭建一个简单的 ChatPDF
  
• 检索的基础概念
  
• 什么是向量体现（Embeddings）
  
• 向量数据库与向量检索
  
• 基于向量检索的 RAG
  
• 搭建 RAG 体系的扩展知识
  
• 混合检索与 RAG-Fusion 简介
  
• 向量模型当地部署
  
• …
  

第三阶段（30天）：模型训练

恭喜你，假如学到这里，你根本可以找到一份大模型 AI相关的工作，自己也能训练 GPT 了！通过微调，训练自己的垂直大模型，能独立训练开源多模态大模型，掌握更多技能方案。
到此为止，大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗？

• 为什么要做 RAG
  
• 什么是模型
  
• 什么是模型训练
  
• 求解器 & 损失函数简介
  
• 小实行2：手写一个简单的神经网络并训练它
  
• 什么是训练/预训练/微调/轻量化微调
  
• Transformer结构简介
  
• 轻量化微调
  
• 实行数据集的构建
  
• …
  

第四阶段（20天）：商业闭环

对全球大模型从性能、吞吐量、资本等方面有肯定的认知，可以在云端和当地等多种情况下部署大模型，找到适合自己的项目/创业方向，做一名被 AI 武装的产品经理。

• 硬件选型
  
• 带你了解全球大模型
  
• 使用国产大模型服务
  
• 搭建 OpenAI 署理
  
• 热身：基于阿里云 PAI 部署 Stable Diffusion
  
• 在当地计算机运行大模型
  
• 大模型的私有化部署
  
• 基于 vLLM 部署大模型
  
• 案例：怎样优雅地在阿里云私有部署开源大模型
  
• 部署一套开源 LLM 项目
  
• 内容安全
  
• 互联网信息服务算法备案
  
• …
  

学习是一个过程，只要学习就会有挑战。天道酬勤，你越努力，就会成为越良好的自己。
假如你能在15天内完玉成部的任务，那你堪称天才。然而，假如你能完成 60-70% 的内容，你就已经开始具备成为一名大模型 AI 的精确特征了。
这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们假如需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。