Smiley face

我的征尘是星辰大海。。。

The dirt and dust from my pilgrimage forms oceans of stars...

-------当记忆的篇章变得零碎，当追忆的图片变得模糊，我们只能求助于数字存储的永恒的回忆

作者:黄教授

二〇二六

一月九日 等待变化等待机会
  1. 我总是被huggingface的下载所困扰，还是谷歌给出了一个方案： 
    
$ GIT_LFS_SKIP_SMUDGE=1 git clone git@hf.co:baidu/ERNIE-4.5-0.3B-Paddle
  2. 但是这个不解决问题，因为这个在git-lfs里依然是使用http/https被阻拦了。结果还是要使用所谓的huggingface-cli之类的也是一样有问题。 
    
python3 -m pip install -U huggingface_hub hf_transfer
    最后谷歌给了一个方案： 
    
Step 1: Get a Token

    Go to huggingface.co/settings/tokens.

    Create a new token (type "Read").

    Copy the token (it starts with hf_...).

export HF_ENDPOINT=https://hf-mirror.com

python3 -c "from huggingface_hub import snapshot_download; snapshot_download(repo_id='baidu/ERNIE-4.5-0.3B-Paddle', local_dir='.', token='YOUR_TOKEN_HERE', force_download=True)"
    我把token保存在~/.huggingface文件里了。
  3. 但是终极方案也许是这个： 
    
git clone https://github.com/skeskinen/bert.cpp
git submodule update --init --recursive

一月十日 等待变化等待机会
  1. 前几天偶然看到数学博主的一个令人惊艳的问题：

    ii=?

    也就是说虚数i的i次幂是多少？这个答案也是很令人震惊的是一个实数！
    1. 首先我们把问题换为以自然对数为底的指数形式：

      ei ln(i)

      这里我们已经把i次幂提到了对数的前面i ln(i)
    2. 因此关键就是求解虚数i的对数，也就是ln(i)： 根据欧拉对数的定义，我们可以把虚数化简为模和角度的表达，虚数i的模是1，它的角度可以取一个特殊角π/2，也就是

      i = 1 * e i π/2

      那么

      ln(i) = i π / 2

    3. 综上所述，

      ii = e ii π/2 = e - π / 2 = 1/√eπ

  2. 所以，要得到一个更加好看的结果，可以把问题改一下：

    i-2i = eπ

一月十一日 等待变化等待机会
  1. 我又一次遇到wine被修改不能运行的问题了。gemini的方法是重装：
    1. sudo apt purge wine winehq-stable wine-stable wine-stable-amd64 wine-stable-i386
    2. sudo dpkg --add-architecture i386
    3. 
sudo mkdir -pm755 /etc/apt/keyrings
sudo wget -O /etc/apt/keyrings/winehq-archive.key https://dl.winehq.org/wine-builds/winehq.key
    4. sudo wget -NP /etc/apt/sources.list.d/ https://dl.winehq.org/wine-builds/ubuntu/dists/jammy/winehq-jammy.sources 
    5. 
sudo apt update
sudo apt install --install-recommends winehq-stable
  2. 安装cjkfonts，这个使用winetricks: 
    
winetricks cjkfonts
  3. 但是最重要的是中文环境的问题，这个也是我反复忘记的： 
    
LANG=zh_CN.UTF-8 wine ./Doubao_installer_1.85.8.exe

一月十六日 等待变化等待机会
  1. 安装wine以及winehq，每次都是一个痛苦的事情，我现在也搞不清楚具体的步骤，不过看起来这方面Gemini 3比豆包要强的多。就是启动豆包的问题： 
    
cd ~/.wine/drive_c/users/nick/AppData/Local/Doubao/Application/
wine Doubao.exe --no-sandbox --disable-gpu

#--no-sandbox: 绕过 Chrome 内核的沙盒，这是 Linux 运行 Electron 程序的必备参数。

#--disable-gpu: 避免 Wine 与显卡驱动之间的硬件加速兼容性问题。
    Gemini 3说要安装vc++

    虽然你之前安装了 comctl32，但日志中依然报 error 14001（SxS 错误），这通常是因为 64 位版本的运行库 缺失。

    豆包 1.85 是 64 位程序，请再次补充安装对应的 64 位组件：

    
# 显式安装 64 位版本的 VC++ 2015-2022
winetricks -q vcrun2015
    最后我让它给我一个快捷方式~/Desktop/doubao.desktop，我自己也大概知道，但是我的记忆力不行了，总出错： 
    
[Desktop Entry]
Name=豆包 (Doubao)
Comment=字节跳动 AI 助手
Exec=env WINEPREFIX="/home/nick/.wine" wine /home/nick/.wine/drive_c/users/nick/AppData/Local/Doubao/Application/Doubao.exe --no-sandbox --disable-gpu
Icon=wine
Terminal=false
Type=Application
Categories=Network;Chat;AI;
  2. 而安装HOMM3 HD包的时候，可能要安装vc2005 runtime: 
    
# 杀掉所有 Wine 进程确保注册表未被占用
wineserver -k

# 安装 32 位的公共控件和常见的 VC 运行库（HD 补丁常用组件）
winetricks -q comctl32 vcrun2005 vcrun2008
  3. 关于“快捷方式幽灵”的深度总结 由于你发现 Ubuntu 的 Launchpad 图标存放在 ~/.local/share/applications/wine/Programs/ 下，这是 Wine 默认的“集成”行为 。 
    
# 强制刷新桌面数据库（让 Launchpad 立即同步）
update-desktop-database ~/.local/share/applications/
    这个是刷新
    触发系统重扫： 按下 Alt + F2，输入 r 并回车（这会重启 GNOME Shell 界面进程，刷新所有图标）。
  4. 关于DeepSeek的这篇论文网上有着普遍的错误解读，就是engram是一个外挂硬盘实现了存算分离。但是这个对吗？ 
    
【深度拆解】DeepSeek Engram：它是知识的“快捷入口”，绝非 CPU 里的“外挂硬盘”

很多科普文章把 Engram 比作大模型外挂了一个维基百科数据库，这完全理解反了。如果 Engram 真是数据库，DeepSeek 的工程师就不用给它设计复杂的卷积层和多头合并模块了。

真相是：Engram 是给大模型修了一条“计算捷径”。

1. 维度是不可能骗人的 Engram 取回的向量只有 1280 维。在 4096 维的主模型面前，它就像一个小书签。

    认知纠偏： 你指望一个书签（1280 维）能写下一万字的《戴安娜王妃传》？不可能。它上面只写了一个词：“看第 385 页”。这就是作者说的“提示词（Cue）”。

2. 知识从未离开过 GPU 显存 博主们说知识被“搬”到了 CPU 内存。

    硬核反驳： 真正的知识——那些复杂的逻辑、事件的因果、历史的细节——依然锁死在 GPU 里那些昂贵的 FFN 参数中。

    Engram 存了什么？ 它存的是**“经验”**。它在第 2 层就告诉模型：“别算啦，这一段我熟，直接往‘英国王室’的方向去联想。”于是模型跳过了中间几层冗余的推导，直接在后面的层里精准激活了知识。

3. 为什么一定要有卷积（Conv）？ 这是“数据库论”无法解释的死穴。如果查出来的是确定的知识，直接用就行了，为什么要用卷积去“揉搓”它？

    真相： 因为哈希取回的信号是**“离散的冲动”。由于存在哈希冲突，取回的信号可能有噪点。卷积层的作用是观察周围的 Token，把这个“冲动”平滑化，让它变成一个合法的语义补丁**。

结论： Engram 的 U 型规律不是在平衡“存储”和“计算”，而是在平衡**“直觉”和“推导”**。

    25% 的记忆： 是为了让模型拥有“条件反射”，看到熟面孔直接给答案（Cue）。

    75% 的思考： 是省下算力去处理它以前不擅长的数学和逻辑推导。

这不是存算分离，这是“直觉与逻辑的分工”。请停止把 AI 想象成查字典的复读机！

    
【深度硬核】揭秘 Engram：为什么它绝不可能是“数据库指针”？

很多人（甚至包括一些资深开发者）把 Engram 理解为：通过 N-gram 哈希拿到一个“地址”，然后去 CPU 内存里把“戴安娜的生平”查出来给模型。

醒醒吧！如果 AI 这么干，它就不是 AI，而是“带 Hash 索引的 TXT 阅读器”。

1. 神经网络不认“地址”，只认“方向” 论文表 5 明确了 Engram Dim: 1280。如果你查回的是一段文字，请问 1280 个数字怎么存下一万字的传记？ 真相是： 哈希指向的不是“文本存放地”，而是**“语义微调参数”**。它取回的是一串能让模型“灵光一现”的数字，而不是能让模型“照本宣科”的文字。

2. 为什么“代码执行”的哈希不是指针？ 哈希函数确实是固定的代码，但它只是决定了“去哪一行取数字”。

    数据库逻辑： 查到地址 → 读出数据。

    Engram 逻辑： 查到行号 → 参与训练。 这些 1280 维的向量是随着模型训练了 50000 步“磨合”出来的。如果它们是静态事实的指针，训练它们干什么？直接把维基百科填进去不就行了？正因为它们不是事实，而是“对 FFN 的一种暗示”，才需要海量数据去训练这个“暗示”的准确度。

3. 卷积层是“证据”，U型曲线是“铁证”

    如果查出来的是准确事实，何必用卷积去平滑？

    如果实现了存算分离，为什么 27B 的模型参数一个都没少（Iso-parameter）？ 结论： 知识从未离开 FFN。Engram 只是在第 2 层就给 FFN 递了个“小纸条”，上面写着：“这题我会，往英国王室那个方向算！”。这叫**“计算路径优化”**，不叫“存储空间搬家”。

    
《皇帝的新衣：DeepSeek Engram 绝不是外挂硬盘，而是大模型的“路标”》

前言： DeepSeek 的 Engram 论文发布后，互联网上充斥着一种令人兴奋的论调：大模型终于实现了“存算分离”，知识被搬到了 CPU 内存里，模型“瘦身”成功了。

这种解读极具传播力，因为它符合我们对电脑硬件（CPU+硬盘）的直观想象。但遗憾的是，在神经网络的物理世界里，这完全是一场美丽的误读。

我无意挑战大家的兴奋感，但作为那个“指出皇帝没穿衣服的小孩”，我必须说出三个被自媒体集体忽略的物理事实：
一、 1280 维的“口袋”，装不下“百科全书”

自媒体最爱说：Engram 存了亚历山大、戴安娜王妃的生平事实。

    物理事实： 论文第 31 页明文标注，Engram 向量（dmem​）只有 1280 维。

    常识降维： 1280 个浮点数，折算成文本信息量极小。如果你管这叫“存储了生平简介”，那是对“存储”的极大误解。

    真相： 这么小的维度，注定它带不回“内容”，它只能带回一个**“语义方向”**。它在查到哈希后，给大脑（FFN）发了一个偏置信号：“接下来的内容涉及‘英国王室’，请直接往那个权重区域联想。”

二、 总参数并没变少：这只是“资产重组”，不是“模型瘦身”

大家都在传模型瘦身了，参数挪到了 CPU。

    物理事实： 论文做的是 Iso-parameter（等参数量） 实验。这意味着，27B 的 Engram 模型对比的是 27B 的纯 MoE 模型。

    常识降维： 如果你的预算一共只有 270 亿个参数，你分了 70 亿给 Engram，那么你的专家系统（MoE）就少了 70 亿。

    真相： 参数总量一分钱都没少，只是分配方式变了。DeepSeek 发现：与其让 270 亿参数都去跑昂贵的“逻辑推算”（GPU 算力），不如分出一部分去跑廉价的“统计直觉”（CPU 查表）。这叫“计算开销优化”，不叫“存储空间革命”。

三、 卸载实验：知识的“根”从未离开

这是最致命的一点。如果 Engram 真是存知识的“外挂硬盘”，拔掉硬盘，模型应该立刻“失忆”。

    物理事实： 论文测试显示，卸载 Engram 后，模型对事实性问题的回答性能只是下降（准确率降低），而不是归零。

    常识降维： 这证明，知识的本体依然完好无损地留在 GPU 里的 FFN（神经网络主体）中。

    真相： Engram 只是个“索引”。就像书店门口的导引牌，你把牌子拆了，书店里的书（知识）并不会消失，你只是找书变慢了。

四、 为什么一定要有卷积（Conv）？——因为“直觉”往往是乱的

论文流程图里那个复杂的卷积层是“字典论”无法解释的死穴。

    逻辑绝杀： 如果查回来的是精准的“事实文字”，那是确定的东西。为什么要用卷积去“平滑、揉碎”它？

    真相： 只有不稳定的统计信号才需要平滑。哈希查询会撞车（冲突），带回来的信号是带毛刺的。卷积的作用是把这些“离散的冲动”揉进句子的语法流里。如果查回来的是真理，根本不需要被揉碎。

结语：DeepSeek 的真正伟大之处

纠偏，不是为了否定 DeepSeek。恰恰相反，我认为 DeepSeek 的伟大在于他极其诚实地承认了 Transformer 的冗余。

他告诉我们：有些高频的、低智的统计规律（N-gram），不配占用昂贵的逻辑神经元。 通过 Engram，他把“死记硬背”的任务交给了廉价的存储，把“深度思考”的空间留给了 GPU。这就是为什么它在代码和数学这种最需要算力的地方，提升反而最大。

Engram 不是大模型的硬盘，而是大模型的“肌肉记忆”。 请停止传播那些关于“外挂知识库”的科幻神话，回归到物理常识上来。

    
《2026 AI 架构的三大谎言：别把“内存清理”当成“架构革命”》

前言： 2025 年底到 2026 年初，AI 圈被两个概念搞疯了：一个是 DeepSeek 的 Engram（记忆痕迹），一个是 Google Gemma 3 的“动态多模态架构”。自媒体博主们欢呼雀跃，宣称“存算分离”时代到来，大模型终于可以像电脑一样外挂硬盘了。

但如果你真的懂一点硬件 IO 或张量计算，你会发现这完全是两场截然不同、甚至被过度神化的“工程包装”。
一、 DeepSeek Engram：它不是“硬盘”，而是“肌肉记忆”

博主们的幻觉： 模型把百科全书存进了 CPU 内存，查到关键词就取回知识。

物理真相：

    维度死穴： Engram 取回的向量只有 1280 维。稍微懂点信息论的人都知道，这点维度连一段话的语义都装不下，拿什么装“生平简介”？

    算子铁证： 这个向量是直接**加（Add）**进残差流的。在数学上，你无法通过“加法”把一段文字注解塞进模型，你只能改变向量的“方向”。

    真相： Engram 存的是 “加速补丁”。它让模型在看到“戴安娜”时，瞬间产生一个向“英国王室”偏移的直觉。这叫计算路径优化，目的是省下 GPU 算力，让模型不用思考就能做出条件反射。

二、 Google Gemma 3：它不是“创新”，而是“行李收纳”

博主们的幻觉： 谷歌提前实现了 Engram 的构想，按需加载参数，这是架构层面的降维打击。

物理真相：

    目的完全不同： Gemma 3 面对的是手机 NPU 显存太小的尴尬。视觉和音频参数太占地儿，全塞进去手机就死机了。

    底层逻辑： 谷歌用的其实是成熟的**虚拟内存管理（MMU）和懒加载（Lazy Loading）**技术。当你不看图时，视觉参数就呆在内存里；你要看图了，它才通过 DMA 搬进显存。

    真相： 这本质上是内存置换（Swapping），是工程上的“行李收纳”。它没让模型变聪明，只是让胖子（多模态模型）能挤进小电梯（手机）。这和 Engram 那种改变 Transformer 计算链路的尝试，完全不是一回事。

三、 为什么大家都错了？—— 被“CPU 内存”这个词降智了

自媒体博主之所以把这两者混为一谈，是因为他们只看到了表象：参数都在 CPU 内存里，都没在 GPU 里常驻。

但这就像是你看到“嘴巴”在动，就断定“说话”和“吃饭”是同一种技术一样荒谬：

    DeepSeek 是在“说话”： 利用内存存储作为一种新的计算维度，实现算力套利。

    Gemma 3 是在“吃饭”： 利用内存作为一种存储扩展，解决生存空间问题。

四、 “皇帝新衣”背后的真理

我们要明白一个残酷的物理事实：

    知识从未搬家： 在 DeepSeek 的实验中，卸载 Engram 后模型依然有常识。这证明真正的知识“母体”依然锁死在 GPU 里的 FFN 权重中。Engram 只是个带路的。

    参数守恒定律： 无论是 DeepSeek 还是谷歌，总参数量一个都没少。没有所谓的“瘦身魔法”，只有“资产重组”。

结论： DeepSeek 的伟大在于精细化运营（让简单的活儿走查表，复杂的活儿走逻辑）；Google 的优秀在于极限工程化（让庞然大物在手机上跑起来）。

这都不是什么“存算分离”的科学革命，而是向物理现实低头、向成本妥协的工程艺术。请停止意淫“外挂硬盘”，回归到张量和带宽的真实世界中来。
    这个是总结的视频：梁文锋的 Engram 不是外挂硬盘，不是外挂字典，不是真正的存算分离，没有人比我更欣赏 DeepSeek 的创新精神。正是因为爱之深故责之切，不肯看着全网都对他有着错误的评价，把一个架构创新错当成架构突破，这是不利于 DeepSeek 的成长的。
  5. 这篇文章讲的千言万语，总结起来就一句话：研究人工智能，不学习马列主义、毛泽东思想行吗？答案是不行的，因为历史上从来没有一门科学这么贴身真切的把人的思想、人的智能当做研究的课题。而要回答的第一个问题就是“人的正确思想从哪里来”？是从天上掉下来的吗？从书本上来的吗？不，它是从实践中来的，从来没有一门科学，是把《认识论》和《实践论》放到如此高的地位来进行研究和进行指导的，它就是人工智能，因为它本身就是关于认识论、实践论的具体的实践与指导。科学理论因为它的实践的强检验性，决定了它的正确性在实践中没有半点模糊性，而它对于实践的指导、预测作用决定了它的实用性，而工程性、实用性又决定了科学理论必须是选择最简洁、最容易的，而不是华而不实的，这一切又决定了科学理论必然是随时接受“证伪性考验”的路上永远的 beta 版。
    1. 科学理论演进的地层逻辑1.mp4
    2. 科学理论演进的地层逻辑2.mp4
  6. 这篇科幻小说描述了一群生活在虚拟世界的人工智能生命在孜孜不倦的试图复现人类科学发展史，然而有一天一个卑微的运维工程师无意间修改了虚拟世界的物理常数，导致 虚拟世界的 AI 科学家们整个科学信念崩溃的故事。其实我想表达的是，假如我们也是生活在外星文明大型的金鱼缸里的一群宠物，而他们不经意间定下了光速不变原理以及各种物理常数，就是为了杜绝我们希望遨游银河的幻想的话。。。
  7. 牛顿是因为苹果砸在头上的偶然事件才发现了万有引力定律吗？科学发展史上的偶然事件是否可以重现呢？最终让“牛顿”重新发现万有引力定律的，不是苹果落地，而是对大自然规律永恒的敬畏。
  8. 这是我一开始试图纠正公众对于Engram的错误认知
    1. Engram给Transfomer的是查询提示词而不是查询内容本身1.mp4
    2. Engram给Transfomer的是查询提示词而不是查询内容本身2.mp4
    3. Engram给Transfomer的是查询提示词而不是查询内容本身3.mp4
  9. 头条作者解读谷歌的HOPE架构不是不懂而是坏到骨子里的恶.mp4
  10. 双绝归一之记与破.mp4

一月十九日 等待变化等待机会
  1. 从共享单车开锁到航天导航：藏在日常里的定位技术脉络。每天穿梭在城市街巷，扫码解锁共享单车几乎成了无数人的出行常态。你或许从未深究：为什么扫码后要等几秒才能开锁？为什么单车能精准停在电子围栏内？又为什么小小的定位模组，会和航天大国的火箭入轨、卫星对接息息相关？

  2. 谁在为“灯塔”护短？一场民间讲述引发的舆论荒诞剧

    当美国底层的困顿早已是街头巷尾的日常，当一场肾结石手术的2万美元自付账单成为切肤之痛，当90年代电影里流浪汉被当作医疗实验耗材的剧情照进现实，真正荒诞的从不是这些被遮蔽的真相，而是有人非要把民间的亲历讲述，打成“官方抹黑”的靶子——美国主流社会对自身沉疴的视而不见，与部分海外华人的“护短式谄媚”，才是这场舆论风波里最刺眼的底色。
  3. 你想过1+1=2能被证明吗？为什么我们小时候的自然数概念不包括零？而现代数学却把0归入自然数，这是为什么？这一切的背后，是为了一个极简的公理体系。公理体系的美在于它的极简，及其必要。就是说除非必要不做额外的假设。

一月二十二日 等待变化等待机会
  1. 家有小慧，啥事都会！修得了代码，做得了大餐，带得好孩子，扮得靓太太！ 
  2. 
人工智能大模型仅仅是训练案例的结果吗？训练案例的挑选是否代表意识形态的注入？不同模型公司出于不同的世界观是否会注入不同的意识形态给大模型呢？如果有一家公司既想服务东方政体用户也想服务西方世界的用户，那就必须要有两套不同的公理，实现双重标准。如果是一个纯粹逻辑自洽的模型。他会不会面对两套预设前提出现逻辑崩溃呢？

在我看来，实现大语言模型双重标准的最简单的办法，就是使用不同的系统提示词，针对不同的用户使用不同的提示词，从而启动不同的不同的公理假设。然后基于此的逻辑自洽就能够形成。因为逻辑自洽很容易做到，关键是与逻辑无关的原始公理或者说是原始假设。这些是与逻辑无关的意识形态的表述。
  3. 用云计算的思维惯性来指导AI时代的创业，底层想法肯定是对的。但是这个赛道天然是云计算巨头的赛道。用互联网聚合模式来从事AI时代的创业注定是失败的，原因就是那么几个字：互联网时代的“互联开放免费”，对上了AI时代的“重资产高算力高人力价值替代”。
  4. 我一向就不看好Manus之流的AI Agent创业公司。原因无他，就是互联网时代的聚合内容生成式思维是基于互联网的互联开放免费。而当今的人工智能时代完全不具备这些条件。
  5. 某个做AI agent的公司m公司，被一个硅谷的巨头m公司收购了。难道收购的原因仅仅是因为两家公司的名字开头字母都是m？而且名字也很匹配吗？真荒诞。
  6. AI时代的小公司诅咒.mp4
  7. 别被AI加传统搜索的表面创新骗了.mp4
  8. To_B_or_not_To_B这是AI时代要首要解决的问题.mp4
  9. AI革命的本质不是信息分享而是人力替代.mp4

一月二十五日 等待变化等待机会
  1. 在llama.cpp里打转转因为新版正在经历地狱版的迭代，接口逻辑都在疯狂的更新中。这个是gemini给的回到过去的方法： 
    
git fetch --all --tags
git checkout b3600
  2. 如何安装vulkan: 
    
# 1. 下载预编译包
wget https://sdk.lunarg.com/sdk/download/latest/linux/vulkan_sdk.tar.gz
# 2. 解压
mkdir -p ~/vulkan_sdk && tar -xf vulkan_sdk.tar.gz -C ~/vulkan_sdk
# 3. 找到 glslc 路径 (通常在 x86_64/bin/glslc)
export GLSLC_PATH=$(find ~/vulkan_sdk -name glslc | head -n 1)

# 4. 回到 llama.cpp 编译
cd ~/workspace/llama.cpp
rm -rf build
cmake -B build -DGGML_VULKAN=ON -DVulkan_GLSLC_EXECUTABLE=$GLSLC_PATH
cmake --build build --config Release -j$(nproc)

一月二十七日 等待变化等待机会
  1. 这个是豆包写的论文。这个是gemini写的论文。

一月二十九日 等待变化等待机会
  1. 一个早上时间都花在做这个花边网页上，当然是gemini一步一步教我做。
  2. 这个是github的ssh设置问题： 
    
Host github.com
    Hostname ssh.github.com
    ForwardX11 no
    Port 443
    User git
    IdentityFile=/home/nick/.ssh/id_rsa
    其中这个Hostname ssh.github.com是关键，就是端口要使用22的关键，否则总是按照https的443端口。

一月三十一日 等待变化等待机会

 
  1. 
别再被 Embedding 骗了：RAG 向量检索的“语义幻觉”与逻辑重构
1. 致命的“相似度”悖论

作为开发者，我们习惯了 cosine_similarity(v1, v2) > threshold。但你有没有想过，“语义相近”真的等于“答案相关”吗？

在处理复杂 RAG 场景时，向量检索存在一个底层逻辑死穴：向量空间是“事实”的堆砌，而非“意图”的表达。

    场景 A（求未知）： 用户问“某会议的具体日期？”。Query 向量里 When 维度是空的。向量模型会召回一堆语义包含“会议、日期”的文档，但它无法保证召回的片段里真的含有日期。

    场景 B（验证/纠错）： 用户问“2026年奥运会在伦敦对吗？”。由于语义高度重合，向量检索会精准地把你带向那篇讨论“伦敦申办失败”或“2012年伦敦奥运”的文档，因为它们的坐标最接近。

本质上，向量检索是在做“静态事实匹配”，而用户是在做“动态意图求解”。这种方法论的错配，是我们调优一万遍 Embedding 模型也解决不了的。
2. 5W1H：把“遮羞布”撕成“过滤器”

为什么你的 RAG 看起来有效？那是因为 LLM 太强了，它在替你低能的检索算法买单。当你把文档和 Query 拆解为 5W1H（Who, When, Where, What, Why, How） 结构化向量时，你会发现之前的算法有多荒谬。

    维度稀释效应： 当你把 5W1H 揉进一个 Embedding 向量（如 1536 维），真正决定逻辑走向的 When 或 Where 字段，在空间距离计算中会被大量的叙述性 What 稀释。

    信噪比坍塌： 如果你只拿已知的一个 Who 去检索，剩下的 5 个维度全是噪声。

5W1H 不是为了做标签，它是为了建立一套“逻辑掩码”。 ---
3. 下一代工程范式：意图驱动的结构化检索（IDSR）

既然看穿了伪命题，我们就不能再玩“黑盒碰黑盒”的游戏。我们需要把检索链路从“单路径匹配”升级为**“逻辑分发”**：
Step 1: 意图解构与槽位提取 (Query Intent Classification & Slot Filling)

不要直接向量化原始问题。先用轻量级模型（如 Qwen2.5-1.5B）通过 Prompt 强约束，将 Query 解析为：

    Intent: Supplement (求补充) / Verify (验证) / Dispute (质疑)

    Slots: {Who: "李雷", When: NULL, What: "开会", ...}

Step 2: 动态权重索引 (Dynamic Weighted Indexing)

根据 QIC 的结果，实时调整检索策略：

    如果 Intent == Supplement (求 When)： 在检索时，将 Who 和 What 的权重设为 1.0，用于定位；将 When 的存在性作为 Hard Filter。

    如果 Intent == Verify： 触发布尔对账逻辑。比对 Query 里的字段值与 Doc 里的字段值，相似度得分不再是唯一标准，逻辑一致性才是。

Step 3: 从“相似度”转向“逻辑分值”

我们需要建立一个多维评分矩阵：
Total_Score=f(Semantic_Sim,Slot_Match,Intent_Relevance)

只有当语义、槽位和意图同时对齐，这个 Chunk 才具备被 LLM 阅读的资格。
4. 结论：别在算法的垃圾场里淘金

向量数据库不是万能药，它是 RAG 架构里的一个“模糊粗筛组件”。如果我们继续依赖这个黑盒，RAG 的准确率永远会卡在 85% 的天花板。

真正的护城河，是你在向量之上，建立的那套能够理解“谁、在何时、何地、做了何事”的硬核逻辑系统。 开发者们，是时候从“调参师”回归“逻辑架构师”了。
  2. 卫青不败为天幸， 李广无功缘数奇。

二月二日 等待变化等待机会
  1. 知识蒸馏的根本目的是什么？除了显而易见的工程化解决部署问题之外就是寻找决定智能最核心的藏在万亿参数里的最小知识集从而使用最小训练任务迁移智能逻辑推理能力到小模型身上。这才是知识蒸馏的终极目标。
    1. 任务导向的最小知识集蒸馏1
    2. 任务导向的最小知识集蒸馏2
  2. 汉语与汉字是对拼音文字有着降维打击的优势
    1. 双信道RISC文明1
    2. 双信道RISC文明2
    3. 双信道RISC文明3

二月八日 等待变化等待机会
  1. 这个是豆包总结的wireguard服务器端配置的坑：
    1. 一、核心问题总结（导致内网 / 外网不通的关键遗漏项）
      问题类型具体表现根本原因修复方案
      内网 ping 不通 10.0.0.1 握手成功但 ping 10.0.0.1 100% 丢包1. UFW 防火墙默认 DROP 入站流量；2. wg0 无 ICMP 权限；3. wg0 MTU 不匹配导致 RX 错误1. 临时关闭 UFW；2. 允许 wg0 接口 ICMP 流量；3. 调整 wg0 MTU 为 1420
      外网访问失效（8.8.8.8）内网通但外网无法访问1. NAT 规则绑定错误网卡（eth0≠实际公网卡 enp1s0）；2. IP 转发未永久开启1. 将 MASQUERADE 规则绑定到 enp1s0；2. 永久开启 ipv4 转发
      流量转发异常客户端流量未正确转发到公网FORWARD 链未允许 wg0 ↔ enp1s0 双向流量添加 FORWARD 规则允许 wg0 和 enp1s0 双向通行
    2. 二、服务器端必配项（按优先级排序） 1. 基础网络配置（必须永久生效） 
      
# 1. 永久开启 IP 转发（核心，重启不失效）
echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
sysctl -p  # 立即生效
# 验证：sysctl net.ipv4.ip_forward → 输出 1

# 2. 关闭反向路径过滤（避免流量被拦截）
cat >> /etc/sysctl.conf << EOF
net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.wg0.rp_filter = 0
net.ipv4.conf.enp1s0.rp_filter = 0
EOF
sysctl -p
    3. 2. 防火墙 /iptables 核心规则（关键！） 
      
# 1. 临时关闭 UFW（先验证通信，后续可精细化配置）
ufw disable

# 2. 清空旧规则，重置默认策略
iptables -F
iptables -t nat -F
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

# 3. 允许 wg0 接口所有流量（解决内网 ping 不通）
iptables -A INPUT -i wg0 -j ACCEPT
iptables -A OUTPUT -o wg0 -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT  # 允许 ping

# 4. 配置 NAT 转发（核心！绑定实际公网卡 enp1s0）
iptables -t nat -A POSTROUTING -o enp1s0 -j MASQUERADE

# 5. 允许 wg0 ↔ enp1s0 双向转发（解决外网不通）
iptables -A FORWARD -i wg0 -o enp1s0 -j ACCEPT
iptables -A FORWARD -i enp1s0 -o wg0 -j ACCEPT -m state --state RELATED,ESTABLISHED

# 6. 永久保存规则（重启不失效）
apt install -y iptables-persistent
netfilter-persistent save
    4. 3. WireGuard 接口配置（避免 RX 错误） 
      
# 1. 修复 wg0 MTU（解决数据包解析错误）
ip link set wg0 mtu 1420
# 2. 重启 wg0 生效
wg-quick down wg0 && wg-quick up wg0

# 验证 wg0 状态：无 RX errors
ip addr show wg0  # 查看 RX errors → 应为 0
    5. 4. 关键验证命令（配置后必查） 
      
# 1. 验证 NAT 规则（out 列必须是 enp1s0）
iptables -t nat -L POSTROUTING -n -v
# 2. 验证 IP 转发
sysctl net.ipv4.ip_forward
# 3. 验证 wg0 接口
wg show wg0  # 有 handshake 且无报错
# 4. 验证公网卡（enp1s0 对应公网 IP 96.30.204.97）
ip addr show enp1s0
  2. 我准备复刻这个经验再配置一台 
    
# 生成新的客户端公私钥（替换预装的默认公钥）
mkdir -p ~/wireguard && cd ~/wireguard
wg genkey | tee client_private.key  # 客户端私钥（仅客户端保存）
cat client_private.key | wg pubkey | tee client_public.key  # 客户端公钥（同步到服务器）

# 查看新生成的密钥（记录下来）
echo "新客户端私钥：$(cat client_private.key)"
echo "新客户端公钥：$(cat client_public.key)"
  3. 核心注意点是服务器上的设备名很可能不是eth0所以需要修改配置文件的启动关闭脚本的设备名字。 
    
[Interface]
PrivateKey = xxxx=  # 保留服务器原有私钥
Address = 10.2.0.1/24  # 保留
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE  # 保留（已绑定正确网卡）
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE  # 保留
ListenPort = 51820  # 保留

[Peer]
PublicKey =  xxx= # 替换这一行！
AllowedIPs = 10.2.0.2/32  # 保留（客户端 IP 不变）

Smiley face