向量数据库原理与实现实验报告

课程作业要写「向量数据库原理与实现」的实验报告，卡住的地方往往不是原理，而是实验怎么设计、指标怎么记、结论怎么写才不像套话。这篇给一套能直接照做的报告骨架：原理部分写到什么颗粒度、实验分几组、每次跑完记哪些字段、误差和延迟怎么解释。不替你下结论，只把可复现的流程和落到表格里的东西列清楚。

写「向量数据库原理与实现」的实验报告，真正卡人的通常不是原理本身，而是实验怎么设计、每次跑完该记什么、结论怎么写才不至于像在凑字数。很多作业的前半段（向量化、建索引、近邻检索）抄得挺全，一到实验部分就只剩一句「效果良好」，老师一眼就能看出来没真跑。

这篇给一套能照着填的报告骨架：原理部分写到什么颗粒度停下、实验分几组、每一轮运行固定记录哪些字段、延迟和召回怎么解释。判断标准和动作都给出来，但结论不替你下——你的数据长什么样，只有你自己跑完才知道。文中涉及具体参数和数字的地方，一律写到站内对应页面现场核对，别把会变的东西写进报告正文。

原理部分写到什么颗粒度就够

原理节最容易写成论文摘要的翻译。对调用型实验来说，够用的颗粒度是：把整条链路拆成四段，每段说清输入是什么、输出是什么、中间付出了什么代价，然后停手。推导过程、公式展开、索引树的旋转细节，除非作业明确要求实现算法本体，否则写进去只是占篇幅，还容易写错。

向量化

原始对象（文本、图片、音频）经模型转成定长浮点数组，输入是原始数据，输出是向量与配套的原始记录编号

建索引

把一堆向量组织成便于剪枝的结构，输入是向量集合，输出是可查询的索引文件，代价主要在时间和内存

近邻检索

给定查询向量，返回距离最近的若干条，输入是查询向量与返回条数，输出是候选编号列表

结果回填

用候选编号取回原始记录并排序展示，输入是编号，输出是最终结果，这步常被忽略但直接影响观感

「近似」到底从哪来，是原理节必须回答的问题。暴力检索一定最准，但每次都要和全库算距离；ANN 靠剪枝只访问一部分候选，于是快、但可能漏掉真正最近的邻居。召回率和延迟之间的拉扯就从这里出来：剪得越狠越快，漏得越多。这一节把这条因果讲顺，后面实验的曲线才有解释的落点。

• 索引类型按「建库成本、查询成本、内存占用、是否支持增量」四列做原理级对照，不写具体参数值
• 对照表里每一行标注适用场景，比如数据量小、要求强一致时暴力检索反而是合理选择
• 具体某款向量数据库的索引参数含义与默认值，到 /stacks/vector-dbs 看你选的那款当时的说明，别凭记忆写
• 如果作业要求自己实现索引，原理节要下沉到距离度量和剪枝逻辑，本篇这套调用型骨架不再适用

实验怎么分组：三组就够，别贪多

课程作业的时间有限，组数太多每组都跑不充分，反而不如三组跑扎实。核心原则是变量一次只动一个：这组动什么、其余全部锁死，锁死的条件写进报告的「固定条件」小节。否则曲线一变，你根本说不清是哪个因素造成的，结论也就无法归因。

1. 第一组：固定数据与索引，只调检索参数数据、索引类型、索引参数全部冻结，只改每次返回的条数。观察召回怎么变、延迟怎么变。验证方式：同一份数据重复跑几轮，确认趋势稳定而不是抖动。
2. 第二组：固定检索参数，换索引类型返回条数锁死，横向换两到三种索引。记录建库耗时、内存占用、查询延迟和召回。验证方式：每种索引至少跑一轮完整的建库加查询，不要拿缓存后的结果比较建库成本。
3. 第三组：固定索引，改数据规模或维度索引和参数不变，把数据条数或向量维度成倍往上加，看延迟和内存的拐点出现在哪个量级。验证方式：至少取三个不同规模的点，两个点连不出趋势。

对照组里一定要放暴力检索当基线。没有基线的曲线，读者不知道「快」是相对谁快，「准」是相对谁准。另外，语料建议自造一份小而可控的，比如几百条短文本，比直接上大公开数据集更容易解释结果，出问题也好排查。

每次跑完记哪些字段：一张表定死

指标口径在动手之前就定死，跑完再补记一定会漏。最少要记录下面这些字段，一行一次运行，落成 CSV。报告里的所有图表都从这张表生成，不要手抄数字，手抄必错。

延迟的分位口径和测试流程，可以参考 /tools/speed-test 的做法，保持和你报告里其他测量一致。要注意一个不适用的情形：如果实验跑在共享机器或限额容器里，延迟数据只能做相对比较，报告里必须写明这条限制，否则数字看着精确、实际不可复现。

结论怎么写才站得住

结论段最常见的毛病是只报好的一面。延迟降了就说方案更优，闭口不提召回掉了多少。实验报告的价值恰恰在权衡：把「快了多少、准了多少」并排放在一起，读者才能判断这个取舍值不值。每个结论后面挂一句限定条件——在什么数据规模、什么参数下成立，换个规模有没有可能反转。

• 限定条件写在结论句后面，比如「在本实验的数据规模下」，不要含糊地说「一般来说」
• 延迟变好但召回变差这类取舍必须明写，这是报告最该有的部分
• 复现步骤写成编号清单：环境、数据来源、脚本入口、跑一次的命令，别人按它跑出同样趋势就算合格
• 图不用多，一张延迟与召回的权衡图、一张规模变化图通常就够；榜单类数字不要写死在正文，去 /rankings 看当时的数字

交之前对着这份清单过一遍

下面几条是阅卷时最容易被抓的点，交之前逐条核对，能省掉大部分返工。

• 维度、距离度量、归一化方式三项是否都在报告里写清楚；这三项不同，任何横向比较都不成立
• 是否只跑了一轮就下结论；至少重复几轮，给出稳定区间而不是单次数值
• 是否混用了「向量检索」和「全文检索」的说法；两者原理不同，资料类工具的定位可以对照 /ai-nav/category/ai-data 的说明
• 环境和依赖是否记录；换一台机器跑不出同样结果时，这份记录是唯一的排查依据
• 指标表是否和正文图表一一对应；图表里出现表里查不到的数字，说明手抄环节出了问题

一份合格的实验报告，不要求结论多漂亮，只要求别人照着你的记录能跑出同样的趋势。