xhj的博客

什么是 RAG？AI 大模型有一些硬伤，比如： 知识有截止日期 会一本正经地胡说八道，也就是我们常说的幻觉 缺乏私有知识，了解不到内部的文档写了什么 比如问 DeepSeek：程序员鱼皮的最新项目是什么？ 结果它给我扯了个两年半以前的项目出来，技术栈也完全不对！ 解决这个问题就可以用 RAG。RAG 的核心思想是 先搜再答 ，让大模型在回答之前先去搜一遍相关资料，再基于搜到的知识来组织答案。 就跟考试的时候偷偷翻书一样，遇到不会的先翻一翻书，再根据书里的知识答题。 还是问 AI 同样的问题，我们主动给 AI 一些参考资料，他的回答就会准确一些： 这个思路听起来简单，但在实际工程上 RAG 已经演化出了很多种不同的实现方法，从最初的「切块 → 搜索 → 生成」，到让 AI Agent 自主决策检索策略的 Agentic RAG，复杂度和能力天差地别。 有朋友可能会问：现在的大模型不是已经支持百万 token 的上下文窗口了，还需要 RAG 吗？ 答案是：需要，而且用得比以前更多了！ 因为把所有文档塞进上下文窗口，既贵又不靠谱。上下文越长 token 费用越高，而且大模型普遍存在...

15. Python 版本 MVP 范围1. 目标避免 Python 版本一开始就无限扩张。MVP 只做能跑通核心闭环的最小系统。 2. MVP 必须包含2.1 主循环 多轮 query loop tool call -> tool result -> next turn 2.2 基础工具 read file write file edit file grep/search bash 2.3 基础权限系统 allow / ask / deny 被拒后不原样重试 2.4 基础 transcript / session 消息持久化 resume 会话 2.5 基础 memory 用户 / 项目记忆注入 简单记忆文件结构 2.6 基础 agent orchestration main agent 至少一个 verification agent 可选一个 explore / plan agent 2.7 基础 compact 超长消息时压缩历史 工具结果 budget 裁剪 3. MVP 可以后置的能力...

16. Python 实现注意事项1. 实现原则目标不是逐字复刻原实现，而是用 Python 重建同样的产品能力结构。 2. 模块建议建议 Python 项目按以下模块拆： runtime/：query loop, orchestration messages/：message schemas tools/：tool registry and execution permissions/：permission engine memory/：memory loading and retrieval tasks/：background task model storage/：transcript and session persistence agents/：agent definitions extensions/：skills/plugins/mcp verification/：verification runner 3. 推荐先用的数据模型优先用： pydantic / dataclasses 定义消息与状态 sqlite 或 JSONL 先...

MCP 解决什么问题在 Agent 系统中，让Agent做出重要的决定的一个关键点是构造好的 /chat/completions 请求参数，参数中： messages 参数：给出对话历史，历史中包含的背景信息质量越高，给出的答案就会更准确； tools 参数：给出模型可用的工具，用于获取动态信息或执行某些动作。 这两个参数都可以认为是我们给模型的上下文信息。（context） message 的内容和问题messages 是一个数组，数组中的 content 的值是 user 给出的信息，或者其他角色的历史输出信息。如果是 user 给出的信息，则一般的做法是用一个 prompt template来组织基本的 prompt 结构，并将一些动态的信息通过其他方式检索到，补充道 prompt template中的占位符，从而形成最终输入模型的 prompt。 要得到最好的解，不同的问题需要不同的 prompt template。这是一个难点 tools 的内容和问题/chat/completions 接受的 tool 是有一定的 schema 规定，而一般的工具（如RESTful...

MCP 三大核心概念MCP（Model Context Protocol）的三大核心概念——Resources、Tools 和 Prompts。MCP 是 2024 年底由 Anthropic 搞出来的一个开放协议，目的是让大语言模型（LLM）能更顺畅地跟外部数据和工具对接。以下是我的解读： 1. Resources（资源）本质：Resources 是 MCP 里用来暴露数据的核心机制，相当于给 LLM 提供“原材料”。你可以把它想象成一个只读的数据库接口或者文件系统，里面装的是静态或者半动态的信息，比如日志文件、用户配置文件、股票价格啥的。 怎么用：服务器（MCP Server）把这些数据暴露出来，客户端（比如 LLM 应用）可以读取它们，然后塞进模型的上下文里去推理或者生成内容。比如你有个日志文件 app.log，通过 Resources 就能让 LLM 直接看到里面的错误信息。 特点： • 应用控制：客户端决定啥时候用、怎么用这些资源。有的客户端像 Claude Desktop 得用户手动选，有的可能自动挑，灵活得很。 • 实时性：支持订阅更新，比如资源变了，服务器能通知...

08. Agent 运行时主循环规格 目标：定义 Python 版本实现时最核心的运行时循环。该文档不是源码解释，而是实现规格。 1. 设计目标主循环必须满足以下目标： 能持续推进任务，而不是只做一次回答 能在每轮后根据工具结果重新决策 能在权限阻断、上下文压缩、工具失败时继续可控运行 能触发子 agent、后台任务、验证任务 能生成可追踪的消息流与 transcript 2. 主循环的输入一次主循环至少需要以下输入： messages: 当前消息序列 system_prompt: 已组装完成的系统提示词 tool_registry: 当前可用工具集合 tool_use_context: 执行上下文（cwd、权限、session、任务状态） memory_context: 注入后的记忆内容 user_context: 用户态上下文 system_context: 系统态上下文 can_use_tool: 权限判断函数 max_turns: 最大回合数 task_budget: 本轮任务预算（可选） 3. 主循环的输出主循环每轮可能产出： 普通 assistant 消息...

线性代数基本概念 特征值和特征向量 值域空间 零空间 行空间与列空间 正交补 基 标准正交基 奇异值分解 Matrix Norm (矩阵范数) Frobenius Norm (弗罗贝尼乌斯范数) 奇异值分解在统计中的主要应用为主成分分析（PCA）。数据集的特征值（在 SVD 中用奇异值表征）按照重要性排列，降维的过程就是舍弃不重要的特征向量的过程，而剩下的特征向量张成空间为降维后的空间。

深入解析 Python 包调用原理与最佳实践[toc] 一、引言写下这篇文章的起因，是最近我在参与 vLLM 项目的开发过程中，发现其中使用了一种动态加载对象的方式值得学习，并由此想对 Python 语言加载依赖的方式做一个研究和总结。本文将通过实验的方式，对 Python import 的原理以及不同 import 方式的区别进行介绍，并针对具体开发过程中可能会遇到的一些问题，分享一些最佳实践的解决方案。 二、什么是 Python 的包？Python 中的模块、包以及库有什么区别？ 一种简单且直观的理解： 模块（module）：任何 .py 文件都可以作为一个“模块”（除了 .py 文件之外，模块还可以有其它形式）； 包（package）：任何包含了一个 __init__.py 文件的文件夹都是一个“包”，一个包里可以包含其它的包和模块； 库（library）：“库”更多地是一种编程上的概念，表示可重复利用的代码。 关于这个问题，更深入的分析和讲解可以参考知乎上“风影忍者”和“看图学”的这两个回答，这里不再深入进行介绍。 三、深入解析 Python import 原理下...

这是个非常好的观察，而且你没有看错 👍在 vLLM-Ascend（NPU） 上，torch.npu.empty_cache() 确实可能导致 non-torch 显存下降，这和 CUDA 的行为本质不同。 下面我分「结论 → 原因 → 机制细节 → vLLM 场景」把这件事讲清楚。 一句话结论（先给你） 在 Ascend / torch-npu 上：torch.npu.empty_cache() 不仅仅是 PyTorch cache 操作，它会间接触发 Ascend Runtime / ACL 的内存回收路径，从而 释放部分 non-torch（runtime / kernel / workspace）显存。 这在 CUDA 上几乎不会发生，但在 Ascend 上是“设计如此”。 1️⃣ 为什么 CUDA 上不行，Ascend 上却行？CUDA（torch.cuda.empty_cache） 只操作 PyTorch CUDACachingAllocator 不会触发： CUDA Runtime 内部 pool cuBLAS &#...

推理显存计算推理所需显存 = 模型参数部分 + 激活参数部分 + KVCache 部分 模型参数部分 = 模型参数量 × 精度系数 激活参数部分 = 激活参数量 × 精度系数 KVCache 部分 = 并发数 ×（输入 Token 数 + 输出 Token 数）× 2（K 和 V）× 层数 × hidden_size × 精度系数 参考资料：模型显存计算逻辑