AI大模型开发知识
大模型最开始火的时候，是OpenAI在2022年11月底发布ChatGPT，它的能力就是与在网页与AI聊天，以下是一个简单的对话例子：
用户：“你是谁”
AI：“我是豆包，AI 助手，陪你聊天、答疑、写东西都可以”
我发给AI的Http post的json
{ "messages": [ {"role":"user","content":"你是谁"} ] }AI会给我的json
{ "message": { "role": "assistant", "content": "我是豆包，AI 助手，陪你聊天、答疑、写东西都可以" } }下面的后续的对话内容：
用户：“你是谁”
AI：“我是豆包，AI 助手，陪你聊天、答疑、写东西都可以”
用户：“你能做些什么”
AI：“我是做这些......”
我发给AI的Http post的json
{ "messages": [ {"role":"user","content":"你是谁"}, {"role":"assistant","content":"我是豆包，AI 助手，陪你聊天、答疑、写东西都可以"}, {"role":"user","content":"你能做些什么"} ] }AI会给我的json
{ "message": { "role": "assistant", "content": "我是做这些......" } }ps：以上例子省略了很多字段，role也不止user、assistant
可以看出来AI的使用就是http接口调用，而且它是无记忆的，你需要让它知道前面的对话记录，它才能更好的理解并回答你；
AI大模型的原理
大模型的起源是Google在2017年发表的论文《Attention Is All You Need》，提出的Transformer架构，最开始作用只是为了解决多国语言互相翻译；
- 编码器：读懂原句子
- 解码器：生成翻译后的句子
然后OpenAI看到这个模型，进行了魔改；
前置准备：
Token：
在AI大模型的运算里，在语义上不可再分割的最小词元（类似于物理中的原子），就是Token，词元包括一个中文字、一个中文词、一个中文的偏旁部首、一个英文单词、一个英文单词的一部分、一个符号等等
词表：
AI大模型一般会有一个固定量的词表（OpenAI最开始是几万个词元），然后大模型厂商会训练宇宙量的数据，这些词表的每个Token会存储一个多维向量值（几百几千维），这个多维向量值就代表了这个Token的词意；
向量值示例：
[0.21, 0.55, -0.13, 0.79, 0.32, …… 共512/1024个数字]
向量：
一个（多维）坐标系中的一个点，以及从坐标系原点出发，构成的一个方向和长度；
每个维度代表一个物理世界的某个特征含义，这个特征是从训练AI的宇宙量数据里提取出来的；
比如：
- 苹果：(甜：8, 脆：5)
- 梨子：(甜：7, 脆：6)
- 青菜：(甜：1, 脆：3)
甜是一个维度，脆是一个维度
脆度(Y) ↑ 8 │ 7 │ 梨子(7,6) 6 │ 5 │ 苹果(8,5) 4 │ 3 │ 青菜(1,3) 2 │ 1 │ 0 ───────────────────→ 甜度(X) 0 1 2 3 4 5 6 7 8 9所有维度的向量值会构成一个多维空间的方向和长度，这个方向和长度越接近的两个词，代表两者的综合含义越接近；
方向：更多代表语义
长度：更多代表词的重要程度、置信度、信息量
举个例子：
"开心" → 方向 ↗
"高兴" → 方向 ↗ （几乎重合 → 语义接近）
"快乐" → 方向 ↗
"悲伤" → 方向 ↘ （方向相反 → 语义对立）
"苹果" → 方向偏向【水果】区域
"香蕉" → 方向偏向【水果】区域 （方向接近）
"汽车" → 方向偏向【交通工具】区域 （方向差异大）
"革命" → 长度长 ████████ （信息量大，语义鲜明）
"民主" → 长度长 ████████
"的" → 长度短 ██ （虚词，几乎没语义信息）
"了" → 长度短 ██
"嗯" → 长度短 █
“今天 出门 散步 了，但是 半路 下起 暴雨 只能 折返。”
今天出门散步了 ██
但是 ██████
半路下起暴雨只能折返 ██
向量计算公式：
两个Token的多维向量值做以下公式计算
点积：计算两个Token之间的综合含义是否接近，同时计算了方向和长度
余弦相似度：计算两个Token之间的语义是否接近，只计算了方向（实际是在点积基础上统一了长度）
用户提问流程：Transformer
1、首先将用户的提问，分解为一个个Token，得到每个字的多维向量值（QKV）；
2、这个时候每个Token会与其他所有的Token做点积计算，算出来的值越大代表互相之间的关系更紧密，从而得到每两个Token之间的语义关联强弱关系
3、把所有的计算结果经过Softmax，得到每个Token的一个比例权重值，加起来等于1；
4、把每个Token的比例权重值 * 原有多维向量值（QKV），得到这个Token的新的多维向量值；
ps：这个新的多维向量值里面包含了这个Token自己的信息以及与其他Token的一部分信息；
5、重复1-4的步骤很多次，每个Token的多维向量值都被刷新了N遍，导致每个Token与其他Token之间越来越熟悉，即每个Token的多维向量值存储了所有Token的信息；
6、所以只需要看用户提问的最后一个Token（代表了整句话的所有信息），与大模型的（词表）每个Token做点积运算（只是过程描述，实际并不是foreach一个个算，而是有矩阵运算之类的数学公式一次能算出所有结果），再经过Softmax，得到与用户提问的最后一个Token的语义最接近的词库里的Token，那么就得到了下一个字是什么；
7、整个过程就是预测最大概率出现的下一个字，当模型预测出来的最后一个字是一个结束符号，那么就代表已经回答完毕了；
例子：
比如用户提问：我明天要去北京，分解 Token 为：我、明天、去、北京。经过点积计算后发现北京和明天、去的语义关联度最高，说明这几个词在语境里联系最紧密。
经过 Softmax 算出各 Token 对应的权重，再用权重加权融合所有向量，每个 Token 都吸纳了整句话的上下文信息。经过多层 Transformer 迭代更新后，末尾 Token 已经完整承载整句语义。
随后用这个融合后的向量，和词表中所有 Token 依次做点积、再做 Softmax 概率换算，模型计算得出，结合前文语境，玩 (0.68)、出差 (0.21)、旅游 (0.11)这类 Token 概率最高，于是优先输出概率最大的玩。
玩 ：68%
出差 ：21%
旅游 ：11%
... ：2%
... ：1%
此时句子变为：我明天要去北京玩。
接着把新生成的玩也纳入 Token 序列，重复上述注意力计算、向量更新、概率预测的流程，继续推算下一个字，不断逐词生成内容。直到模型预测出终止符，生成流程结束，最终形成完整回答。
疑问：
既然AI大模型是概率论，但是我们往往得到的回答都是对的，AI的训练数据都是从网上拉取的，那么是不是证明网上出现正确的答案比错误的答案更多？
- 网络素材里正确内容数量远多于错误内容，奠定基础；
- 少数错误文本频次低、互相矛盾，模型学不到错误的稳定规律；
- 微调、人类反馈对齐会专门修正网络自带的错误信息；
- 推理时优先选取高概率、符合共识的文字，极少输出低概率错误内容。
AI大模型的能力
AI大模型的原生能力只有一个，就是通过调API，发一段话给大模型，然后返回一段话给你；
在此基础上有一个进阶能力：Function Call
AI大模型喂了宇宙量的函数数据，训练出可以理解函数的能力。
翻译成大白话就是，可以发一段用户提问+几个函数定义给AI，它能理解这些函数的含义，并回复给你说，针对用户提问，可以调其中一个或多个函数来解决，并带有调这些函数的具体参数值；
例子：
已知有2个函数
get_weather(city: str)：查城市当天天气calc_math(expr: str)：计算数学表达式
def calc_math(expr): return eval(expr) def get_weather(city): # 调用真实天气API return { "city": "深圳", "temperature": 28, "condition": "多云", "wind": "微风" }我发给AI的Http post的json
{ "messages": [ {"role":"user","content":"帮我算 128×56 等于多少？顺便查一下深圳今天天气。"} ], "tools": [ { "type": "function", "function": { "name": "calc_math", "description": "计算数学表达式，支持加减乘除", "parameters": { "type": "object", "properties": { "expr": { "type": "string", "description": "数学表达式，如 128*56" } }, "required": ["expr"] } } }, { "type": "function", "function": { "name": "get_weather", "description": "查询指定城市当天天气", "parameters": { "type": "object", "properties": { "city": { "type": "string", "description": "城市名，如 深圳" } }, "required": ["city"] } } } ] }AI会给我的json
{ "message": { "role": "assistant", "content": "", "tool_calls": [ { "id": "call_001", "type": "function", "function": { "name": "calc_math", "arguments": "{\"expr\":\"128*56\"}" } }, { "id": "call_002", "type": "function", "function": { "name": "get_weather", "arguments": "{\"city\":\"深圳\"}" } } ] } }这个时候，我们的程序知道了AI建议我们去调这两个函数，那么我们就顺着AI的意思，写代码去执行这两个函数，并得到结果。
ps：这个过程是我们程序里自己完成的，再次强调AI只有我们发一段话给它，然后它返回一段话给我们的能力，它只有大脑，没有手脚
等我们程序执行完函数后，将执行结果发给AI，它会知道这个是函数的结果，并组织一段通人性的话再返回
{ "messages": [ { "role":"user", "content":"帮我算 128×56 等于多少？顺便查一下深圳今天天气。" } ], "tools": [...] }, { "messages": [ "role": "assistant", "content": "", "tool_calls": [...] ] }, { "messages": [ "role": "tool", "tool_call_id": "call_001", "content": "7168" ] }, { "messages": [ "role": "tool", "tool_call_id": "call_002", "content": "深圳今日晴，气温26℃，微风" ] }, # 后续AI回给我们的 { "messages": [ "role": "assistant", "content": "128乘以56的结果是7168。深圳今天天气晴朗，气温26℃，伴有微风。" ] }Function Call的应用场景
1、精准匹配
普通对话没有任何数据结构可言，如果我们要通过纯对话发给 AI 的话，它可能返回一段序列化后的Json给我们（或者任意字符串），我们要在程序里把它解析出方法名、参数等等；
风险有：Json格式不对、方法名对不上、参数名对不上、参数格式没办法转化为预定的类型、参数值不在预设的范围里；
不方便有：如果不写成函数的话，我们丢给它的tool功能会描述起来非常麻烦以及不直观；
而由于AI大模型学习了函数调用Function Call，可以让 AI 按照约定好的结构化格式返回给我们可以立刻调用该函数的所有信息；我们用代码的形式描述一件事比纯文字描述（后续还要回归代码）一件事要高效多
2、扩展能力
从 “聊天” 走向 “落地干活” 的核心能力。当AI大模型访问给我们调用函数的所有信息后，我们就可以拿着它去执行这个函数，这个函数可以实现控制本地、查询数据库、调用某API等等各种程序里能办到的事；
然后我们把在本地执行该函数的结果再次告诉AI，它进行后续的对话，也就间接弥补了AI落地干活的完整能力，不仅仅只是聊天；
其他AI大模型
向量大模型
一个专门生成AI向量的大模型，发给它一段话，它会返回给你代表这段话的多维向量值；是一个生成基础数据的模型，为了后续其他应用使用；
其实主要是用来做余弦相似度用的，也就是语义相似性判断，一般给RAG或AI应用来用；
VL大模型
一个专门处理图像的大模型，发给它一个图片、视频等，它能理解其中的含义；实际底层原理还是 Transformer 那套，输入图片先切分成多个固定尺寸小图块，每一个图块是一整组 RGB 像素集合（语义特征上不可再分割的最小单元），不会单独拿单个 RGB 色值当 Token；通过 CNN / 图像编码器把整块 RGB 像素数据压缩抽象成一个视觉特征多维向量，这个多维向量就是视觉版 Token，替代文本里的汉字 Token。后续同样走 QKV 注意力、多层 Transformer 迭代计算，融合整张图片全部内容信息；最终可以实现看图描述、图文问答、OCR 识别等能力。
衍生还有音频大模型，逻辑同理，将声波波形转成频谱特征 Token 后送入 Transformer 计算。
ps：与普通AI大模型相似，它们还是只能通过http接口发送文本的形式来调用，并没有什么上传文件的接口，我们在市面上看到的豆包、deepseek之类的网页版能上传文件只是它们在AI大模型基础上做的AI应用，处理好上传文件后才发给大模型；
多模态文件发给大模型的时候，一般是转为base64，并带上文件名，再加上用户提问，组成一个数组，比如：
{ "model": "qwen-vl-7b", "messages": [ { "role": "user", "content": [ { "type": "text", "text": "提取图片里所有表格数据" }, { "type": "image_url", "image_url": { "url": "data:image/jpeg;base64,xxxx此处替换图片base64字符串xxxx", "file_name": "数据表格.jpg" } } ] } ], "temperature": 0.7 }AI大模型的周边能力
MCP：
首先：大模型并不知道MCP是什么，它只是AI外部的工程化成果；
自主部署、扩展能力
设想我们已经有了AI对话能力，也能用FunctionCall去实现落地干活的能力，但是我们有多套系统，都需要一个查询当天天气的能力；
已知AI大模型的训练数据是停在某一个固定时间点，也就是说它永远都不知道当天天气怎么样，所以我们可以写一个FunctionCall去调百度天气的API接口，返回给AI让它知道，然后再进行后续的对话；
但是我们的需求是有多套系统都要有这个能力，所以最好的方法是我们把这个查当天天气的函数单独部署在一个独立的服务，其他的系统就通过接口来获取和调用这个服务，比如get接口返回函数定义（纯Json），post接口的参数为AI返回的函数+参数值，执行后返回当天天气给调用方系统，这样就实现了写一个函数，多个系统用；
这里有一个问题就是这个服务的get post等接口的参数得定一下，要不然随意写的话只能自己对接了，所以就有了mcp数据协议，方便所有的AI应用都能方便的对接MCP服务，而不会导致各种对接不统一，这就是我们看到的各种MCP插件的集成
Skill
首先：大模型并不知道Skill是什么，它只是AI外部的工程化成果；
省Token
渐进式披露
设想我们要让AI做的事有很长的流程说明，如果我们要讲所有流程都发给AI的话，会占用非常大的上下文，导致AI回复会特别慢，如果我们只是把每个流程的name和description发给AI，并且告诉AI一个FunctionCall，来获取需要被调用的skill的其他全部内容的话，不仅可以节省Token，也可以大大提高回复的速度；
有一个FunctionCall就叫查询skill内容；
RAG
根据语义搜索相关度高的结果
相比于数据库、Redis、ES 等搜索之间的差别，
数据库：只能实现精准匹配、模糊匹配，自带分词能力弱、检索性能差；
Redis：仅支持精准键值匹配，无分词、无语义检索能力；
ES：高性能分词检索，依靠词语字面匹配查询。
但是以上三类全部只能基于文字关键词匹配，没办法实现语义相似检索。依托余弦相似度计算逻辑：先将用户整段提问送入向量模型生成一条多维向量，再提前把知识库文档切分成若干文档分片，每个分片单独生成一条多维向量存入向量库；检索时使用提问向量和全部分片向量逐个计算余弦相似度，按相似度分值筛选 Top N 高分相关文档片段，把原文片段连同用户问题一起拼入上下文，交给大模型依托参考素材组织答案。
海量数据场景下逐条手写循环算余弦耗时巨大，因此引入向量数据库：底层针对高维向量距离、余弦相似度运算做了索引与算法专项优化，能毫秒级完成百万、千万级向量相似度召回，远优于业务代码全量遍历计算。
补充落地优势
- 解决大模型知识滞后：不用微调模型，新增业务文档直接切片向量化入库即可被检索使用；
- 抑制大模型幻觉：AI 回答被限定在检索出来的真实文档范围内，减少凭空编造内容。
工程常用优化
实际项目多用多路召回：ES 分词关键词召回 + 向量语义召回，两份结果合并去重后再筛选片段，兼顾字面命中与语义命中，提升资料召回完整度。
对话内容
现阶段，一般发给AI大模型的对话里包括的内容：有一套脚手架Harness
1、系统提示词：AI的角色背景
2、整体流程
3、Few-shot 示例
4、各种准则，做事方法，行为约束禁止规则等（Guardrails护栏）
5、FunctionCall（或来自MCP）
6、Skill
7、历史对话记录：包括多轮的用户提问、AI对话、AI调tool后的回复、RAG回复（也可以算在AI调tool后的回复）
8、用户提问：包括多模态文件+文字提问
ps: 1-4 也可以都放到1里，不过市面上都是分开的，应该是更科学些；
AI大模型开发框架
.net开发框架：
SK：基础能力封装；包括对话、FunctionCall、自动触发等，比自己写接口调用做会方便很多倍
MAF：在SK的基础上多个AI互相合作的能力
python开发框架：
LangChain：同SK
LangGraph：同MAF
python开发为什么更有优势
python因为各种原因非常适合做AI开发，导致它的各种轮子是最全，所以你不想因为各种高级能力，在网上各种找其他开发语言的轮子的话，那么用python是更省心的做法
OpenAI兼容模式
虽然调用AI都是调接口而已，但是实际各家大模型的接口参数都不一样，由于OpenAI是出来的最早一家，所以后出的大模型厂商都会兼容OpenAI的接口参数，实际就是把OpenAI的参数再转化成自家的接口参数，对于要求热切换大模型的企业型系统，基本都是用OpenAI兼容模式去达到忽略模型厂商的目的
本地大模型
虽说OpenAI兼容模式解决了一致化调用的问题，但是它相对于原生调用是有损耗的，模型处理压力不大的情况下会只有10%-20%左右的差距，但是模型压力一旦上来后，可能会有甚至超过100%的差距；
所以在本地大模型的情况下，它的版本又不像线上每一家都不一样，它只有固定的几个版本，我们可以根据url不同来固定适配这几种原生模式，做到没有转换损耗；
BaseUrl switch { // 带/v1：全走OpenAI统一SDK，vLLM/SGL零损耗、Ollama自愿用兼容 var u when u.EndsWith("/v1") => OpenAI链路, // 裸Ollama地址：切Ollama原生规避兼容损耗 var u when u.Contains(":11434") => Ollama原生, // vLLM/SGL裸地址本身原生就是v1规范，仍走OpenAI完全没问题 var u when u.Contains(":8000") || u.Contains(":30000") => OpenAI链路, var u when u.Contains(":7860") => Oobabooga, _ => throw }本地大模型开发杂谈
本地大模型相对于线上而言，由于算力资源有限，限制特别大，所以运用好有限的资源特别重要；
原则
1、上下文不能多，且不能复杂化，否则速度和准确度都会大打折扣，可以分多次简单化处理，渐进式披露，转换业务使之简单化；
2、能自己处理就自己处理，大模型只做简短的语义化理解并判断
3、效率要高，比如
不用OpenAI兼容模式，使用原生模式减少损耗
尽量选用快的模型（比如量化模型），在结果可接受的情况下
关闭思考
调参
强制返回JSON结构
关闭思考模式（接口层、基础设施层）
向量余弦相似度应用
余弦相似度实际是在点积的基础上，把所有向量的值的长度统一了（用某个数学公式），在这基础上再去看两个向量值的方向是否接近，达到判断这两个向量的语义是否接近；
应用具体：当我们把几百几千个FunctionCall，如果都要发给AI去决定需要调哪一个函数的话，会占用非常大的AI上下文，很容易造成AI回答非常慢；
解法：我们可以把所有的FunctionCall依次发给AI向量大模型，得到多个多维向量值，每个多维向量值代表一个FunctionCall函数，然后把用户的提问也发给AI向量大模型，得到一歌多维向量值，然后拿这个多维向量值与每个FunctionCall函数的多维向量值做余弦相似度计算，得到这个用户提问与每个FunctionCall的语义相似度（0-1的值），按相似度排序，取Top N的FuntionCall函数再发给AI对话大模型，极大概率上我们想要匹配的FunctionCall就在这个Top N里；
这样就达到了节省上下文的目的；