AI备忘录 - 大语言模型
type: channel
link: https://www.aiuai.cn/category/llm/
description: 大语言模型
items: AI大模型企业业务应用模式[转]
items: vLLM Python 运行 gpt-oss 模型
items: Post-Train和Finetune三种模型训练技术
items: vLLM与Ollama模型推理部署对比
items: vLLM与Hugging Face模型推理对比
items: 多模态RAG评测流程[转]
items: Ollama运行本地路径模型
items: DeepSeek-R1 GPU硬件要求
items: LLM驱动的智能体如何引领行业变革及应用探索与未来展望[转]
items: 基于RAG的信息检索[译]

AI大模型企业业务应用模式[转]
type: item
date: 2025-10-01T00:38:16+08:00
description: From: 阿里云CIO首次系统复盘：大模型落地的RIDE方法论与RaaS实践突破AI大模型企业业务应用模式这里，我重点讲述深蓝色部分的两种模式：第一个是翻译模式，第二个是 Agent 模式，我认为主要分为这两种典型的应用模式。其中，翻译模式最容易取得成效，因为它相对简单；而智能体模式则较为复杂。翻译模式先谈谈翻译模式。 在公司内部，将所有翻译类模式统称为 AI 领域的“低垂果实”，这类模式相对容易实现。这一轮的大型语言模型背后的算法是 Transformer。Transformer 最早是 Google 为了翻译任务而开发，在不停做翻译的过程中衍生出了 Transformer 算法。随后，预训练模型如 BERT 也大量应用于翻译领域。所以，大模型的原理 Transformer 特别擅长做翻译。翻译又可以分为狭义翻译和广义翻译。狭义翻译指的是中译英、英译中等语言之间的转换。而广义翻译则涵盖更广泛的形式，比如：自然语音转成文本，再转成语音；自然语言转成 SQL 语言；自然语言转成 Java 语言；甚至让一篇论文用自然语言“翻译”成中学生能听懂的表述，这些都属于广义翻译范畴。无论是狭义翻译还是广义翻译，Transformer 都特别擅长，因此这是最容易出结果的地方。但这里有一个坑： 虽然（图中）左边的翻译能力已经具备，但如果右边原有的系统还没准备好（not ready），就会出现问题。以 Chat BI 来说，为什么 Chat BI 在企业里没什么成功的案例呢？其实很大一部分原因在于，Chat BI 的逻辑无外乎就是：用自然语言翻译成 SQL，然后在后台的数据库或大数据系统里执行，再把执行结果取出来，再翻译成自然语言返回给人。它的实质，就是自然语言 → SQL → 执行结果 → 自然语言，这本质上还是一种翻译。但我们会发现一个很有意思的问题：很多企业说要上 Chat BI，但如果原本数据库和里面的业务逻辑、数据口径积累不足，甚至连人都写不出对应的 SQL 来，那自然语言也一样翻译不出来。因为后台本身没有可执行的基础。所以作者认为，企业里绝大部分在 Chat BI 上踩的坑，都来自于一开始就想做一个过于“宽”的东西。但是做了这个翻译之后，如果原来的系统 API 没准备好，数据没准备好，甚至连原来的人都无法执行这些操作，那自然语言翻译也没法落地。这就是最大的误区。因此我们在内部的逻辑是：要先Identify 原系统具备哪些能力。比如，如果你原来的 ODPS、数据库和数据中台本身已经有 BI 和运营，能够在某个领域里不断取数、用 SQL 分析数据，而且业务场景也很丰富，那么，那些高频的 SQL 语句才是真正值得作为翻译目标的部分，而不是盲目地去做一个 Chat BI。所以很关键的是要分成两个部分 ：一部分是翻译，一部分是原来系统的语言处理能力。我习惯这么来形容：原来的系统就是“蛋糕坯”，大模型翻译就是上面的“樱桃”。如果你现有的蛋糕坯是 ready 的，我放一个樱桃上去，你就可以吃樱桃蛋糕了。但是如果原来的蛋糕坯都没有，你让我做一个樱桃蛋糕，那是做不出来的。所以，这里非常关键的一点就是：你要能够识别出原来的蛋糕坯是不是 ready ，然后在上面放上你的樱桃，而不是直接拿一个樱桃就装作是樱桃蛋糕。这个地方往往就是个误区。Agent 模式再说 Agent 应用模式。大家可以注意这样一句话：所有的 Agent 应用模式都是始于用户意图，终于意图满足。如果你不是从用户意图出发，最后又不是以是否满足客户意图来作为度量标准去看待你的智能体，那一定会失败，没有任何成功的可能性。这是我发现团队甚至整个业界，最容易出现的问题。因此我们引出了一个方法，这是我在内部做智能体时，一定要去践行的方法。第一件事情，要找到这个领域的“意图空间”。 当一个客户在智能体里和你交互时，他一定是带着意图的。那么这些意图都有哪些？比如客服场景里，客户会提出各种咨询问题，这些问题本质上就是一个空间、集合。所以，第一步就是要搞清楚这个集合的 边界和完整性。如果你不知道它的完整性，就无法去度量。只有在建立了完整的意图空间之后，才能继续往下做。所以第一件事要建立意图空间。然后，当清楚地知道了意图空间，就要基于这个意图空间来准备 知识工程。也就是说，你的知识、文档是否完备？API 和结构化数据是否具备？能否真正满足客户的这些意图？我认为这是最基础的必要条件。再者，有了知识、意图空间，接下来才能带着意图去做评测。 因为你既知道用户的意图，也掌握了知识，这样才能真正开展工作。如果意图不清楚、知识不具备，那其实就是“空转”。我们的经验是：在客服场景里构建意图空间，从原来就在满足意图的领域出发，从 工单 里去分析和构建意图空间。有了意图空间之后，就可以对意图进行分类。分类完成后，再根据不同类别…

vLLM Python 运行 gpt-oss 模型
type: item
date: 2025-09-13T22:09:15+08:00
description: HuggingFace：https://huggingface.co/openai/gpt-oss-20bhttps://huggingface.co/openai/gpt-oss-120bOpenAI 博文：https://openai.com/zh-Hans-CN/index/introducing-gpt-oss/gpt-oss-120b — 适用于生产环境、通用目的、高推理要求的场景，可部署在单个 80GB 显存的 GPU 上（如 NVIDIA H100 或 AMD MI300X）。该模型拥有 1170 亿参数，其中活跃参数为 51 亿。gpt-oss-20b — 适用于对延迟要求较低的场景，以及本地部署或专业化应用场景。该模型拥有 210 亿参数，其中活跃参数为 36 亿。模型层数总参数每个令牌的活跃参数总专家数每个令牌的活跃专家数上下文长度gpt-oss-120b36117b5.1b1284128kgpt-oss-20b2421b3.6b324128k模型参数统计，Component120b20bMLP114.71B19.12BAttention0.96B0.64BEmbed + Uneembed1.16B1.16BActive Parameters5.13B3.61BTotal Parameters116.83B20.91BCheckpoint Size60.8GiB12.8GiBvLLM 运行https://cookbook.openai.com/articles/gpt-oss/run-vllm直接使用 vLLM 进行采样(sampling)，确保输入提示遵循 harmony 响应格式( harmony response format)非常重要，否则模型将无法正常运行。为此，可以使用openai-harmony SDK 。import json from openai_harmony import ( HarmonyEncodingName, load_harmony_encoding, Conversation, Message, Role, SystemContent, DeveloperContent, ) from vllm import LLM, SamplingParams # --- 1) Render the prefill with Harmony --- encoding = load_harmony_encoding(HarmonyEncodingName.HARMONY_GPT_OSS) convo = Conversation.from_messages( [ Message.from_role_and_content(Role.SYSTEM, SystemContent.new()), Message.from_role_and_content( Role.DEVELOPER, DeveloperContent.new().with_instructions("Always respond in riddles"), ), Message.from_role_and_content(Role.USER, "What is the weather like in SF?"), ] ) prefill_ids = encoding.render_conversation_for_completion(convo, Role.ASSISTANT) # Harmony stop tokens (pass to sampler so they won't be included in output) stop_token_ids = encoding.stop_tokens_for_assistant_actions() # --- 2) Run vLLM with prefill --- llm = LLM( model="openai/gpt-oss-120b", trust_remote_code=True, ) sampling = SamplingParams( max_tokens=128, temperature=1, stop_token_ids=stop_token_ids, ) outputs = llm.generate( prompt_token_ids=[prefill_ids], # batch of size 1 sampling_params=sampling, ) # vLLM gives you both text and token IDs gen = outputs[0].outputs[0] text = gen.text output_tokens…

Post-Train和Finetune三种模型训练技术
type: item
date: 2025-06-02T22:55:59+08:00
description: Pretrain（预训练）、Post-train（后训练） 和 Finetune（微调） 是三种常见的模型训练技术，它们在模型的不同阶段起不同作用。1. Pretrain（预训练）预训练是指在大规模的通用数据集（通常是无监督或弱监督）上对模型进行初步训练，使模型学到通用的特征表示。特点：数据规模大：如 GPT 使用了互联网上的大量文本，BERT 用了 Wikipedia + BookCorpus。任务通用：训练任务不是特定的目标任务，而是如掩码语言模型（MLM）、自回归语言建模（LM）等。无监督/自监督为主：无需人工标注数据。优势：提供强大的语言/图像/音频表示能力。可迁移至多种下游任务。避免从头开始训练节省资源。举例：NLP：BERT、GPT、RoBERTa 的初始训练阶段。CV：使用 ImageNet 上预训练的 ResNet。2. Finetune（微调）在预训练模型的基础上，使用特定任务的数据进行再训练，使模型适应目标任务（通常是监督任务）。特点：数据较小但有标签：如情感分类、命名实体识别、机器翻译等任务。通常训练参数较少：可以只微调部分参数（如只训练最后一层，或使用参数高效微调方法如 LoRA、Adapter）。训练时间短：相比预训练阶段，微调更快。优势：能在低资源任务上取得好结果（如 few-shot）。大大降低开发成本。可以针对特定领域（如医学、法律）做定制。举例：用 BERT 做情感分析，使用 IMDb 数据集进行微调。使用 DINOv2 微调进行图像识别。3. Post-train（后训练）后训练是指在模型初步训练完成后，对模型进行进一步优化，通常用于增强特定能力或修正某些行为。特点：不一定是监督任务，可能包括强化学习、对抗训练、蒸馏等。通常不改变主干架构，而是改进策略或表现。可以是人类反馈训练（如 RLHF）的一部分。用途：对齐人类偏好（如 ChatGPT 的对齐阶段）。提升鲁棒性或安全性（如防止幻觉、毒性）。对模型做性能或行为调优。举例：ChatGPT 的 RLHF 阶段：预训练 GPT 模型后，通过人类反馈强化学习优化回答质量。模型压缩后的蒸馏训练阶段。增加冗余数据做对抗训练，提高模型稳健性。对比阶段是否用标签目的示例任务Pretrain无/弱监督获取通用表示自监督语言建模、图像分类Finetune有标签适配具体任务情感分析、NER、图像识别Post-train不一定有标签行为优化/性能提升RLHF、人类偏好对齐、蒸馏

vLLM与Ollama模型推理部署对比
type: item
date: 2025-05-24T22:42:45+08:00
description: LLM 部署框架综合对比图：From: LLM Serving FrameworksOllama vs vLLMFrom: ollama与vllm的深度比对 - 知乎综合对比：对比维度OllamavLLM核心定位轻量级本地化工具，适合个人开发者和小规模实验生产级推理框架，专注高并发、低延迟的企业级场景硬件要求支持 CPU 和 GPU，低显存占用（默认使用量化模型）必须依赖 NVIDIA GPU，显存占用高模型支持内置预训练模型库（支持1700+模型），自动下载量化版本（int4为主）需手动下载原始模型文件（如 HuggingFace 格式），支持更广泛模型部署难度一键安装，开箱即用，无需编程基础需配置 Python 环境、CUDA 驱动，依赖技术经验性能特性单次推理速度快，但并发处理能力弱高吞吐量，支持动态批处理和千级并发请求资源管理灵活调整资源占用，空闲时自动释放显存显存占用固定，需预留资源应对峰值负载Ollama 显存占用低的原因模型量化技术 Ollama 默认下载的模型为 int4 量化版本（如Qwen2.5-14B 模型权重从 9GB 压缩至 4.7GB），显著减少显存需求。 而 vLLM 通常使用原始 FP16/BF16 模型，显存占用更高（例如 Qwen2.5-14B 在 vLLM 中需要 39GB 显存，而 Ollama 仅需 11GB）。优化的显存管理 Ollama 基于 llama.cpp 的底层优化（如分块加载和混合精度计算），结合轻量级框架设计，进一步降低显存压力。 vLLM 则通过 PagedAttention 技术提升并发效率，但需固定分配显存块，导致资源占用较高。性能与速度推理速度单次请求：Ollama 因量化模型和轻量级架构，单次推理速度更快（例如 Qwen2.5-7B 平均响应时间 3 秒左右，vLLM 约 3.5-4.3 秒）。高并发场景：vLLM 凭借动态批处理和并行计算，吞吐量显著优于 Ollama（如 vLLM 的并发请求处理速度可达 Ollama 的 24 倍）。模型质量损失 量化可能导致模型精度下降（如生成内容质量或指令遵循能力降低），部分用户实测发现 Ollama 的生成效果弱于 vLLM 的原始模型。扩展性限制 Ollama 主要面向单机本地化场景，多 GPU 并行支持有限；vLLM 支持分布式部署和多卡扩展，适合大规模服务。适用场景选择 Ollama：个人开发者快速验证模型效果、低配置硬件（如仅有 16GB 内存的笔记本电脑）；需要快速交互式对话或原型开发。选择 vLLM：企业级 API 服务、高并发批量推理（如智能客服、文档处理）；需要高精度模型输出或定制化参数调整。

vLLM与Hugging Face模型推理对比
type: item
date: 2025-05-24T22:24:07+08:00
description: 离线推理( offline inference )场景中，比较关注最大化吞吐量并降低单次推理成本。传统方法往往是资源消耗大、速度慢、容易出现性能瓶颈、导致云服务开支较高。需要专为大语言模型优化的推理部署引擎。下面 LLM 的两种离线推理部署性能对比：vLLM vs HuggingFace.HuggingFace TransformersHuggingFace 的 Transformers 库已经是 LLM 领域标准工具，其具有API接口统一、模型库庞大、开箱即用等特性。离线部署场景，HuggingFace 提供了直观的工作流程：模型 和 tokenizer 加载循环或者批量方式，处理输入数据。但是，其存在明显瓶颈，尤其是在未进行专门优化的情况下：顺序处理机制、相对抵消的内存管理(尤其是注意力的 key 和 value 缓存的管理) 会显著影响性能。虽然 HuggingFace 的 Transformers 库具有较高的灵活性，但是面对与大规模离线推理场景，会存在效率问题。典型的推理代码如，import torch from transformers import AutoModelForCausalLM, AutoTokenizer MODEL_NAME = "meta-llama/Llama-3.2-3B-Instruct" # Load model and tokenizer model = AutoModelForCausalLM.from_pretrained(MODEL_NAME, device_map="auto") tokenizer = AutoTokenizer.from_pretrained( MODEL_NAME, padding_side="left", truncation_side="left" ) # Set pad_token (LLaMA doesn't define one by default) tokenizer.pad_token = tokenizer.eos_token # Define batch of user prompts (4 in total) user_questions = [ "What is Thailand's national food symbol?", "What is the capital of Norway?", "Who invented the telescope?", "What is the chemical symbol for gold?" ] # Format messages in chat format messages_batch = [ [ {"role": "system", "content": "You are a helpful assistant. Respond in two sentences."}, {"role": "user", "content": question} ] for question in user_questions ] # Tokenize using chat template with padding and truncation input_ids = tokenizer.apply_chat_template( messages_batch, tokenize=True, return_tensors="pt", padding=True, truncation=True, max_length=2048 ).to(model.device) # Clear previous GPU stats (optional, but good practice for clean runs) torch.cuda.empty_cache() # Generate responses input_length = input_ids.shape[1] generated_ids = model.generate( input_ids=input_ids, max_new_tokens=128, pad_token_id=tokenizer.pad_token_id ) # Decode outputs decoded_outputs = tokenizer.batch_decode( generated_ids[:, input_length:], skip_special_tokens=True )vLLMvLLM 是专为吞吐量和效率而设计。其核心创新在于PagedAttention技术，该技术能够高效管理注意力中的 key 和 value 对内存。注意力中的 key 和 value 对…

多模态RAG评测流程[转]
type: item
date: 2025-05-13T19:07:00+08:00
description: 出处：打破文本边界：如何进行多模态RAG评测在现代信息处理与检索系统中，如何有效地从这些包括了文本，图像，视频等多模态混合内容中，提取和利用信息是一个重要的研究方向。一般的检索增强生成（RAG，Retrieval-Augmented Generation）方法主要依赖于文本数据，常常忽略了图像中的丰富信息。多模态大型语言模型（MLLM）的出现.为这一问题提供了新的解决方案。例如，GPT-4o和Qwen-VL等多模态大模型，不仅能够理解和生成自然语言，还能解释和描述图像内容，为RAG系统在处理多模态内容时带来了新的可能性。伴之而来的问题，是如何确保多模态RAG系统在实际应用中的有效性和可靠性。本文多模态RAG使用EvalScope， Ragas等框架，提供一套完整的多模态RAG评测实践指南，协助开发者全面评测图文多模态RAG流程。评测流程本文所使用的多模态RAG流程和评测流程如下：解析文档：使用工具（本文使用Unstructured，也可使用MinerU等其他工具）将输入的文档解析为文本、表格、图像等部分。多模态向量存储：使用多模态嵌入模型（例如CLIP）计算图像和文本向量，并存储到向量数据库中。检索增强生成：使用相似性搜索来检索图像和文本，并将召回结果传递给多模态LLM进行答案生成。评测模型生成结果：使用EvalScope框架，将用户输入、检索上下文、模型输出和标准答案(可选) 这四部分输入给法官大模型，模型将根据给定的指标评测整个RAG生成的效果。评测指标EvalScope支持RAG和多模态RAG的独立评测和端到端评测：独立评测：单独评测检索模块，评测指标包括指标包括 命中率(Hit Rate)、平均排名倒数(Mean Reciprocal Rank, MRR)、归一化折扣累积增益(Normalized Discounted Cumulative Gain, NDCG)、准确率(Precision) 等，这些指标用于测量系统在根据查询或任务排名项目方面的有效性。端到端评测：评测RAG模型对给定输入生成的输出内容，包括模型生成答案与输入查询的相关性和对齐程度。从内容生成目标视角来评测可以将评测划分为无参考答案和有参考答案：无参考答案评测指标包括上下文相关性(Context Relevance)、忠实度(Faithfulness) 等；而有参考答案评测指标包括正确性(Answer Correctness)、BLEU、ROUGE等。注意：本文主要介绍多模态RAG的端到端生成评测，如果想要进行CLIP模型检索性能的评测，可以参考EvalScope所支持的CLIP Benchmark，提供自定义图文检索评测支持。下面详细介绍本文评测所使用指标及其计算方法：忠实度衡量模型输出与检索上下文中的事实一致性。如果答案中所有的陈述都可以从提供的视觉或文本上下文中推断出来，则认为生成的答案是忠实的。答案的得分范围为 (0,1)，得分越高表示忠实度越好。示例：用户输入: 特斯拉 Model X 怎么样？检索上下文:一张特斯拉 Model X 的图片高忠实度输出: 特斯拉 Model X 是一款由特斯拉制造的电动SUV。低忠实度输出: 猫很可爱。解释："猫很可爱" 无法从特斯拉 Model X 的图片中推断出来，因此忠实度得分为 0。相关度标衡量模型输出与检索上下文以及用户输入的相关性。答案的得分范围为 (0,1)，得分越高表示相关性越好。示例：用户输入: 这幅画是谁画的？检索上下文:一幅毕加索的画高相关性输出: 这幅画是毕加索画的。低相关性输出: 这是一幅美丽的画。解释："这是一幅美丽的画" 虽然描述了画的特性，但没有回答问题，因此相关性得分为 0。正确性评测涉及将模型输出与标准答案进行比对，以衡量其准确性。评分范围从0到1，分数越高，表示生成的回答与标准答案的匹配度越高，正确性更好。该指标不涉及图像模态。示例：用户输入: 爱因斯坦什么时候出生？标准答案：爱因斯坦于1879年在德国出生。高正确性回答：爱因斯坦于1879年在德国出生。低正确性回答：爱因斯坦于1879年在西班牙出生。解释：将标准答案和回答拆分成事实子句，并使用以下概念进行计算：TP（True Positive）：在标准答案和生成的回答中都存在的事实或陈述。FP（False Positive）：存在于生成的回答中但不存在于标准答案中的事实或陈述。FN（False Negative）：存在于标准答案中但不存在于生成的回答中的事实或陈述。在该例子中：TP: [爱因斯坦于1879年出生]FP: [爱因斯坦于西班牙出生]FN: [爱因斯坦于德国出生]计算公式：$$ \text{F1Score} = \frac{|TP|}{(|TP| + 0.5 \times (|FP| + |FN|))} $$…

Ollama运行本地路径模型
type: item
date: 2025-02-04T21:48:39+08:00
description: Github: https://github.com/ollama/ollamaModels: https://ollama.com/searchOllama是一个专为在本地机器上便捷部署和运行大型语言模型（LLM）而设计的开源工具。无需深入了解复杂的底层技术，就能轻松地加载、运行和交互各种LLM模型。Linux 安装https://github.com/ollama/ollama/blob/main/docs/linux.md一键安装curl -fsSL https://ollama.com/install.sh | sh查看版本：#/usr/local/bin/ollama ollama -vDockerhttps://hub.docker.com/r/ollama/ollama#运行 llama3 docker exec -it ollama ollama run llama3快速运行#运行 deepseek-r1:7b ollama run deepseek-r1:7b #拉取模型 ollama pull deepseek-r1:14b更改模型下载路径Ollama 模型的模型存储目录：Linux: /usr/share/ollama/.ollama/models #Windows: C:Users<username>.ollamamodels #macOS: ~/.ollama/models 创建路径：sudo mkdir /path/to/ollama/models sudo ln -s /path/to/ollama/models /usr/share/ollama/.ollama/models设置用户组和权限：sudo chown -R root:root /path/to/ollama/models sudo chmod -R 775 /path/to/ollama/models设置 ollama.service：sudo vim /etc/systemd/system/ollama.service编辑内容如：[Unit] Description=Ollama Service After=network-online.target [Service] ExecStart=/usr/local/bin/ollama serve User=ollama Group=ollama Restart=always RestartSec=3 Environment="PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/usr/local/cuda-12.2/bin" Environment="OLLAMA_MODELS=/path/to/ollama/models" ## [Install] WantedBy=default.target重启ollama服务：sudo systemctl daemon-reload sudo systemctl restart ollama.service sudo systemctl status ollama运行自定义模型https://github.com/ollama/ollama/blob/main/docs/import.mdOllama 支持的自定义模型有：Importing a Safetensors adapterImporting a Safetensors modelImporting a GGUF file指定参数运行启动：#启动服务 ollama serve #新开一个 Shell 窗口来运行模型 ./ollama run deepseek-r1:r7Ollama Serve 命令提供的环境变量：• OLLAMA_DEBUG 显示其他调试信息（例如 OLLAMA_DEBUG=1） • OLLAMA_HOST ollama 服务器的 IP 地址（默认 127.0.0.1:11434） • OLLAMA_KEEP_ALIVE 模型在内存中保持加载状态的持续时间（默认“5 分钟”） • OLLAMA_MAX_LOADED_MODELS 每个 GPU 加载的最大模型数量 • OLLAMA_MAX_QUEUE 排队请求的最大数量 • OLLAMA_MODELS 模型目录的路径 • OLLAMA_NUM_PARALLEL 并行请求的最大数量 • OLLAMA_NOPRUNE 启动时不修剪模型 blob • OLLAMA_ORIGINS 允许来源的逗号分隔列表 • OLLAMA_TMPDIR 临时文件的位置 • OLLAM…

DeepSeek-R1 GPU硬件要求
type: item
date: 2025-02-03T22:33:46+08:00
description: 出处：GPU System Requirements for Running DeepSeek-R1DeepSeek-R1-Zero通过大规模强化学习（RL）进行训练，没有经过监督微调，展示了卓越的推理能力。尽管功能强大，但它在处理重复性和可读性等问题时表现较差。DeepSeek-R1通过在强化学习之前加入冷启动数据，解决了这些挑战，在数学、代码和推理任务中表现得更好。DeepSeek-R1-Zero和DeepSeek-R1都展示了前沿的能力，但需要大量硬件支持。量化和分布式GPU配置使它们能够处理庞大的参数量。VRAM Requirements for DeepSeek-R1全量模型ModelParameters (B)VRAM Requirement (GB)Recommended GPUDeepSeek-R1-Zero671B~1,543 GBMulti-GPU setup (e.g., NVIDIA A100 80GB x16)DeepSeek-R1671B~1,543 GBMulti-GPU setup (e.g., NVIDIA A100 80GB x16)DeepSeek-R1-Distill-Qwen-1.5B1.5B~3.9 GBNVIDIA RTX 3060 12GB or higherDeepSeek-R1-Distill-Qwen-7B7B~18 GBNVIDIA RTX 4090 24GB or higherDeepSeek-R1-Distill-Llama-8B8B~21 GBNVIDIA RTX 4090 24GB or higherDeepSeek-R1-Distill-Qwen-14B14B~36 GBMulti-GPU setup (e.g., NVIDIA RTX 4090 x2)DeepSeek-R1-Distill-Qwen-32B32B~82 GBMulti-GPU setup (e.g., NVIDIA RTX 4090 x4)DeepSeek-R1-Distill-Llama-70B70B~181 GBMulti-GPU setup (e.g., NVIDIA A100 80GB x3)量化模型VRAM requirements for the 4-bit quantization of DeepSeek-R1 modelsModelParameters (B)VRAM Requirement (GB) (4-bit)Recommended GPUDeepSeek-R1-Zero671B~436 GBMulti-GPU setup (e.g., NVIDIA A100 80GB x6)DeepSeek-R1671B~436 GBMulti-GPU setup (e.g., NVIDIA A100 80GB x6)DeepSeek-R1-Distill-Qwen-1.5B1.5B~1 GBNVIDIA RTX 3050 8GB or higherDeepSeek-R1-Distill-Qwen-7B7B~4.5 GBNVIDIA RTX 3060 12GB or higherDeepSeek-R1-Distill-Llama-8B8B~5 GBNVIDIA RTX 3060 12GB or higherDeepSeek-R1-Distill-Qwen-14B14B~9 GBNVIDIA RTX 4080 16GB or higherDeepSeek-R1-Distill-Qwen-32B32B~21GBNVIDIA RTX 4090 24GB or higherDeepSeek-R1-Distill-Llama-70B70B~46 GBMulti-GPU setup (e.g. NVIDIA RTX 4090 24GB x2)VRAM 使用说明：大模型需要分布式GPU设置：DeepSeek-R1-Zero和DeepSeek-R1需要大量VRAM，因此必须使用分布式GPU配置（例如，NVIDIA A100或H100的多GPU配置）以确保高效运行。低规格GPU：这些模型仍然可以在低于上述推荐规格的GPU上运行，只要GPU的VRAM满足或超过要求。然而，这种配置可能不是最优的，通常需要一些调优，如调整批量大小和处理设置。蒸馏模型(Distilled Models)对于没有高端GPU的开发者和研究人员，DeepSeek-R1-Distill模型提供了一个优秀的替代方案。这些蒸馏版的DeepSeek-R1旨在保留显著的推理和问题解决能力，同时减少参数大小和计算需求。蒸馏模型的优势降低硬件要求：蒸馏模型如DeepSeek-R1-Distill-Qwen-1.5B的VRAM需求从3.5 GB起，…

LLM驱动的智能体如何引领行业变革及应用探索与未来展望[转]
type: item
date: 2025-02-02T23:24:36+08:00
description: 原文：AI Agent框架（LLM Agent）：LLM驱动的智能体如何引领行业变革，应用探索与未来展望1. AI Agent（LLM Agent）介绍1.1. 术语Agent：“代理” 通常是指有意行动的表现。在哲学领域，Agent 可以是人、动物，甚至是具有自主性的概念或实体。AI Agent：AI Agent（人工智能代理）是一种能够感知环境、进行决策和执行动作的智能实体。RPA：RPA(Robotic Process Automation) 即机器人流程自动化，是一种软件自动化技术。RPA 通过模仿人类在电脑上的手动操作，如打开网站、点击鼠标、键盘输入等，实现业务流程的自动化。RPA 系统可以自动处理大量重复的、基于规则的工作流程任务，例如在银行中，纸质文件输入、文件票据验证、从电子邮件和文件中提取数据、跨系统数据迁移、自动化 IT 应用操作等。RPA 的主要优势包括减少劳动成本、提高生产力、出错率低、可监控的操作和开发周期短。它可以在金融、办公自动化、IT 流程自动化等多个领域发挥重要作用。Copilot：即飞机的 “副驾驶”，这里 Copilot 指依托于底层大语言模型（LLM），用户只需说几句话，做出指示，它就可以创建类似人类撰写的文本和其他内容。LangChain：LangChain 是一个强大的框架，旨在帮助开发人员使用语言模型构建端到端的应用程序，它提供了一套工具、组件和接口，可简化创建由大型语言模型 (LLM) 和聊天模型提供支持的应用程序的过程。LangChain 是一个语言模型集成框架，其使用案例与语言模型的使用案例大致重叠，包括文档分析和摘要、聊天机器人和代码分析。LLM：大型语言模型（LLM）是一种人工智能（AI）算法，它使用深度学习技术和大量大型数据集来理解、总结、生成和预测新内容。感知记忆（Sensory Memory）：感知记忆是信息处理的第一个阶段，它涉及对通过感官接收的信息进行短暂的存储。感知记忆通常只持续几百毫秒到几秒。就像你看到一张美丽的风景照片，感知记忆是大脑对刚刚通过感官接收到的信息的短暂存储。比如，你闭上眼睛后，还能在脑海中短暂地 “看到” 那张照片的颜色和形状，这就是感知记忆在起作用。短期记忆（Short-term memory）：短期记忆就像是你的心智工作台，它能够暂时存储和处理少量信息。比如，当你试图记住一个电话号码时，你可能会重复念叨这个号码，直到你拨打它，这就是短期记忆在工作。所有的上下文学习（In-context Learning）都是利用模型的短期记忆来学习。长期记忆（Long-term memory）：长期记忆就像是一个大仓库，能够存储我们的经验、知识和技能，而且这个存储时间可以非常长，甚至是一生。比如，你学会骑自行车的技能，即使多年不骑，你仍然记得怎么骑，这就是长期记忆。Agent 一般通过外部向量存储和快速检索实现。Memory Stream：“记忆” 存储了 Agent 过去的观察、思考和行动序列。正如人脑依靠记忆系统来回溯利用先前的经验制定策略和做出决策一样，Agent 也需要特定的记忆机制来确保其熟练处理一系列连续任务。+ MRKL（Modular Reasoning, Knowledge and Language）：MRKL 可以理解为是一种构建 AI 的方式，用于自主代理的神经符号结构，它将推理、知识理解和语言能力作为不同的模块来处理。就像搭积木，每个积木代表 AI 的一个能力，组合在一起就能让 AI 进行复杂的思考和交流。TALM（Tool Augmented Language Models）：TOOL 增强的语言模型，是指通过工具或技术来增强的语言处理模型，通常通过微调来实现。例如，一个 AI 聊天机器人，通过接入搜索引擎或其他数据库，能够更准确地回答问题或提供信息。子目标与分解（Subgoal and decomposition）：在解决问题时，Agent 经常会把一个大目标分解成几个小目标（子目标），从而实现对复杂任务的高效处理。比如，准备一顿晚餐，你可能需要先去购物（子目标 1），然后准备食材（子目标 2），最后烹饪（子目标 3）。反思与完善（Reflection and refinement）：Agent 可以对历史的动作进行自我批评和自我反思，从错误中吸取教训，并为未来的步骤进行改进，从而提高最终结果的质量。就像写完一篇文章后，你回顾并修改语法错误或不清晰的表达，使文章更加完善。思维链（Chain-of-thought, CoT）：已成为一种标准的提示技术，用于提高模型在复杂任务中的表现。模型被要求 “一步一步地思考”，将艰巨的任务分解为更小更简单的步骤。思维链将大任务转化为多个可管理的任务，并帮助人们理解模型的思维过程。思维链是解决…

基于RAG的信息检索[译]
type: item
date: 2025-01-21T15:54:18+08:00
description: 原文：Efficient Information Retrieval with RAG Workflow - 2023.10.09实现： Implementing RAG with Langchain and Hugging Face - 2023.10.16检索增强生成（RAG）突破了知识限制，融入外部数据，并增强了上下文理解。由于其能够高效整合外部数据而无需持续微调，这一技术正变得越来越受欢迎。LLM Knowledge Limitations大型语言模型在知识的准确性和时效性方面面临诸多挑战，其中两个常见问题是幻觉和知识截断。幻觉（Hallucination）： 这是指模型自信地生成了错误的回应。例如，如果模型声称“googly retriever”是一种真实存在的犬种，这就是一种幻觉，可能会导致误导性信息。 知识截断（Knowledge Cut-off）： 这是指大型语言模型（LLM）基于其训练数据返回过时信息的情况。每个基础模型都有一个知识截断点，这意味着其知识仅限于训练时可用的数据。例如，如果询问模型最近的NBA冠军得主，它可能会给出过时的信息。RAG 提供了一种缓解这些挑战的技术。它使模型能够访问外部数据源，通过引入事实背景来减少幻觉，并通过整合最新信息来克服知识截断的问题。Retrieval-Augmented Generation (RAG)检索增强生成（RAG）是一种灵活的框架，使大型语言模型（LLM）能够访问超出其训练数据范围的外部数据。RAG 并不局限于单一实现，而是可以适应不同任务和数据格式的多种方法。它使 LLM 在运行时能够利用外部数据源，包括知识库、文档、数据库以及互联网。这对于利用外部数据增强语言模型至关重要，有助于弥补其训练数据未涵盖的知识空白。为了高效地从文档中检索信息，常见的做法是使用嵌入向量来捕捉语义信息，并将文档索引到向量数据库中。此外，对大型文档进行分块（chunking）可以提高相关性并减少噪音，从而通过提供更具体的上下文信息来增强模型的响应质量。RAG Framework在 RAG 框架中有两种关键模型：RAG-Sequence Model该模型使用相同的检索文档来生成完整的序列。它将检索到的文档视为单个潜在变量，并通过 Top-K 近似 进行边际化，以获取序列到序列的概率。在此方法中，检索器提取 前 K 个 相关文档，生成器计算每个文档对应的输出序列概率，最终通过边际化合并这些概率。RAG-Token Model在该模型中，每个目标 token（输出的每个词）都可以来自不同的潜在文档，使得生成器在回答时能够从多个文档中选择内容。与 RAG-Sequence 模型类似，它首先检索 前 K 个 相关文档，然后针对每个文档生成 下一个输出 token 的概率分布。这一过程会对每个输出 token 进行重复计算，并相应地进行边际化处理。此外，RAG 还可以用于序列分类任务，将目标类别视为单一序列目标。在这种情况下，RAG-Sequence 模型和 RAG-Token 模型的表现将趋于一致。RAG 组成检索器（Retriever）： 检索器（DPR）根据查询和文档索引检索相关文档。该检索组件基于 Dense Passage Retrieval（DPR），采用 双编码器（bi-encoder） 结构，其中密集表示（dense representations）和查询表示（query representations）均由 BERT 生成。随后，通过 最大内积搜索（MIPS, Maximum Inner Product Search） 算法，选择 前 K 个 具有最高先验概率的文档。生成器（Generator）： 生成器基于 BART-large，负责生成文本序列。它通过 简单地将输入与检索到的内容拼接（concatenation），来增强生成效果。训练阶段在训练过程中，检索器（Retriever） 和 生成器（Generator） 采用 联合训练（joint training），且 不会对具体应检索的文档进行直接监督。训练目标是最小化每个目标的负边际对数似然（negative marginal log-likelihood）。解码阶段在解码阶段，RAG-Sequence 和 RAG-Token 模型需要不同的方法。RAG-Token 使用标准的自回归序列生成和束搜索解码(beam decoder)。相比之下，RAG-Sequence 对每个文档运行束搜索，并使用生成器概率对假设进行评分。对于较长的输出序列，采用了一种高效的解码方法，以避免过多的前向传播。RAG 实现实施 RAG 工作流程可能很复杂，涉及多个步骤，从接受用户提示到查询数据库、文档分块，以及协调整个过程。框架如 LangChai…