做 LLM Agent 开发时，Code Interpreter 是个绕不开的功能。让 AI 写代码容易，但让它安全地运行代码，却是个棘手的工程问题。 在设计 go-sandbox 之初，我们面临的最大抉择就是：到底是用 Docker，还是自己造轮子？ Docker 的诱惑与代价 最开始，我们自然而然地想到了 Docker。它成熟、安全、隔离性好。我们尝试为每个代码执行请求启动一个容器： docker run --rm -it python:3.10 python -c "print('hello')" 但在高并发测试中，问题很快暴露了： 1. 慢：即使是热启动，容器的创建和销毁也需要几百毫秒。对于用户来说，…
摘要：手持 X99 平台和一张只有 2GB 显存的 GTX 960，还能玩转 Docker 和 AI 吗？本文详细对比了 Docker Desktop 与 WSL Native 两种部署方案，并深入讲解了最令人头秃的网络代理配置、数据迁移。 X99 平台凭借多核心优势，至今仍是很多开发者的主力机。但当你想在 Windows 上通过 Docker 运行 AI 模型时，往往会面临选择困难症：是装简单易用的 Docker Desktop，还是追求极致性能的 WSL 原生命令行？ 本文记录了在 Windows (X99) + GTX 960 (2GB) 环境下的完整折腾记录。 第一部分：路线选择——你属于哪一派？ 在…
X99 平台（Xeon E5 v3/v4）凭借极其廉价的服务器拆机配件（如 E5-2696 v3 和 DDR3 ECC 内存），成为了很多技术爱好者和“垃圾佬”组建高性价比工作站的首选。 最近我在折腾一台配置为 E5 CPU + 64GB DDR3 内存 + X99-DM3 主板 + GTX 960 的机器时，经历了一系列从系统卡顿排查，到 WSL2 AI 环境搭建，再到显卡升级选型的过程。本文将详细记录这些坑点，特别是关于Tesla 计算卡与 GeForce 游戏卡的区别，以及一线主板与国产“寨板”的差异，希望能帮到同样在使用 X99 平台的朋友。 第一部分：性能排查——大内存为什么还卡？ 1. 误区：…
在前几篇文章中，我们搭建起了 RAG 的骨架：选好了向量数据库（Milvus），配置了强大的语义模型（BGE），甚至解决了时间衰减的问题。 现在，你的 RAG 系统已经能跑通了。但在实际测试中，你可能会撞上一堵无形的墙： * 场景 A： 你问“公司迟到怎么罚款？”，系统搜到了“罚款 50 元”的片段，但 LLM 答错了。因为那个片段太短，丢掉了前面关键的主语——“连续三次迟到者”。 * 场景 B： 用户问“怎么治那个一直在嗓子眼里的病？”，系统搜不到任何结果。因为数据库里的文档写的是专业的“慢性咽炎临床治疗方案”。 这标志着我们进入了 RAG 开发的深水区——检索质量优化（Retrieval Quality Optimization）。 不仅仅是“搜得快”，更要“搜得准”且“读得懂”…
在构建 RAG系统时，我们经常会遇到这样一个尴尬的场景： 用户问：“最新的 iPhone 摄像头参数怎么样？” 你的 RAG 系统兴致勃勃地从数据库里找出了 iPhone 11 的评测文章，因为那篇文章写得非常详尽，和问题的语义相似度（Semantic Similarity）极高。而关于 iPhone 12 的介绍可能比较简短，导致向量距离稍远，被排在了后面。 这就是向量检索的“时效性盲区”。 在 HNSW 或 IVF 这样的向量索引眼里，只有空间距离，没有时间概念。数据一旦写入，它在向量空间的位置就是永恒的。但在新闻、金融或日志分析等场景中，“新”往往比“准”更重要。 那么，在使用 Milvus 或 Faiss 时，我们如何引入时间衰减（Time Decay）…
在前两篇文章中，我们已经达成了共识：“Milvus + BGE-base + BGE-Reranker” 是目前构建中文 RAG 系统的高性价比黄金组合。今天，我们将使用 LangChain 框架将这三个组件串联起来，构建一个真正具备“漏斗式检索”能力的 RAG pipline。 准备工作 在开始之前，请确保你已经安装了 Docker 并启动了 Milvus 实例。同时，你需要安装以下 Python 库： pip install langchain langchain-community langchain-huggingface pymilvus sentence-transformers 注：我们将使用最新的 langchain-huggingface 库来加载模型，这是 LangChain 官方推荐的现代化方式。 核心架构设计 我们的代码将遵循以下数据流： 1. 加载与切分 (Load & Split): 将长文档切分成…
上一篇我们搞定了“身体”（Milvus 向量数据库），这一篇我们要赋予系统“灵魂”（语义理解）。 很多开发者有一个误区：认为 RAG 的效果主要取决于大模型（LLM）的智商。其实不然，RAG 的“生死线”在于检索（Retrieval）。 如果你喂给 LLM 的是垃圾文档，在好的LLM 也救不了你。而决定检索质量的核心，就是 Embedding（向量化） 和 Rerank（重排序） 模型。 在上一章中，我们搭建了 Milvus 向量数据库，它就像是一个巨大的、极其高效的图书馆书架。但是，把书放上去只是第一步，最难的是：当用户问“苹果怎么吃”时，你怎么知道要把关于“水果”的书给他，而不是关于“iPhone 手机”…
为什么说 Milvus 2.0 是云原生的？它如何通过“存算分离”实现无限扩展？从 Kafka 的多路消费到 HNSW 的参数调优，本文配合详细架构图，深度拆解 Milvus 的内核机制。 在 RAG 系统中，向量数据库（Vector Database）是长时记忆的载体。许多开发者在初次接触时，往往会选择 Faiss 这样的轻量级库。但当数据量突破千万级，或者需要高并发、高可用（HA）支持时，架构完善的数据库系统就成为了必然选择。 Milvus 是目前最主流的云原生向量数据库之一。与传统数据库不同，它采用了存储与计算完全分离的设计。这意味着，如果你还没看懂它的架构，你可能正在浪费大量的服务器资源，或者在面对“为什么刚插的数据搜不到？”这种问题时束手无策。 今天，我们通过一张图，并结合日志流转和索引原理，彻底看懂 Milvus 是如何工作的。…