kimi-222-CSDN博客

原创多轮对话历史管理

需求实现方式多用户隔离自动过期ttl=86400参数限制轮数继承LTRIM生产部署用长期记忆额外将问答存入 FAISS/Milvus建议：短期会话用 LangChain + Redis；长期语义记忆用 RAG + 向量库。两者互补！# 截断：只保留最近 max_messages 条。

2026-01-18 00:09:30 555

在自回归模型（如Transformer解码器）中，生成文本时是逐个token进行的。每次生成新token时，注意力机制需要计算当前token与之前所有token之间的关系，这涉及大量的矩阵运算。由于计算复杂度随序列长度增长而急剧上升（例如，预测第1001个token时需处理1000×1000的QK矩阵），效率会显著下降。：KV Cache是一种“用内存换取速度”的优化技巧，通过存储历史K和V的计算结果，避免在每一步都重新计算整个注意力矩阵，显著提升了自回归模型的推理效率。为提升推理速度，引入了。

2026-01-06 15:11:35 484

原创 Accelerate 是由 Hugging Face 开发的一个轻量级 Python 库，旨在让 PyTorch 的分布式训练变得极其简单

传统 DDP使用 Accelerate需写一行全搞定多进程启动需torchrun或mp.spawn直接混合精度、梯度累积代码复杂参数化配置即可保存模型需处理module.前缀自动处理accelerate= PyTorch 分布式训练的“胶水层”它不改变你的训练逻辑，只帮你自动处理设备、并行、精度、同步等底层细节，让你专注模型和算法本身。

2026-01-05 23:34:48 1188

原创 LLM多卡并行计算：Accelerate、DeepSpeed

需求推荐方案快速微调 7B 模型全量训练 13B+ 模型极限显存压缩企业级生产训练最佳实践组合DeepSpeed（训练） + vLLM（推理） + LoRA（微调）实现从训练到部署的全链路高效闭环。

2026-01-05 01:28:15 616

原创大模型推理model.generate()+tokenizer.decode() 、model(**input)

问题能不能直接得到“故事结尾”？能不能（只得到当前输入的预测）能不能控制每一步采样？有限（依赖 generate 参数）完全可控能不能用于训练？不能可以（配合 labels 计算 loss）性能开销较高（多次前向）较低（单次前向）方法功能输入输出是否涉及GPU计算完整生成：一次性生成多token文本是单步推理：计算一次前向传播Logits(概率分布)是文本转换：将token ID转成文本字符串(String)否（CPU操作）

2026-01-03 22:29:43 285

原创 DataCollator

这样既利用了 HF 的高效 padding，又确保 loss 只在 assistant 回复上计算。（如 T5、BART、Flan-T5、Qwen2-VL 的文本部分）设计。，然后仍可用此 collator（因它会保留已有 labels），将 user/system 部分设为。通用 padding 工具，适用于。"user\n你好"

2026-01-03 22:25:09 939

原创 tokenizer.apply_chat_template()

是 Hugging Face 库中用于将对话历史（messages）格式化为模型可接受的输入文本的关键方法，尤其在使用 Chat 模型（如 Qwen、Llama-3、ChatGLM、Phi-3 等）时必不可少。将结构化的对话列表（如）→ 转换为模型训练/推理时使用的带特殊 token 的字符串（如）。输出示例（Qwen3 格式）：关键参数说明参数类型说明对话历史，每个 dict 含（user

2026-01-03 20:44:52 303

原创模型量化（Quantization）、推理时的反量化（Dequantization）以及显存使用动态性

问题答案int4 模型反量化成 float16 会不会爆显存？不会，因为反量化是临时、分块、按需的显存主要被什么占用？激活值、KV Cache、临时计算缓冲区，不是全量权重为什么 int4 能在小显存跑大模型？存储省 75%，计算时只临时展开小块Ollama / llama.cpp 如何做到的？GGUF + 高效分块反量化 + 内核优化int4 加载 → 推理时局部反量化 → 显存依然满足。如果你用的是 8GB 显卡跑，这正是量化 + 优化推理引擎带来的红利！

2026-01-03 00:34:36 773

原创在 Hugging Face Transformers 库中，AutoModel 及其变体

类别模型架构典型任务输出头示例模型AutoModel任意特征提取无编码器 or 编码器-解码器文本分类分类头解码器 only自回归生成LM 头（因果）编码器-解码器序列生成（翻译/摘要）LM 头（非因果，decoder侧）T5, BART。

2025-12-31 13:01:33 636

原创 Transformer 模型中位置编码（Positional Encoding, PE）

表示：对输入序列加上了对应位置编码，并保留原始 shape。

2025-12-29 23:23:42 526

原创 RAG-语义切片 +混合检索（BM2.5、向量）+ 多查询检索

技术作用价值语义切片提升上下文连贯性中文专用模型本地部署，性能好Milvus向量数据库支持亿级扩展混合检索兼顾关键词与语义查询扩展提升召回率整体架构属于“现代 RAG 三阶优化”语义切片（预处理）混合检索（召回）多查询扩展（增强召回）

2025-12-28 17:27:15 899

原创 LangChain 中不同方式的检索增强

组件类型是否依赖 LLM主要作用优势局限稀疏关键词检索否精确关键词匹配快速、可解释无语义理解混合检索框架否（但可集成 LLM 检索器）融合多种检索结果兼顾精度与泛化需调权重、去重查询扩展增强器是扩展用户查询，提升召回解决模糊查询依赖 LLM 成本/质量。

2025-12-28 12:18:48 588

原创基于 LangChain 的 RAG（检索增强生成）

方式特点适用场景简单快捷，一键完成快速原型、学习演示手动构建 RAG 链控制力强，可调试，支持复杂逻辑生产环境、需要溯源、优化性能。

2025-12-27 13:19:08 416

原创 LangChain 将数据加载到 Chroma 向量数据库

特性from_texts输入类型List[str]元数据支持需通过metadatas参数传入自动从提取适用场景简单文本，快速原型使用 LangChain 加载器后的标准流程是否推荐用于生产较少（除非数据简单）推荐（结构清晰，可扩展性强）

2025-12-27 13:09:59 265

原创 LangChain 中的文档加载器和文本分割器

【代码】LangChain 中的文档加载器（PyMuPDFLoader）和文本分割器（RecursiveCharacterTextSplitter）来处理 PDF 文档。

2025-12-27 00:27:37 317

原创 LLM 生成 → 输出 Markdown 文本

只需粘贴你的 Markdown 文本，即可下载为 Excel/CSV/HTML 格式。这样既利用了 LLM 的生成能力，又保证了数据的结构化和可操作性。生成的 HTML 可直接用于 Web 页面渲染。只需要确保格式正确（列对齐行。存在），就会自动显示为表格。进阶处理：确保数据类型正确。

2025-12-26 21:35:04 275

原创 llm.with_structured_output

是 LangChain 中一个非常强大且便捷的方法，用于强制大模型输出符合特定格式的数据（如 JSON、Pydantic 对象），而不是返回普通的文本字符串。该方法会在底层通过以下两种方式之一工作（取决于模型支持情况）：这是最常用、最健壮的方式。利用 Pydantic 进行数据校验，能确保类型正确（例如金额必须是，日期必须是）。步骤：代码示例：3. 进阶用法：处理复杂结构 (嵌套与列表)在招投标场景中，往往需要提取一个列表（例如：评分表中的多条明细，或多个产品清单）。Pydantic 完美支持

2025-12-26 20:41:21 333

原创 LangGraph 流式处理（streaming）

工具@tool"""获取城市天气"""return f"{city}今天晴，25°C"# 节点return {# 构建图。

2025-12-25 17:32:33 281

原创 langgraph 构建一个带工具调用的简单 Agent 工作流

HumanMessage(content='今天上海的天气怎么样?', additional_kwargs={}, response_metadata={}, id='ef338c50-e6bf-4726-887e-7c4ad8699726')LangChain 的。

2025-12-25 11:25:33 235

原创 create_tool_calling_agent中采用ConversationBufferMemory

功能上：没有任何区别，只是名字不同。建议如果你正在构建新的 LCEL 应用，或者参考最新的 LangChain 文档，推荐使用 chat_history，因为它语义更清晰（明确表示是聊天消息列表）关键配置。

2025-12-23 17:37:39 336

原创 create_tool_calling_agent、create_react_agent区别

如果你使用的是 GPT-3.5/4、Claude 3 等先进模型：请优先使用。它是现代的标准，错误率更低，体验更好。如果你使用的是早期的开源模型（如 Llama-2, Vicuna）或者模型不支持 API 级别的工具调用：你需要使用（或者），通过提示词技巧来强制模型调用工具。

2025-12-23 16:45:10 964

原创对比ConversationBufferMemory、InMemoryChatMessageHistory

特性所属库（旧）（新）输出格式字符串（默认）或消息始终是消息列表推荐程度⚠️ 已弃用✅ 官方推荐配合方式持久化不支持不支持# 1. 初始化模型# 2. 定义输入 schema"""计算加法的输入参数"""a: int = Field(description="第一个数字")b: int = Field(description="第二个数字")# 3. 定义工具"""计算二数之和"""# 使用 StructuredTool 创建工具description="计算二数之和。

2025-12-23 16:37:46 1026

原创短期记忆中ChatMessageHistory()、 InMemoryChatMessageHistory()区别

ChatMessageHistory() 、 InMemoryChatMessageHistory()区别

2025-12-23 15:09:47 279

原创 LangChain 中创建 Agent（智能体）方法

和是 LangChain 中用于创建的两个不同函数，它们代表了。

2025-12-22 21:14:16 1099

原创 LangChain 框架-短期记忆能力

是 LangChain 中实现短期对话记忆的最简单方式，适用于单次会话内的上下文保持。只需几行代码，就能让 AI 记住你说过的话！控制历史长度→ 用节省 token→ 用多用户持久化→ 用。

2025-12-22 11:26:33 370

原创 LangChain 框架-长期记忆能力

特性Redis 示例MySQL 示例存储类型内存数据库（快速读写）关系型数据库（结构化、持久）适用场景缓存、实时性强的应用需要事务、备份、审计的场景部署要求安装 Redis 服务安装 MySQL 并配置权限扩展性易于集群扩展支持主从复制、分库分表数据结构简单键值对表格形式，支持 JOIN 查询自动建表❌✅（首次运行时自动创建）通过结合或，可以在 LangChain 中轻松实现基于会话的长期记忆功能，让大模型具备持续对话的能力，并根据实际需求选择合适的后端存储方案。

2025-12-22 10:49:58 1116

原创 llm.invoke() 的输入类型详解

输入类型是否支持说明字典（dict）推荐最常用，用于填充模板变量字符串（str）支持当链的第一个组件是LLM或Runnable且不需要变量时列表（list）特定场景如多轮对话消息列表其他对象有限支持必须被转换为可处理格式链的第一个组件推荐输入类型示例字典（dict）LLM（非聊天）字符串（str）"你好"ChatModel消息列表（List[BaseMessage]）字符串"hello"字符串（JSON）"{\"name\": \"张三\"}"问题答案只能传字典吗？不是，但。

2025-12-22 00:23:40 414

原创 LangChain 中少样本提示（Few-shot Prompting）

少样本提示（Few-shot Prompting）是一种通过在提示中提供少量“输入-输出”示例（即“few-shot examples”），来引导大语言模型（LLM）按照指定风格或逻辑回答新问题的技术。特性（文本）（聊天）适用模型OllamaLLMOpenAI非聊天接口ChatOllamaChatOpenAI输入类型str格式化方法.format()示例格式是否支持角色不支持支持 system/human/ai若只需简单问答 → 使用若需多轮对话 → 使用。

2025-12-21 17:03:54 746

原创提示模板与大模型交互

模型类型推荐输入格式对应模板类BaseLLM（如OllamaLLMstr或（如ChatOllama或最佳实践不要混用：不要把列表传给，会报错。统一接口：若不确定模型类型，可通过让 LangChain 自动处理转换。

2025-12-21 16:29:34 702

原创 LangChain 中 Prompt 模板

用于构建多轮对话式提示（聊天格式）：用于构建简单的文本提示模板两者都支持变量填充和参数化处理，但适用场景不同。专为聊天机器人设计，遵循通用聊天消息格式（如 OpenAI API 格式）。每条消息必须包含role和content字段。支持多轮对话结构，适合复杂交互任务。适用于单次文本提示，不涉及对话历史。支持变量插值{variable}，可动态替换内容。可显式声明变量，也可自动推断。特性用途多轮对话、聊天场景单次文本提示必需字段rolecontent仅template支持角色。

2025-12-21 11:40:13 682

原创大模型后训练阶段常用的三种关键技术

维度SFTRL对抗训练数据需求高质量标注数据奖励函数/偏好对原始数据 + 梯度计算泛化能力弱（易记忆）强（可迁移策略）局部鲁棒，语义泛化有限训练稳定性高中~低（依赖超参）中（可能降低主任务性能）计算成本低~中高（需环境交互）中（需额外前向/反向）适用任务单步、确定性任务多步、决策性任务安全/鲁棒性敏感任务GRPO 是 RLHF 范式的一次重要演进利用组内相对偏好替代绝对奖励；简化训练流程，减少超参依赖；提升样本效率与稳定性；成为SFT → GRPO。

2025-12-21 11:14:21 578

原创调用大模型的方式

适合企业级应用或需要高并发的服务。推荐用于简单问答场景。

2025-12-21 01:58:13 391

原创三种调用 ChatOllama 的方式

调用方式输入类型是否支持 System PromptLangChain 标准消息适用场景1. 元组列表支持非标准对象快速原型、简单脚本2. 消息对象列表支持完全兼容LangChain 工作流（Agent/Memory/Tool）3. 纯字符串"上海最推荐的地方"str不支持自动包装为最简测试。

2025-12-20 23:10:37 277

原创 python多线程和多进程

多线程适合 I/O 密集型任务和轻量级任务。共享资源，通信开销低。受 GIL 限制，不适合 CPU 密集型任务。多进程适合 CPU 密集型任务和需要高隔离性的任务。独立资源，通信开销高。可以充分利用多核 CPU，不受 GIL 限制。chunksize参数是中一个重要的性能调优参数。通过合理设置chunksize，你可以减少调度开销，更好地平衡负载，从而提高多进程并行执行的效率。对于不同的任务和数据量，最佳的chunksize值可能会有所不同，因此建议通过实验来确定最优值。

2025-03-18 14:05:33 936