分类下的全部文章
https://github.com/sickn33/antigravity-awesome-skills |工具|Skills 文件夹正确名称|说明| | --- | --- | --- | |**Codex App / Codex CLI**（OpenAI）|**.agents/skills**（**复数** agents）|官方标准| |**Antigravity**（Google）|**.agent/skills**（**单数…
完整的中文 RAG 稀疏检索原型：**先切块 → 分词 → 建 BM25 索引 → 查询匹配**。本文通过一个可运行的 Python 示例，逐步拆解每个环节的原理与实现细节。 --- 整体流程概览 🔍 稀疏检索（Sparse Retrieval）的核心思路是：将文档和查询都表示为**高维稀疏向量**（大部分维度为 0，只有出现的词对应维度非零），然后通过向量相似度（本质是加权关键词匹配）完成检索。BM25 是最经典的稀疏检索算法。 整…
💡 **为什么要了解稀疏向量和稠密向量？** 在构建 RAG（Retrieval-Augmented Generation，检索增强生成）系统时，检索质量直接决定了最终生成答案的好坏。而检索的核心就在于如何把文本变成向量、用什么样的向量去匹配。理解稀疏向量和稠密向量的区别，能帮助你选择合适的检索策略，甚至将两者结合以获得最佳效果。 在信息检索和 RAG 里，我们把一段文本（句子、段落、文档）转换成一个**数字列表**，这个列表就叫**…
创建 collection 建立索引： 使用稀疏向量 **表结构**、**度量标准**和**算法参数**三个维度。 字段属性 (Schema Fields) 在向量数据库中，每一行数据不再只是简单的文本，而是由以下核心字段组成： **FloatVector(1024)**: **概念**: 这是一个高维向量字段。 **1024 (维度)**: 这必须与你的 Embedding 模型（如 BGE-M3）输出的维度完全一致。它代表了将一段…
前言 在构建企业级 RAG（检索增强生成）系统时，**Rerank（重排序）** 是提升准确率的关键一环。我们通常会选择强大的 CPU 服务器来部署这一服务，比如拥有恐怖核心数的 AMD EPYC 系列。 然而，许多人在部署 HuggingFace 的 text-embeddings-inference (TEI) CPU 版后会发现：**为什么我的 CPU 利用率不高，推理速度也不尽如人意？** 感觉就像开着法拉利在送外卖。 根本原…
下载模型 配置 onnx 转换 vim convert_to_onnx.py 下载模型，因为需要 onnx 转换，所以使用 python 进行转换 配置 docker-compose **Docker 的坑：** 默认情况下，Docker 只给容器分配 **64MB** 的共享内存。 **AI 的需求：** TEI、PyTorch、Ollama 这些 AI 程序，在处理大量并发或大模型时，需要在进程间传输巨大的矩阵数据。 **后果：*…
下载模型 以这个 bge-m3 为例： save_dir 就是保存的绝对路径，根据需要修改 tei 部署 测试 部署测试 你会看到屏幕上瞬间刷出一屏密密麻麻的浮点数：[[0.0123, -0.0456, ...]]。 只要看到这一屏数字，说明 **TEI 活了**，模型加载成功，推理功能正常。 如果报错 Connection refused，说明容器没起来或者端口没对上。 相似度测试 运行结果：
docker-compose 部署 部署minio 首选会使用到 Minio 因为我之前配过，所以这里直接使用了即可。 注意需要自己的 MINIO_ROOT_USER 和 MINIO_ROOT_PASSWORD milvus 其他的服务 注意修改MINIO_ACCESS_KEY_ID 和MINIO_SECRET_ACCESS_KEY 的值。 先启动 Minio 然后启动这个 docker-compose 的文件。 一开始启动会报错，不…
