想象一下,你到一座陌生城市找一个“笑起来像高中同桌的人”。你没有具体地址,但你知道他平时混迹于几个固定圈子。你找到一位消息灵通的大佬,大佬把你引荐给认识他的人,经他带路,再找到目标圈子里最熟的那几个朋友——三层人脉就能锁定任务目标。这个“人脉金字塔”就是 HNSW(Hierarchical Navigable Small World,层级化小世界图)的底层逻辑。它先把海量向量搭成一张多层“熟人网络”,搜索时从顶层的大佬开始,一层层下潜到普通用户,用极少的比较次数找到最相似的向量。Milvus 把这张网络变成可配置的索引:M 管圈子大小,efConstruction 管建房时的人力投入,efSearch 管找人时愿意问多少人。读完这篇文章,你会从直觉到参数,彻底看懂 HNSW 这个向量数据库里的“寻人引擎”。
对 AI 从业者而言,理解 HNSW 是驾驭 Milvus 这类向量数据库的必修课:你会知道为什么索引建得慢,为什么调大 efSearch 能提召回,也知道如何在“快”与“准”之间做出理性取舍,而不是靠玄学调参。
可视化演示
展示HNSW层次化小世界图的三层结构、贪心搜索逐层下降流程与参数调优效果,支持步骤切换与参数调节。
本节配有交互动效(进入视口后自动加载,约 3KB)。
HNSW层次化图结构 L2层稀疏入口节点 L1/L0层逐步密集 Layers: L2→L1→L0 HNSW通过分层小世界图实现快速近似最近邻搜索
向量检索基础
你初到一座城市,想找一个“笑起来像高中同桌的人”。如果没有照片和地址,你得把记忆中那些零碎的印象——爱穿格子衬衫、讲话带南方口音、常在天台喝咖啡——变成一套可描述的“特征”,才能在人群中比对。向量检索做的事正是如此:给每条数据发一张“性格画像”,画像越准确,找起来越顺手。
AI 模型会把文本、图片、声音等一切信息转换成一串数字,这串数字就叫向量。比如“猫”的向量可能像 (0.2, 0.8, 0.5),“狗”的向量是 (0.3, 0.7, 0.4)。向量检索的目标就是找到目标向量最像的邻居,专业说法是“最近邻搜索”(Nearest Neighbor Search)。
最朴素的做法是暴力搜索:把所有向量和查询向量逐一比对,距离最近的留下。就像你拿着画像挨个问遍全城的人,一万人要问一万次,一千万人要问一千万次,查询量大时完全扛不住。于是大家开始用“近似最近邻搜索”,允许结果和真正最近邻“差不多像”,换取速度。衡量“差不多像”的指标就是召回率。
1. 第1步:计算点积:把两个向量在同一维度上的值相乘再累加,结果可以理解为“共同语言”的总量。
2. 第2步:计算模长:分别算出两个向量的“长度”,即每个向量与原点之间的直线距离。
3. 第3步:归一化:用点积除以两个模长的乘积,消除向量长度的影响,只比较方向。
回到找回同桌的例子:画像只是参考,真正决定找得快不快的是你手里那张“人脉网”。暴力搜索是挨个敲门,而 HNSW 选择先把城市里的人组织起来。
HNSW核心思想
假设你认识一位“人脉王”,他认识各行各业的圈子领袖;每个圈子领袖又认识一群普通朋友。你要找那个爱喝咖啡的人,只需要让大佬推荐一位消息灵通的熟人,熟人再带你去目标街区的咖啡店,问题就解决了。这个人脉金字塔的精髓叫“六度分隔”——任何两个人之间最多隔着六层关系。
HNSW 把这种直觉带入了算法世界。它从社会学中的“小世界网络”获得灵感,又借鉴了跳表(Skip List)的分层机制:数据组织成多层图,层数越高节点越少,底层则包含全量节点。搜索时从最高层出发,利用高层“长距离跳跃”快速定位区域,再逐层下潜到低层精细查找。这就像在大型商场里找店铺,先看总览图确定楼层,再看楼层索引确定方向,最后在店铺门口核对门牌。
小世界网络之所以“小”,是因为少数关键节点充当了桥。HNSW 建图时也刻意让每个节点偏向连接“容易找到”的邻居。究竟该把节点放到哪一层?算法用指数分布来决定层数,这样绝大多数节点待在底层,只有少数节点登顶。
1. 第1步:识别层编号:l 表示候选者想上到的层数,从 0 开始,0 是最底层、人最多。
2. 第2步:看指数衰减:分母 M 越大,整个指数值衰减越平缓;M 越小,高层节点越稀有。
3. 第3步:得到选层概率:对 -l/M 取自然指数,得到该节点出现在第 l 层的概率。
每个人脉金字塔都有设计图纸,但真正决定这个网络好不好用的是“谁和谁连在一起”。HNSW 的建图规则就在第三节。
图结构构建
这张人脉网络是靠什么建起来的?想象你加入一个陌生社团,为了快速融入,你不会加遍所有人,而是精心挑选几位离你最近、最聊得来的朋友,并记下他们的电话。HNSW 建图时也一样:每个新节点插入时,只和当前图上“最相似的几个节点”建立边,边的数量上限就是参数 M。
底层图中,每个节点会尽力连接 M 个距离最近的邻居;高层图则更稀疏,只为快速导航。建图时先随机给节点分配一个层数,然后从最高层开始逐层插入:每层用贪心方式找到该层离它最近的 efConstruction 个候选节点,从中挑出 M 个建立连接。这样构造出来的图,既保证底层的覆盖度,又保留高层的“捷径”。
节点之间的距离怎么算?Milvus 支持欧氏距离、内积、余弦距离等多种度量,其中欧氏距离最直观:它衡量两个点在多维空间中的直线长度。选哪种距离,取决于业务更看重“方向相似”还是“绝对差距”。
1. 第1步:逐维求差:对每一维计算 p_i 与 q_i 的差,差越大说明这一维离得越远。
2. 第2步:平方累加:求差后再平方并全部相加,避免正负抵消,同时放大离群维度的影响。
3. 第3步:开根号还原:对累加和开根号,得到实际空间中的直线距离,单位与原始维度一致。
好友名单定好之后,真正考验这张网的是“找人”的流畅度。下一节我们来看搜索动作如何在这张网上滑行。
搜索路径
现在人脉网已经建好,你要找那个“爱喝咖啡的人”。第一步,你找到顶层的大佬,问:“离这个人最近的是谁?”大佬看了看,指出中层的 A 女士。你继续问 A 女士,她带你找到了目标街区的 B 先生。最后由 B 先生的邻居们包围目标,精确锁定。整个过程就叫贪心搜索——每一步都只在当前熟悉的人里选离目标最近的,不走回头路。
HNSW 的搜索从最高层的入口点开始,在当前层的邻居集合中反复挑选与查询向量距离最近的节点,直到邻居不再更接近目标,就下降到下一层重复这个过程。到了底层后,再以某几个入口节点为中心,把候选名单扩大到 efSearch 个,从中选出最相似的 k 个作为最终结果。efSearch 就是“你愿意打听多少人”,数值越大,候选池越大,但查询耗时也更长。
这里的关键是贪心更新:每次都要从当前节点的邻居里挑出距离目标最近的节点作为下一步落脚点。由于图的连接质量较高,这个局部最优往往能通向全局较优。
1. 第1步:查看邻居集合:N(v) 表示当前节点 v 的朋友列表,只包含 M 个以内的邻居。
2. 第2步:逐一计算距离:对每个邻居 u,计算它到查询向量 q 的欧氏距离。
3. 第3步:取最小者:arg min 表示从中选出距离最小的那个邻居,作为下一跳。
你在人脉网上的每步行走都与参数密切相关:愿意问多少人、愿意让每个人有多少朋友,这些旋钮就在 Milvus 的配置面板上。
Milvus参数配置
开车的人都熟悉仪表盘:油门控制动力,刹车控制停下,方向盘控制方向。Milvus 里 HNSW 索引也有三个核心旋钮——M、efConstruction、efSearch。M 是每个人的“好友上限”,决定图的密度;efConstruction 是建图阶段的人力投入,决定每个新朋友入网时要问多少人;efSearch 是查询阶段找人时的打听力度,决定候选名单的宽度。
在 Milvus 的索引配置中,M 默认通常为 4,范围一般在 2 到 64。M 越大,图上边越多,信息越丰富,但内存占用和构建时间也线性上增。efConstruction 默认约为 M 的 8 倍,它只影响构建期的搜索队列大小:值越大,插入节点时越能找到真正适合做邻居的节点,图质量越高,但建索引越慢。efSearch 默认一般为 16 或 64,它直接决定查询时搜索候选范围的宽窄。
这三个参数带来的资源开销是可以估算的。每条有向边需要存一个邻居编号,加上节点的坐标和层级信息,整体内存近似正比于 M 乘 N。理解这个公式,就能明白为什么盲目加大 M 会让集群内存迅速告急。
1. 第1步:确定好友数:M 是每个节点平均维护的邻居数量,边越多图越大。
2. 第2步:乘以节点总数:N 个节点,每个节点都维护 M 条边,边的总量约 M × N。
3. 第3步:换算字节数:每条边加上反向指针和元数据,简化后约 16 字节。
旋钮就在手边,关键是怎么拧。下一节我们把“速度”和“精度”放在同一个杯子里,看看如何调出最佳风味。
调优策略
调 HNSW 参数就像点奶茶:全糖甜腻、无糖太苦,真正的快乐在“三分甜”。速度与精度的关系亦如此——数据越大,你越不能指望“又快又全对”。调优不是把参数拉到最大,而是找到业务能接受的甜点区间。
实践中建议先定 M,再调 efSearch。为什么不先调 efSearch?因为 M 决定了整个网络的地基,后期修改 M 通常需要重建索引;而 efSearch 是查询期的软参数,可以在线动态调整,随时观察效果。推荐流程是:先用默认参数建好索引,暴力搜索算出基准召回,然后逐步调大 efSearch,记录延迟和召回率的变化曲线,找到拐点后,再考虑是否用更大的 M 重建索引换取更高上限。
评估调优效果最核心的指标是召回率:你的近似搜索结果和暴力搜索结果重叠了多少。召回率不必追求 100%,在搜索场景中,80% 到 95% 的召回结合秒级响应,往往已经是产品体验的最优解。
1. 第1步:算出标准答案:用暴力搜索找出 top-k 结果,作为 R_brute。
2. 第2步:收集近似结果:用 HNSW 搜索得到 R_ann,规模同样是 k。
3. 第3步:求交集占比:两者交集越大,说明近似搜索越接近暴力搜索。
调好参数后,HNSW 究竟比别的索引好在哪?把它放到不同路况上跑一圈,你就会有体感。
性能对比
选索引如同选车:越野车擅长山路,跑车擅长高速,城市 SUV 样样通但样样不极致。IVF(倒排文件)像公交车,先把数据按聚类分成固定线路,查询时只查几条线路附近的站点,简单高效但长距离跳跃能力弱;HNSW 像打车软件,通过多层网络随时找到直达路径,查询延迟对数据规模增长更平缓;SCANN 像包了一辆高档专车,通过压缩向量和矩阵乘法加速取数,精度好但内存开销大、构建时间长。
从数据规模看,百万级以下向量,IVF 和暴力搜索已经够用;百万到千万级,HNSW 通常表现出更低的查询延迟和更高的召回率;当数据集达到亿级且对召回要求很高时,SCANN 这类基于矩阵运算的方法可能有优势,但工程复杂度也更高。Milvus 内部允许按场景混合使用多种索引,比如先用 IVF 粗筛再用 HNSW 精排。
HNSW 的查询复杂度接近对数级别,这是它在大规模数据中仍能保持低延迟的底气。
1. 第1步:认识对数:log 是以 2(或 e)为底的对数,N 扩大 10 倍,log N 只增加约 3.3。
2. 第2步:看作跳数:每层缩小搜索范围,跳数近似等于层数,即 log N 的量级。
3. 第3步:整体复杂度:每跳还要检查 M 个邻居,因此总复杂度 O(M × log N),M 是常数。
车选好了,还得知道往哪开。最后一节看看 HNSW 在真实业务里最常见的三个用武之地。
应用实践
工具箱里的扳手,用对地方才顺手。HNSW 特别适合“数据规模大、查询延迟敏感、结果容忍近似”的场景。第一种是语义搜索:用户输入一段自然语言,系统把它编码成向量,在千万商品描述中找回语义相似的条目;第二种是推荐系统召回:用户向量与物品向量的相似度决定候选池,HNSW 在毫秒级给出候选;第三种是文本去重:判断一篇文章是否与已有内容高度重复,本质上就是找最近邻。
选型建议上,如果你的数据量小于 10 万且 QPS 要求不高,暴力搜索或 IVF 即可;如果数据在百万到千万级、embedding 维度 128 到 768 之间,HNSW 是稳妥起点;如果内存紧张、构建时间敏感,可以考虑压缩类索引或者给 HNSW 调小 M。Milvus 中切换索引类型和参数都通过 index params 配置,方便 A/B 测试。
这类在线检索服务最终看的吞吐指标是 QPS——每秒能处理多少个查询。HNSW 的低跳数特性让 QPS 在高并发下依然坚挺。
1. 第1步:统计查询总量:N_queries 是压测周期内成功返回的查询请求数。
2. 第2步:记录总耗时:T_total 是这些查询消耗的总秒数,包括排队和处理时间。
3. 第3步:相除得到吞吐:QPS 越高,说明系统每秒能服务更多用户。
从画像到人脉金字塔,再到拧参数、看指标,HNSW 这台“寻人引擎”你已经完全拆解过了。
AI 应用场景
电商语义搜索
阶段:检索召回
解决的问题:传统电商搜索靠关键词精确匹配,用户搜“显瘦的连衣裙”时难以理解“显瘦”这种语义;HNSW 让商品向量与查询向量做近邻搜索,把“语义上相似”的商品一次性召回,再交给精排模型。
具体案例:某服装电商平台将 500 万商品描述输入 Embedding 模型生成 768 维向量,Milvus 中建 HNSW 索引(M=16,efConstruction=128,efSearch=64),搜索延迟从原来 ES 的 120 毫秒降到 8 毫秒,召回率稳定在 92% 左右。就像人脉网里从顶层大佬直接锁定目标街区,不再挨家挨户翻关键词。
推荐系统用户召回
阶段:候选生成
解决的问题:传统协同过滤需要预先计算用户与物品的相似度矩阵,存储开销大且无法实时更新;HNSW 支持动态插入新向量,新用户或新物品上线后能立即被检索到,适合大规模实时推荐召回。
具体案例:某短视频平台的“猜你喜欢”模块,把用户行为序列编码成向量,在 Milvus 中用 HNSW 召回与当前用户最相似的 1000 个内容候选。由于 HNSW 底层图支持增量更新,新发布的视频 30 秒内就能进入候选池,带来次日留存率 3 个百分点的提升。
论文与文档查重
阶段:相似度检测
解决的问题:传统查重依赖 n-gram 重叠,对改写句子无能为力;把文档切块后编码成向量,用 HNSW 检索近似重复片段,能识别语义级抄袭,且不需要两两比对全量文档。
具体案例:某学术平台收录 3000 万篇论文,将每篇摘要转为向量并建立 HNSW 索引,投稿时对新的稿件摘要在 20 毫秒内返回最相似的历史论文,查重准确率从 78% 提升到 94%,误报率大幅下降。
Python 演示
import mathimport random class SimHNSW: def __init__(self, M=8, ef_construction=20, top_k=5): self.M = M self.ef_construction = ef_construction self.top_k = top_k self.vectors = [] self.top_nodes = [] def _dist(self, a, b): return math.sqrt(sum((x - y) ** 2 for x, y in zip(a, b))) def build(self, vectors): self.vectors = vectors # 每隔固定间隔抽取一个节点作为顶层入口 for i in range(0, len(vectors), 20): self.top_nodes.append(i) def _greedy(self, query, candidates, k): # 在候选集合里贪心找出距离最近的k个 ranked = sorted(candidates, key=lambda i: self._dist(query, self.vectors[i])) return ranked[:k] def search(self, query, ef_search=10): # 顶层找1个最近入口,再向附近扩展候选池 entry = self._greedy(query, self.top_nodes, 1) pool = list(entry) for idx in entry: start = max(0, idx - self.M) end = min(len(self.vectors), idx + self.M) pool.extend(range(start, end)) results = self._greedy(query, pool, ef_search) return results[:self.top_k] def brute_topk(query, vectors, k): ranked = sorted(range(len(vectors)), key=lambda i: math.sqrt(sum((x-y)**2 for x,y in zip(query, vectors[i])))) return ranked[:k] def main(): random.seed(42) vectors = [[random.random() for _ in range(8)] for _ in range(400)] model = SimHNSW(M=8, ef_construction=20, top_k=5) model.build(vectors) query = [random.random() for _ in range(8)] ann = model.search(query, ef_search=10) brute = brute_topk(query, vectors, 5) hit = len(set(ann) & set(brute)) / 5 print("HNSW top5:", ann) print("暴力 top5:", brute) print("召回率: %.2f" % hit) if __name__ == "__main__": main()
for i in range(0, len(vectors), 20): self.top_nodes.append(i)每 20 个节点挑一个作为顶层“人脉大佬”,让搜索先定位大方向。entry = self._greedy(query, self.top_nodes, 1)在顶层挑一个离目标最近的入口点,相当于先问大佬“该去找谁”。pool.extend(range(start, end))把入口点附近 M 个邻居拉进候选池,模拟进入底层后向邻居打听消息。results = self._greedy(query, pool, ef_search)在候选池中挑 ef_search 个最近邻,相当于扩大打听范围提升准确度。hit = len(set(ann) & set(brute)) / 5用交集比例算召回率,回答“近似结果和标准答案有多少重合”。
常见误区
误区朋友越多信息越全,M 调到 64、128,检索肯定更快更准。
正解M 增大确实让图连接更丰富、召回率提升,但内存和构建时间也线性增长,而且 M 超过一定值后召回增益快速衰减,反而拖慢查询(每跳要比较更多邻居)。就像你加遍全城人的微信,找人理论上更容易,但通讯录翻起来也累。建议从 M=16 起步,用数据说话。
为何常见:直觉认为“连接越多越好”,忽略了图搜索每跳都要遍历邻居,边数多导致取邻居、算距离的总量变大。
误区调大 efConstruction 查询也会变快,反正都是“搜索宽度”。
正解efConstruction 只作用于索引构建期,影响图质量已经定型;查询时真正生效的是 efSearch。改 efConstruction 后如果不重建索引,查询效果不会变化。类比装修房子:efConstruction 是施工时请多少监理,efSearch 是入住后找东西时愿意翻多少个抽屉,两者不是一回事。
为何常见:名字都带 ef,单词还一样,初学者自然以为一个参数管到底。
误区近似搜索不准就是垃圾,必须和暴力搜索结果完全一致。
正解HNSW 的意义就是在延迟和召回之间取平衡。实际业务中 95% 召回配合 10 毫秒延迟,往往远优于 100% 召回配合 200 毫秒延迟。定位是“近似最近邻”,而非精确最近邻。就像找人时偶尔绕个小路,但最终仍能快速见到人。
为何常见:做算法题时习惯了“答案必须正确”,没有意识到工业搜索是延迟约束下的优化问题。
误区在 Milvus 里改了 M 或 efConstruction,索引会自动更新,查询马上生效。
正解M 和 efConstruction 是构建期参数,索引建好后不会自动重建,必须重新执行建索引操作。efSearch 是查询期参数,可以在请求间动态调整。搞错这一点会导致大量时间花在“调参”上却看不到效果。
为何常见:数据库领域常有“改配置即热加载”的习惯,但向量索引是离线构建的数据结构,参数固化在图中。
误区HNSW 是 Milvus 最常用的索引,那不管数据量多大、维度多高,全用它。
正解数据量小于十万时,暴力搜索更快更省心;维度高达数千且稀疏时,HNSW 的距离计算开销大,IVF 或压缩索引可能更合适;如果对内存极度敏感,基于 PQ 的索引比 HNSW 省得多。选索引是场景题,不是追星题。
为何常见:只看技术文章的推荐结论,忽略“最佳实践依赖数据规模、维度、延迟预算”这一前提。
面试题
Q1. HNSW 中的 "H" 代表什么?
- A.折叠的层级化小世界图← 正确答案
- B.高度可扩展的暴力检索法
- C.混合式近邻哈希索引法
- D.高维空间倒排压缩结构
答案:A。HNSW 全称 Hierarchical Navigable Small World,关键在于“层级化小世界图”——把图分成多层,顶层稀疏、底层稠密。B 说的是暴力搜索,C 是哈希索引,D 是倒排思想,都不是 HNSW 的本质。
Q2. HNSW 搜索时从哪一层开始查找?
- A.从最底层逐层向上查找
- B.从最高层入口点开始← 正确答案
- C.从随机一层开始查找
- D.同时搜索全部层次
答案:B。HNSW 借鉴跳表思路,搜索必须从最高层“大佬层”入口开始,利用高层长边快速定位区域,再逐层向下精化。从底层开始就退化成普通图搜索,随机层则可能错过跳转捷径。
Q3. 参数 M 过大会导致什么典型后果?
- A.召回率必然大幅下降
- B.内存和构建时间上升← 正确答案
- C.查询路径完全失效
- D.索引格式发生改变
答案:B。M 决定每个节点的好友数,M 越大边越多、图越密,内存和构建时间随之上升,这是 HNSW 最直接的代价。召回率通常不会因此下降,反而可能上升;查询路径不会失效,只是每跳比较更多邻居。
Q4. efConstruction 在 Milvus 中的作用是什么?
- A.控制查询时候选队列大小
- B.影响索引构建时的搜索宽度← 正确答案
- C.设置向量维度压缩比例
- D.指定底层节点数量的上限
答案:B。efConstruction 是构建期参数,决定插入节点时要用多大的候选队列寻找邻居,直接影响图的连接质量。查询时的队列大小由 efSearch 控制;向量压缩和底层节点数分别属于其他索引与参数范畴。
Q5. efSearch 越大,通常召回率与查询延迟如何变化?
- A.召回率上升延迟也上升← 正确答案
- B.召回率上升延迟下降
- C.召回率下降延迟也下降
- D.召回率下降延迟上升
答案:A。efSearch 控制查询时候选池的广度,越大代表越愿意多打听,候选向量更多,召回率提升,但比较次数增多、延迟上升。这是一组典型的“速度-精度”权衡,不会出现又准又快的免费午餐。
Q6. 下列对 HNSW 算法类型的描述正确的是?
- A.HNSW 是精确最近邻搜索算法
- B.HNSW 是近似最近邻搜索算法← 正确答案
- C.HNSW 无法处理高维向量数据
- D.HNSW 索引不需要构建阶段
答案:B。HNSW 属于 ANN(近似最近邻搜索),它通过多层图牺牲少量召回换取速度,因此不是精确搜索。它专门为高维稠密向量设计,且必须先构建索引再查询,所以 C、D 明显错误。
Q7. 在 Milvus 中修改 M 之后,下列哪种操作才能让新参数生效?
- A.立即生效无需重建索引
- B.删除旧索引并重新建索引← 正确答案
- C.重启 Milvus 服务自动生效
- D.修改查询节点的参数即可
答案:B。M 是构建期参数,已经建好的图不会自动改变,必须删除旧索引并重建。重启服务只是重新加载旧索引,修改查询参数也无法影响索引结构。重新建索引是唯一可靠的方式。
Q8. 以下哪种场景最适合使用 HNSW 索引?
- A.只有一万条向量的冷启动
- B.千万级向量的低延迟检索← 正确答案
- C.需要精确匹配的主键查询
- D.完全不需要相似度的存储
答案:B。HNSW 的价值在千万级低延迟近似检索中体现最明显;小数据量用暴力搜索更简单;主键精确匹配和不需要相似度的场景根本不需要向量索引。
Q9. HNSW 的主要优势有哪些?
- A.查询延迟随数据规模增长平缓← 正确答案
- B.在高召回需求下延迟依然极低
- C.支持动态插入新的向量节点← 正确答案
- D.适合高维稠密向量的近似查找← 正确答案
答案:ACD。HNSW 的复杂度接近 O(log N),所以 A 正确;HNSW 支持增量插入,C 正确;它是为高维稠密向量设计的图索引,D 正确。B 错误——如果把召回率推到 100% 附近,efSearch 必须很大,延迟会显著上升。
Q10. 调优 HNSW 参数时,合理的操作步骤有哪些?
- A.先用默认参数建立性能基线← 正确答案
- B.同时大幅调大 M 与 efSearch
- C.观察召回率与延迟的变化曲线← 正确答案
- D.针对业务场景逐项参数微调← 正确答案
答案:ACD。调优应“先基准,后单变量,再看曲线”。A 能提供对比参照;C 帮助定位拐点;D 体现场景化微调。B 同时大幅调两个参数会难以判断是谁的贡献,且内存和延迟容易失控,因此不可取。