LLM RAG - ChatGLM3-6B + LangChain + Faiss
RAG
使用知识库,用来增强 LLM 信息检索的能力
知识准确
先把知识进行向量化,存储到向量数据库中
使用的时候通过向量检索从向量数据库中将知识检索出来,确保知识的准确性
更新频率快
当发现知识库里面的知识不全时,可以随时补充
不需要像微调一样,重新跑微调任务、验证结果、重新部署等
应用场景
ChatOps
知识库模式适用于相对固定的场景做推理
如企业内部使用的员工小助手,不需要太多的逻辑推理
使用知识库模式检索精度高,且可以随时更新
LLM 基础能力 + Agent 进行堆叠,可以产生智能化的效果
LangChain-Chatchat组成模块
模块
作用
支持列表
大语言模型
智能体核心引擎
ChatGLM / Qwen / Baichuan / LLaMa
Embedding 模型
文本向量化
m3e-* / bge-*
分词器
按照规则将句子分成短句或者单词
LangChain Text Splitter
向量数据库
向量化数据存储
Faiss / Milvus
Agent Tools
调用第三方接口
...
LLM PEFT - ChatGLM3-6B + LoRA
通用 LLM
千亿大模型(130B、ChatGPT)和小规模的大模型(6B、LLaMA2)都是通用 LLM
通用 LLM 都是通过常识进行预训练的
在实际使用过程中,需要 LLM 具备某一特定领域知识的能力 - 对 LLM 的能力进行增强
增强方式
Method
Desc
微调
让预先训练好的 LLM 适应特定任务或数据集的方案,成本相对低LLM 学会训练者提供的微调数据,并具备一定的理解能力
知识库
使用向量数据库或者其它数据库存储数据,为 LLM 提供信息来源外挂
API
与知识库类似,为 LLM 提供信息来源外挂
互不冲突,可以同时使用几种方案来优化 LLM,提升内容输出能力
LoRA / QLoRA / 知识库 / API
LLM Performance = 推理效果
落地过程
Method
Pipeline
微调
准备数据 -> 微调 -> 验证 -> 提供服务
知识库
准备数据 -> 构建向量库 -> 构建智能体 -> 提供服务
API
准备数据 -> ...
LLM Deploy - ChatGLM3-6B
LLM 选择核心玩家
厂家很多,但没多少真正在研究技术 - 成本 - 不少厂商是基于 LLaMA 套壳
ChatGLM-6B
ChatGLM-6B 和 LLaMA2 是比较热门的开源项目,国产 LLM 是首选
企业布局 LLM
选择 MaaS 服务,调用大厂 LLM API,但会面临数据安全问题
选择开源 LLM,自己微调、部署、为上层应用提供服务
企业一般会选择私有化部署 + 公有云 MaaS 的混合架构
在国产厂商中,从技术角度来看,智谱 AI 是国内 LLM 研发水平最高的厂商
6B 的参数规模为 62 亿,单张 3090 显卡就可以进行微调和推理
企业预算充足(百万以上,GPU 费用 + 商业授权)
可以尝试 GLM-130B,千亿参数规模,推理能力更强
GLM-130B 轻量化后,可以在 3090 × 4 上进行推理
训练 GLM-130B 大概需要 96 台 A100(320G),历时两个多月
计算资源
适合 CPU 计算的 LLM 不多
有些 LLM 可以在 CPU 上进行推理,但需要使用低精度轻量化的 LLM
但在低精度下,LLM 会失真,效果较差
要真正体验并应用到实 ...
LLM - LangChain + RAG
局限
大模型的核心能力 - 意图理解 + 文本生成
局限
描述
数据的及时性
大部分 AI 大模型都是预训练的,如果要问一些最新的消息,大模型是不知道的
复杂任务处理
AI 大模型在问答方面表现出色,但不总是能够处理复杂任务AI 大模型主要是基于文本的交互(多模态除外)
代码生成与下载
根据需求描述生成对应的代码,并提供下载链接 - 暂时不支持
与企业应用场景的集成
读取关系型数据库里面的数据,并根据提示进行任务处理 - 暂时不支持
在实际应用过程中,输入数据和输出数据,不仅仅是纯文本
AI Agent - 需要解析用户的输入输出
AI Agent
AI Agent 是以 LLM 为核心控制器的一套代理系统
控制端处于核心地位,承担记忆、思考以及决策等基础工作
感知模块负责接收和处理来自于外部环境的多样化信息 - 文字、声音、图片、位置等
行动模块通过生成文本、API 调用、使用工具等方式来执行任务以及改变环境
LangChain - 开源 + 提供一整套围绕 LLM 的 Agent 工具
AI Agent 很有可能在未来一段时间内成为 AI 发展的一个重要 ...
LLM - Prompt
Prompt
是否充分使用好 AI 大模型,提示是关键
OpenAI
question / answer
prompt / completion - 给 LLM 一个提示,让 LLM 进行补全
LLM 训练原理
GPT 系列模型基于 Transformer 架构的解码器机制,使用自回归无监督方式进行预训练
训练过程 - 大量的文本输入,不断进行记忆
相比于监督学习,训练效率更低,但训练过程简单,可以喂大量的文本语料,上限比较高
completion
根据训练过的记忆,一个字一个字地计算概率,取概率最大的那个字进行输出
因此有人吐槽 LLM 输出很慢 - 逐字计算并输出
Prompt Engineering
需求描述越详细越准确,LLM 输出的内容就越符合要求
Prompt Engineering 是一门专门研究与 LLM 交互的新型学科
通过不断地开发和优化,帮助用户更好地了解 LLM 的能力和局限性
探讨如何设计出最佳提示,用于指导 LLM 帮助我们高效完成某项任务
不仅仅是设计和研发提示,还包含了与 LLM 交互的各种技能和技术
在实现与 LLM 交互、对接, ...
LLM - ChatGPT
Timeline
OpenAI 在 NLP 领域取得了突破性进展
ChatGPT 背后包含了一系列的资源整合 - 技术、资源、大厂背书、国际巨头的通力合作 - 工程 + 产品
NLPTransformer
基于 Transformer 架构的语言模型大体可分为两类
以 BERT 为代表的掩码语言模型 - Masked Language Model - MLM
以 GPT 为代表的自回归语言模型 - Autoregressive Language Mode - ALM
OpenAI
创造造福全人类的安全通用人工智能 - Artificial general intelligence - AGI
创立之初就摒弃了传统 AI 模型标注式的训练方式
可用来标注的数据总是有限的,而且很难做得非常通用
Autoregressive
基于自回归的无监督训练
BERT 由 Google 发布,非常权威,GPT 早期压力巨大 - GPT-2 引入了 zero-shot
按照人类语言的习惯,语言本身是有先后顺序的,下文依赖上文
自回归语言模型代表了标准的语言模型 - 利用上文信息预测下文
比传统 A ...
Kubernetes - Helm Doc
基本概念
Chart
包含在 Kubernetes 集群内部运行的应用程序、工具和服务所需的所有资源定义
Repository
用于存放和共享 Chart
Release
运行在 Kubernetes 集群中的 Chart 实例
一个 Chart 可以在同一个集群中被安装多次,每次安装都会创建一个 Release
基本使用Search
Source
Desc
hub
从 Artifact Hub 中搜索
repo
基于本地 repo 搜索,无需联网
hub123456$ h search hub wordpressURL CHART VERSION APP VERSION DESCRIPTIONhttps://artifacthub.io/packages/helm/kube-wordp... 0.1.0 1.1 this is my wordpress packagehttps://artifacthub ...
Go Engineering - CLI
应用框架
命令行参数解析 - Pflag
配置文件解析 - Viper
应用的命令行框架 - Cobra
命令需要具备 help 功能
命令需要能够解析命令行参数和配置文件
命令需要能够初始化业务代码,并最终启动业务进程
Pflag
命令行参数解析工具 - Kubernetes / Istio / Helm / Docker / Etcd / …
Flag
一个命令行参数会被解析成一个 Flag 类型的变量
1234567891011121314// A Flag represents the state of a flag.type Flag struct { Name string // name as it appears on command line Shorthand string // one-letter abbreviated flag Usage string ...
Go Engineering - Log
功能设计基础功能
支持基本的日志信息 - 时间戳、文件名、行号、日志级别、日志信息
支持不同的日志级别 - Debug / Info / Warn / Error / Panic / Fatal
logrus 支持 Trace 日志级别,Trace 不是必须的
Trace 和 Panic 是可选的级别
支持自定义配置 - 不同的环境采用不同的配置
开发环境的日志级别为 Debug,而生产环境的日志级别为 Info
通过配置,可以在不重新编译代码的情况下,改变记录日志的行为
支持输出到标准输出和文件
至少实现 6 个日志级别
日志调用时的属性
输出级别
glog.Info(“This is info message”)
开关级别
启动程序时,期望哪些输出级别的日志会被打印
glog -v=L - 只有输出级别 ≥L 的日志才会被打印
高级功能
支持多种日志格式 - TEXT / JSON / …
开发环境采用 TEXT 格式,生产环境采用 JSON 格式
按日志级别分类输出 - Error 级别日志可 ...
Go Engineering - Error Code
预期功能
有业务 Code 码标识 - HTTP Code 码有限
安全 - 对内对外展示不同的错误信息
设计方式
无论请求成功与否,都返回 200,在 HTTP Body 中包含错误信息
HTTP Code 通常代表 HTTP Transport 层的状态信息
缺点:性能不佳(需解析 Body) + 对客户端不友好
返回 4xx or 5xx,并在 Body 中返回简单的错误信息
返回 4xx or 5xx,并在 Body 中返回详细的错误信息 - 推荐
设计思路
区别于 http status code,业务码需要有一定的规则,可以通过业务码判断出是哪类错误
请求出错时,可以通过 http status code,直接感知到请求出错
需要在请求出错时,返回详细的信息:Code + Message + Reference(Optional)
返回的错误信息,需要是可以直接展示给用户的安全信息,不能包含敏感信息
但同时也要有内部更详细的错误信息,方便 Debug
返回的数据格式应该是固定的,规范的
错误信息要保持简洁,并提供有用的信息
Biz Code
纯数字表示,不同部位代表不同的服务,不 ...