设计模式（Design pattern）代表了最佳的实践，通常被有经验的面向对象的软件开发人员所采用。设计模式是软件开发人员在软件开发过程中面临的一般问题的解决方案。这些解决方案是众多软件开发人员经过相当长的一段时间的试验和错误总结出来的。

最近的 战地6 发布了，作为一款FPS游戏，是出了名的外挂多， 这才发布几天又变成了天神乱斗，这不怪EA菜，毕竟 TX 的 ACE 保护下的三角洲也遭不住挂B满天飞。这是 FPS 游戏技术架构的 “先天缺陷”。

为了提供流畅、无延迟的游戏体验，FPS 游戏通常采用 “客户端预测（Client Prediction）” 和 “客户端信任（Client-Side Trust）” 的架构。这意味着：

• 可见性数据： 客户端（玩家的电脑）必须提前知道和渲染地图上所有可见对象的信息，包括你的队友、你的敌人、各种道具的精确坐标、血量、装备等。如果客户端不知道敌人的位置，游戏就无法在敌人出现的一瞬间立即渲染出来，会造成延迟。

  ➡️ 结果： 这一数据漏洞直接催生了 透视（Wallhack/ESP - Extra Sensory Perception） 外挂。外挂程序只需从本地内存中读取这些合法的“敌人坐标”数据，然后绘制到屏幕上，作弊者就能透视障碍物看到敌人。

• 物理与射击计算： 在一些 FPS 游戏中，虽然最终的伤害计算会由服务器验证，但瞄准、弹道落点、后坐力等输入细节，最初都源于客户端的输入和本地计算。

  ➡️ 结果： 这为 自瞄（Aimbot） 提供了可乘之机。外挂程序通过读取内存中的敌人位置，然后直接劫持鼠标输入，向瞄准目标发送精确的、看起来合法的鼠标移动指令。

好吧，其实是最近在刷 B 站的时候，偶然看到差评君的一个 vlog – 游戏厂商下场制裁DMA外挂，VT-d技术立大功？

视频链接放到末尾 ~

最近在日常的工作中遇到这样一个场景：我需要存储线上海量的拨测结果，内存里堆积着数以百万计的小对象，每个对象只有几百字节？当我满怀信心地以为 Go 的垃圾回收（GC）能帮你搞定一切时，却发现程序时不时地“卡顿”一下，CPU 飙升，而内存占用也远超预期。

深入分析后，我终于定位到了问题的症结所在：这个服务需要维护海量的业务元数据，每个元数据对象只有大约 2000-5000 字节，但总量却高达 200 万个。这些“小不点”们，在内存里正悄无声息地制造着一场“大麻烦”！

在讨论RAG技术之前，我们先看在开发大语言模型（LLM）应用时会遇到的典型场景问题。比如，当设计一个 LLM 问答应用，当模型回答用户的特定领域问题时，尽管大模型再厉害，也没办法提供准确的答案，而且大模型的训练数据也不可能总是最新的，模型无法及时提供最新的答案，这种现象在 LLM 应用中较为常见。

除此之外，还有其他的诸多问题。总结为以下几个问题：

• 领域知识缺乏: 大模型的知识来源于训练数据，而训练数据来自于互联网上的爬虫获取到的内容，无法覆盖特定领域的高度专业化的内部知识。
• 信息过时: 模型的训练周期长、花费大，模型一旦完成训练，就难以获取和处理新信息。
• 幻觉问题: 模型都是基于概率生成文本，有时会输出看似合理但实际错误的答案。
• 数据安全性: 在关键领域，如保密单位，企业内部，需要保证数据的安全。