大模型最开始火的时候是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之间的语义是否接近只计算了方向实际是在点积基础上统一了长度用户提问流程Transformer1、首先将用户的提问分解为一个个Token得到每个字的多维向量值QKV2、这个时候每个Token会与其他所有的Token做点积计算算出来的值越大代表互相之间的关系更紧密从而得到每两个Token之间的语义关联强弱关系3、把所有的计算结果经过Softmax得到每个Token的一个比例权重值加起来等于14、把每个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 CallAI大模型喂了宇宙量的函数数据训练出可以理解函数的能力。翻译成大白话就是可以发一段用户提问几个函数定义给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接口返回函数定义纯Jsonpost接口的参数为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大模型的对话里包括的内容有一套脚手架Harness1、系统提示词AI的角色背景2、整体流程3、Few-shot 示例4、各种准则做事方法行为约束禁止规则等Guardrails护栏5、FunctionCall或来自MCP6、Skill7、历史对话记录包括多轮的用户提问、AI对话、AI调tool后的回复、RAG回复也可以算在AI调tool后的回复8、用户提问包括多模态文件文字提问ps: 1-4 也可以都放到1里不过市面上都是分开的应该是更科学些AI大模型开发框架.net开发框架SK基础能力封装包括对话、FunctionCall、自动触发等比自己写接口调用做会方便很多倍MAF在SK的基础上多个AI互相合作的能力python开发框架LangChain同SKLangGraph同MAFpython开发为什么更有优势python因为各种原因非常适合做AI开发导致它的各种轮子是最全所以你不想因为各种高级能力在网上各种找其他开发语言的轮子的话那么用python是更省心的做法OpenAI兼容模式虽然调用AI都是调接口而已但是实际各家大模型的接口参数都不一样由于OpenAI是出来的最早一家所以后出的大模型厂商都会兼容OpenAI的接口参数实际就是把OpenAI的参数再转化成自家的接口参数对于要求热切换大模型的企业型系统基本都是用OpenAI兼容模式去达到忽略模型厂商的目的本地大模型虽说OpenAI兼容模式解决了一致化调用的问题但是它相对于原生调用是有损耗的模型处理压力不大的情况下会只有10%-20%左右的差距但是模型压力一旦上来后可能会有甚至超过100%的差距所以在本地大模型的情况下它的版本又不像线上每一家都不一样它只有固定的几个版本我们可以根据url不同来固定适配这几种原生模式做到没有转换损耗BaseUrl switch { // 带/v1全走OpenAI统一SDKvLLM/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里这样就达到了节省上下文的目的