# ai-word

**Repository Path**: hellowllh/ai-word

## Basic Information

- **Project Name**: ai-word
- **Description**: ai相关的文档
- **Primary Language**: Unknown
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2026-03-31
- **Last Updated**: 2026-04-02

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

AI

向量

你要向一个没见过苹果的朋友描述一个苹果。你可能会说：“它是红色的，味道很甜，口感很脆。”
* 		颜色：红色程度打 0.9 分
* 		甜度：甜度打 8 分
* 		脆度：脆度打 7 分
那么，这个苹果的“向量”就可以表示为 [0.9, 8, 7]。这就是一个三维向量，因为它有三个特征。

如果我们有另一个水果，它的向量是 [0.8, 7, 8]（偏红、很甜、很脆）

AI 通过计算这两个向量 [0.9, 8, 7] 和 [0.8, 7, 8] 的相似度，就能判断出“哦，这两个东西很像，可能都是水果”。


Transformer

将每个词都翻译并且整合翻译——》 成为超级向量。



大模型 (Large Language Model, LLM)
* 大模型是动态的，它是一个复杂的“处理引擎”。它接收向量的输入，通过Transformer架构理解它们之间的关系，再通过概率预测的方式，一个接一个地生成新的向量，并最终把这些新向量“翻译”成我们能看懂的文字或图片。
* 		角色：核心智能引擎。
* 		功能：基于海量数据训练而成的神经网络（如 Llama 3, Qwen, GPT-4, DeepSeek 等）。它具备理解自然语言、逻辑推理、代码生成等能力。
特点：本身只是一个静态的模型文件（权重），无法直接处理并发请求或连接外部数据库，需要被“加载”和“运行”。

不同模型有输入限制（比如一次只能输入 4000 字），处理8KB等等。

》〉》〉》〉》〉
大模型,本质就是一个模型，只是比较大，比较牛逼 而已。它躺在磁盘上。文件里装的就是训练时学到的知识参数。

大模型只懂自然语言（文本）和数学向量。


 “推理服务” (Inference Service) 具体是什么？
推理服务就是一个“加载并运行”上述超大文件的软件系统。它的任务是把磁盘上静止的数字文件，变成能回答问题的智能服务。

它的核心工作流程：
* 加载 (Loading)：
    * 		服务启动时，它会从磁盘读取那个巨大的模型文件（权重），将其载入到高性能的显存 (GPU Memory) 或内存中。
    * 		注意：因为文件太大，普通电脑内存不够，必须用带有大显存的显卡集群来承载。
* 接收请求 (Request)：
    * 		它作为一个服务器（通常通过 HTTP 接口），等待用户发送消息。
    * 		用户输入：“今天天气怎么样？”【提示词，Prompt】
* 计算推理 (Inference)：
    * 		这是最核心的步骤。服务程序利用加载好的模型权重，结合用户的输入，进行复杂的数学运算（矩阵乘法、注意力计算等）。
    * 		它不是一个简单的数据库查询（查表），而是一个生成过程：根据前一个字，计算下一个字出现的概率，选出一个字，再基于这两个字算第三个字……以此类推，直到生成完整句子。
    * 		这个过程需要消耗大量的算力（GPU 计算资源）。
* 返回结果 (Response)：
		将生成的文字流式地（一个字一个字蹦出来）或一次性返回给用户。

每次输入长度限制（比如一次只能读 4000 字），而且文件太长它记不住。

>>>>>>
也就是推理服务，他是通用的模型托管平台。它们的核心架构就是“容器/服务”与“模型权重”分离的。

将它加载到内存里,对外暴露HTTP接口。  接收用户请求,做推理,返回结果。这就是推理服务

所以说：推理服务本质是个 无状态的 HTTP 服务,每个请求进来,处理完就结束,本身不保存任何状态。

典型就是 前期的  文心一言 一开始就仅仅是个推理模型。

 无状态的 HTTP 服务 —》 == 集群，可以横向扩展，支持无限并发。

这意味着：
	当你发送第一个请求：“我叫小明”，模型回答：“你好小明”。
	当你发送第二个请求：“我叫什么名字？”时，如果你直接把这句话发给模型，模型会一脸懵逼：“我不知道，你没告诉过我。”

提示词的阶段

上下文

那么大模型本身什么都不记得。如何让他记得我们之前的对话？

每次请求时,系统会把之前的聊天记录重新拼到对话里,一起发给大模型。这些拼起来发给大模型的内容,统称上下文。大模型看到完整上下文,自然就能接上话了。请你注意大模型的输入限制。本质还是

如果每次请求都把所有历史对话发出去,上下文会超长,这个问题如何? 

直接就是丢弃太久的内容。  —》 典型就是  文心一言

压缩技术—》 提取关键词，摘要 。 压缩的缺点，失真。

全部压缩不行的话，就要 有选择性的压缩，有针对性的压缩。

如何具体的做呢？

Memory

我们可以分两类管理:

当前会话最近几轮对话完整保存,这叫短期记忆。
很久之前的对话提取关键 信息压缩成摘要,这叫长期记忆。

每次请求时,都将它们拼进对话,发给大模型。
这样大模型看起来就像有记忆一样，而且效果还比较好。


新问题

有了记忆,大模型能记住历史对话了。但新问题又来了,大模型的训练数据，都是从互联网上抓的历史公开数据,训练完成后知识就固定了。你问它新的技术，它根本不可能知道。

怎么办?

定期去训练这个‘大模型’ ，把我们的最新的内容训练进去大模型里面。让这个大模型变大，变聪明。  【大模型微调】 
哈哈哈哈哈哈。 
那么你假如（你改一个错别字就需要重训练啦）
大模型的好坏都在你的手里啦。
还有如果是新闻呢？你不是在训练路上就是在训练的路上。

公司内部文档呢？  贵、慢、难以更新（改一个错别字要重训）、容易产生幻觉（胡说八道）



检索增强生成，Retrieval-Augmented Generation

给它配个外部知识库,里面可以放最新新闻、公司内部文档这些资料，存到数据库里。  如：《员工手册》
用户提问时,先从数据库里做匹配,获得相关知识,构建新的【提示词，Prompt】，调用 推理服务。

你是一个助手。请根据以下【参考信息】回答用户的问题。如果参考信息里没有答案，就说不知道。

【参考信息】：
片段1：员工请假需提前3天申请...
片段2：病假需提供医院证明...
片段3：年假每年有5天...

用户问题：公司关于请假的规定是什么？


所以这里的核心变成： 如何存，如何匹配？   向量数据库的诞生。


至此：
有了memory和RAG的加持,大模型能记住历史聊天和获取外部知识了。

已经很强啦。但是这么强还只是聊天呀。

它如何具备操作工具的能力呢?


Model Context Protocol

我们可以在对话里约定一种消息格式。外部先告诉大模型有哪些工具可用，大模型想用工具时,输出一段特定格式JSON,就行啦呢？简单的说就是调用接口，的一个开发规范。 比如发邮件，里面写清楚要发给谁和发什么。graph TD
    User[用户提问] --> App[应用层 (LangChain)]
    App -->|1. 注入工具描述 | LLM[大模型]
    LLM -->|2. 决策: 我需要调用工具 X, 参数 Y | App
    App -->|3. MCP 协议封装 (JSON-RPC) | MCPServer[MCP 服务器 (外部工具)]
    MCPServer -->|4. 执行真实操作 (查库/读文件) | MCPServer
    MCPServer -->|5. 返回结果 (JSON) | App
    App -->|6. 将结果转为自然语言上下文 | LLM
    LLM -->|7. 生成最终回答 | User


App 也叫 MCP Host （包含MCP Client）