企业官网建设流程全解析

1. 为什么“记忆归属”成了本地大模型落地的第一道坎

把大模型跑在自己机器上，这件事在两年前还属于极客圈的自娱自乐，现在已经变成很多团队认真评估的方案。但真正动手做过的人都会发现，模型权重下载下来只是开始，真正让人头疼的是另一件事：模型记住的东西，到底存在哪、归谁管、能不能带走。

我最初接触这个方向，是因为一个做企业内部知识助手的需求。对方的核心诉求很朴素：员工问的问题涉及内部流程和客户资料，这些内容不能离开自己的设备。模型可以本地跑，但对话历史、检索到的文档片段、用户偏好这些“记忆”，如果还散落在各个云端服务的数据库里，那本地部署就只是个心理安慰。这就是标题里说的“AI记忆归属”问题——它不是一个哲学问题，而是一个非常具体的工程问题：记忆的存储位置、访问权限、迁移能力，决定了这套系统到底是不是真的属于你。

围绕这个核心，我把方案拆成了三块来验证：本地大模型负责推理，Qdrant 负责向量记忆的存储与检索，Edge 侧负责在资源受限的环境里把这两者串起来。Qdrant 是一个开源的向量数据库，专门用来存和查高维向量，也就是把文本、图片这些东西转成一串数字之后做相似度匹配。Edge 这个词在这里指的是边缘侧部署，通俗讲就是把整套东西塞进一台性能不算强的机器里，比如一台普通笔记本、一台小型工控机，甚至是一个单板计算机。

这套组合能解决的问题很明确：让 AI 的“长期记忆”完全落在你自己的硬盘上，检索过程不依赖任何外部服务，模型换掉、数据库换掉、机器换掉，记忆都能跟着走。适合谁来参考？我认为有三类人值得往下看：一是正在做本地知识库的开发者，二是对数据主权有硬性要求的团队技术负责人，三是单纯想搞清楚 RAG（检索增强生成）在离线环境下怎么落地的手工爱好者。下面我会把整个思路、关键参数、实操步骤和踩过的坑一次讲清楚。

2. 整体架构设计与选型背后的取舍逻辑

2.1 为什么是“本地模型 + Qdrant + Edge”这个组合

先说说为什么没有选更省事的方案。最省事的做法是直接用某个云端 API 做推理，向量库也用托管服务，代码量最少，效果也稳定。但这个方案在“记忆归属”这个命题下直接出局，因为你的对话记录和文档向量都在别人的服务器上，谈归属没有意义。

那退一步，本地跑模型，向量库用本地文件比如 FAISS 或者 Chroma 行不行？行，我一开始就是这么干的。FAISS 很轻，Chroma 上手也快，但它们有个共同问题：当记忆量涨到几十万条向量、需要按元数据过滤、需要持久化并且支持并发读写的时候，维护成本会陡增。FAISS 本质上是个索引库，不是数据库，元数据过滤要自己在外层再包一层；Chroma 早期版本在持久化和并发上踩过不少坑。Qdrant 的定位正好卡在中间：它是正经的向量数据库，支持 payload 过滤、支持持久化、有 HTTP 和 gRPC 两套接口，而且可以编译成比较轻量的形态跑在边缘设备上。

至于 Edge，它不是某个具体产品，而是一种部署约束。你要假设这台机器内存可能只有 8GB 到 16GB，没有独立显卡，磁盘是普通 SSD，网络时断时续。在这个约束下做设计，很多在服务器上理所当然的选择都要重新考虑，比如模型量化等级、向量维度、批量写入的大小。这个约束反过来也逼着我把架构做得更干净，因为资源不够，就没法堆冗余组件。

2.2 记忆分层的设计思路

我把“AI 记忆”拆成了三层，这个分层是后面所有实操的基础，值得单独说清楚。

第一层是会话记忆，也就是当前这轮对话的上下文。这部分通常放在内存里，用滑动窗口或者摘要的方式控制长度，它的生命周期就是一次会话，关掉就没了。第二层是长期记忆，也就是跨会话要保留的东西，比如用户之前问过什么、系统检索过哪些文档片段、哪些回答被标记为有用。这部分才是真正需要“归属”的部分，也是要落到 Qdrant 里的。第三层是知识记忆，也就是外挂的文档库，它相对静态，更新频率低，但体量大。

为什么要分三层？因为它们的读写模式完全不同。会话记忆是高频写、高频读、生命周期短；长期记忆是中频写、高频读、需要持久化；知识记忆是低频写、高频读、体量大。如果混在一起存，要么浪费资源，要么查询变慢。分开之后，每一层可以用不同的存储策略，比如会话记忆直接用内存字典，长期记忆用 Qdrant 的一个 collection，知识记忆用另一个 collection，检索的时候按需路由。

提示：分层不是越多越好。我见过有人把记忆拆成五六层，结果光是维护层与层之间的同步逻辑就写了几百行代码，最后收益还不如老老实实两层。三层是我实测下来在边缘设备上比较平衡的划分。

2.3 边缘侧的资源预算怎么算

在动手之前，先算一笔账，这决定了后面所有参数的选择。假设目标设备是 16GB 内存、4 核 CPU、无独显、512GB SSD。

模型这边，一个 7B 参数量的模型，如果用 4-bit 量化，权重大概占 4GB 左右，推理时的 KV Cache 根据上下文长度浮动，2K 上下文大概再占 1GB 到 2GB。向量库这边，Qdrant 本身进程占用不大，几百 MB 级别，但向量数据要算清楚：假设用 768 维的向量，每条向量用 float32 存就是 768 × 4 = 3072 字节，约 3KB。十万条向量就是约 300MB，加上 payload 和索引开销，按 1.5 倍算大概 450MB。这个量级在 16GB 机器上完全放得下。

真正吃资源的是检索时的计算。Qdrant 默认用 HNSW 索引，建索引的时候吃内存和 CPU，查询的时候也吃。在 4 核 CPU 上，十万条向量的查询延迟大概在几十毫秒级别，可以接受。但如果向量量级涨到百万，边缘设备就吃力了，这时候要么降维度，要么做分片，要么把知识记忆层挪回稍微强一点的机器。这个预算表建议你在动手前也自己算一遍，因为不同设备的瓶颈位置不一样。

3. 核心细节拆解与实操前的关键准备

3.1 本地模型的量化选择与推理框架

模型这块，边缘设备上基本只有量化模型可选。量化的核心思路是把原本用 16 位或 32 位浮点数存的权重，压缩成 8 位、4 位甚至更低的整数，代价是精度损失。常见的量化等级有 Q8、Q5、Q4、Q3，数字越小压缩越狠，效果损失越大。

我的实测经验是：Q4 是边缘设备上的甜点区。Q8 效果最好但体积翻倍，在 16GB 机器上留给向量库和系统的空间就紧张了；Q3 体积最小但回答质量下降明显，尤其是需要推理和多步理解的问题，经常答非所问。Q4 在体积和效果之间平衡得比较好，7B 模型压到 4GB 出头，回答质量在日常问答和文档检索场景下够用。

推理框架方面，常见的有几类：一类是专门为本地推理优化的运行时，一类是基于通用深度学习框架自己搭。我倾向于用前者，因为边缘设备上自己搭框架要处理的兼容性问题太多，比如不同 CPU 指令集的优化、内存分配策略、多线程调度。选一个成熟的本地推理运行时，把精力留给记忆层和检索逻辑，性价比更高。

注意：量化模型的文件格式在不同运行时之间不一定通用。选运行时之前先确认它支持哪些格式，否则你可能下载了一个模型却发现跑不起来，白白浪费时间。

3.2 Qdrant 的部署形态与 Edge 适配

Qdrant 的部署方式有好几种：Docker 容器、二进制文件、源码编译。在边缘设备上，我推荐用二进制文件或者轻量容器。Docker 在资源受限的设备上会额外吃一层开销，而且如果设备本身没有容器运行时，装 Docker 又是一堆事。二进制文件直接跑，进程干净，内存占用可控。

Qdrant 的配置文件里几个关键参数需要根据边缘设备调整。第一个是storage路径，一定要指向 SSD 而不是机械盘或者网络挂载盘，向量检索对随机读很敏感。第二个是hnsw_config里的m和ef_construct，m是每个节点在 HNSW 图里的连接数，默认 16，边缘设备上可以降到 8 到 12，减少内存占用；ef_construct是建索引时的搜索宽度，默认 100，可以降到 64，建索引更快。第三个是optimizers里的memmap_threshold，这个参数控制什么时候把数据从内存映射到磁盘，边缘设备内存小，可以把这个阈值调低，让 Qdrant 更早地把冷数据放到磁盘上。

这里有个容易忽略的点：Qdrant 的 collection 一旦建好，部分参数就不能改了，比如向量维度。所以建 collection 之前一定要想清楚维度是多少，因为维度取决于你用的 embedding 模型。换 embedding 模型意味着要重建整个 collection，十万条数据重新 embedding 一遍可能要跑几个小时。我的做法是先用小批量数据把 embedding 模型定下来，确认效果满意了再全量灌数据。

3.3 Embedding 模型的选择与维度权衡

Embedding 模型负责把文本转成向量，它的选择直接决定了检索质量。边缘设备上选 embedding 模型，主要看三点：模型体积、推理速度、维度。

模型体积方面，几百 MB 级别的模型在边缘设备上跑得动，几个 GB 的就吃力了。推理速度方面，单条文本 embedding 最好控制在几十毫秒以内，否则用户提问之后要等太久。维度方面，常见的有 384、768、1024 等，维度越高表达能力越强，但存储和检索开销也越大。

我的建议是：如果知识库以中文为主，优先选在中文语料上训练过的模型；如果中英文混合，选多语言模型。维度上，768 维是个比较稳妥的选择，384 维省资源但检索精度会打折扣，1024 维效果好但边缘设备上存储压力大。这个权衡没有标准答案，取决于你的数据量和精度要求。

还有一个实操细节：embedding 模型和生成模型最好用同一套 tokenizer 或者至少确认兼容性，否则在拼接检索结果和用户问题时可能出现截断或者乱码。我踩过一次坑，检索出来的文档片段拼进 prompt 之后，模型回答里出现了奇怪的符号，排查半天才发现是两套 tokenizer 对特殊字符的处理不一致。

4. 完整实操流程与关键环节实现

4.1 环境搭建与依赖安装

先把基础环境搭起来。假设目标设备是 Linux 系统，有 Python 环境。第一步是创建独立的虚拟环境，避免污染系统 Python。

python3 -m venv ai_memory_env source ai_memory_env/bin/activate

第二步是安装 Qdrant 客户端和 embedding 相关依赖。Qdrant 提供了 Python 客户端，用起来比较顺手。

pip install qdrant-client pip install sentence-transformers

第三步是下载 Qdrant 服务端二进制文件。从官方发布渠道拿到对应架构的二进制之后，放到一个固定目录，比如/opt/qdrant，然后写一个简单的启动脚本。

/opt/qdrant/qdrant --config-path /opt/qdrant/config.yaml

配置文件里我调整过的几个关键项：

storage: storage_path: /data/qdrant_storage service: http_port: 6333 grpc_port: 6334 hnsw_config: m: 10 ef_construct: 64 optimizers: memmap_threshold_kb: 20000

memmap_threshold_kb设成 20000 意思是超过 20MB 的段就用内存映射，边缘设备内存小，这个值可以再调低。

4.2 建立记忆 Collection 与向量写入

Qdrant 里数据是按 collection 组织的，一个 collection 里的向量维度必须一致。我建了两个 collection，一个存长期记忆，一个存知识记忆。

from qdrant_client import QdrantClient from qdrant_client.models import Distance, VectorParams client = QdrantClient(host="localhost", port=6333) client.create_collection( collection_name="long_term_memory", vectors_config=VectorParams(size=768, distance=Distance.COSINE) ) client.create_collection( collection_name="knowledge_base", vectors_config=VectorParams(size=768, distance=Distance.COSINE) )

Distance.COSINE是余弦距离，适合文本向量，因为它只看向量方向不看向量长度，对文本长度差异不敏感。如果你的 embedding 模型输出已经归一化了，用点积也可以，速度更快。

写入数据的时候，每条记录包含三部分：id、向量、payload。payload 是附加的元数据，比如原文、时间戳、来源、标签。payload 的设计很关键，因为后面检索的时候要靠它做过滤。

from qdrant_client.models import PointStruct points = [ PointStruct( id=1, vector=embedding_vector, payload={ "text": "原始文本内容", "source": "内部文档A", "timestamp": 1700000000, "tags": ["流程", "审批"] } ) ] client.upsert(collection_name="knowledge_base", points=points)

批量写入的时候，一次不要塞太多。我实测在边缘设备上，一次写 100 到 200 条比较稳，一次写几千条容易把内存打满。如果数据量大，写个循环分批写，每批之间稍微 sleep 一下，给系统喘息时间。

4.3 检索逻辑与记忆召回策略

检索是整套系统的核心。用户提问之后，先把问题 embedding 成向量，然后去 Qdrant 里查最相似的若干条记录。

query_vector = embed_model.encode("用户的问题") results = client.search( collection_name="knowledge_base", query_vector=query_vector, limit=5, query_filter=None )

limit=5是召回条数，这个数字需要调。召回太少，可能漏掉关键信息；召回太多，拼进 prompt 之后上下文太长，模型推理变慢，而且可能引入噪声。我的经验是：知识记忆召回 3 到 5 条，长期记忆召回 2 到 3 条，加起来控制在 8 条以内。如果发现回答质量不够，优先优化 embedding 模型和分块策略，而不是盲目加大召回数量。

分块策略这里展开说一下。文档不能整篇 embedding，要切成小块。块太大，检索精度下降；块太小，语义不完整。常见做法是按段落切，每块 200 到 500 字，块之间留一点重叠，避免关键信息正好被切断。重叠部分一般取块大小的 10% 到 20%。

检索的时候还可以加过滤条件，比如只查某个来源的文档，或者只查最近一个月的内容。Qdrant 的 payload 过滤支持等于、范围、包含等操作，用起来比较灵活。

from qdrant_client.models import Filter, FieldCondition, MatchValue query_filter = Filter( must=[ FieldCondition( key="source", match=MatchValue(value="内部文档A") ) ] )

4.4 把检索结果拼进本地模型的 Prompt

检索出来的内容要拼成 prompt 喂给本地模型。这里有个模板设计的技巧：把检索到的内容放在明确的标记之间，并且告诉模型这些是参考资料，不是用户指令。否则模型可能把文档里的句子当成用户的要求来执行，出现奇怪的行为。

一个我常用的模板结构：

你是一个知识助手。请根据下面的参考资料回答用户问题。 如果参考资料中没有相关信息，直接说不知道，不要编造。 参考资料： [1] 文档片段内容... [2] 文档片段内容... 用户问题：xxx 回答：

这个模板看起来简单，但每一句都有用。“根据参考资料回答”约束了模型的信息来源，“没有就说不知道”抑制了幻觉，“不要编造”是双重保险。我试过去掉其中任何一句，回答质量都会下降。

本地模型推理的时候，注意控制总上下文长度。边缘设备上，上下文越长，KV Cache 越大，推理越慢。如果检索结果拼起来超过模型的最大上下文，要么截断，要么减少召回条数。我一般把总上下文控制在 2K 到 4K token 之间，具体取决于设备性能。

4.5 记忆的持久化与迁移验证

“记忆归属”这个命题的最终检验标准是：能不能把记忆完整地带走。Qdrant 的数据都在storage_path指定的目录里，把这个目录打包拷到另一台机器，启动 Qdrant 指向这个目录，数据就回来了。这个过程我实测过，十万条向量的 collection，打包大概几百 MB，拷贝加启动不到十分钟。

但有几个细节要注意。第一，Qdrant 的版本要一致，大版本之间存储格式可能不兼容。第二，拷贝之前最好先停掉 Qdrant 进程，或者用它的快照功能，避免拷贝到一半数据在写入导致不一致。第三，payload 里的时间戳、来源这些元数据是跟着向量一起走的，不用担心丢失。

迁移验证的步骤：

1. 在源机器上停掉 Qdrant，打包 storage 目录。
2. 把压缩包拷到目标机器，解压到相同路径。
3. 在目标机器上启动同版本 Qdrant。
4. 用同样的查询向量做检索，对比结果是否一致。

如果结果一致，说明记忆完整迁移了。这个验证做完，你才真正拥有了这份记忆。

5. 常见问题与排查技巧实录

5.1 检索结果不相关怎么办

这是最常见的问题。排查顺序我一般是这样的：先看 embedding 模型是否适合你的语料，中文语料用英文模型效果肯定差；再看分块是否合理，块太大或者切分位置不对都会影响；最后看召回数量，太少可能漏掉，太多引入噪声。

有一个容易被忽略的点：查询和文档要用同一个 embedding 模型。我见过有人文档用一个模型 embedding，查询用另一个模型，结果检索出来的东西完全不沾边。这个错误很低级但确实有人犯。

还有一个技巧：如果检索结果总是差一点，可以试试把用户问题改写成更接近文档表述的形式再检索。比如用户问“报销怎么弄”，文档里写的是“费用报销流程”，直接检索可能匹配不上，但如果先把问题改写成“费用报销流程是什么”，匹配度就上去了。这个改写可以用本地模型来做，增加一点延迟但效果提升明显。

5.2 边缘设备内存不够怎么优化

内存不够的表现通常是：Qdrant 进程被系统杀掉，或者模型推理时报内存分配失败。优化方向有几个。

第一，降低模型量化等级，从 Q5 降到 Q4 甚至 Q3，权重占用直接减半。第二，减小 Qdrant 的 HNSW 参数，m从 16 降到 8，内存占用能降不少。第三，调整memmap_threshold，让更多数据走磁盘映射而不是常驻内存。第四，减少召回数量，降低单次查询的内存峰值。第五，如果设备支持，加一条 swap 分区作为兜底，但要注意 swap 在 SSD 上频繁读写会影响寿命。

我个人的优先级是：先调 Qdrant 参数，再降召回数量，最后才动模型量化等级，因为量化等级对回答质量的影响最直接。

5.3 写入速度慢或者写入失败

批量写入慢，通常是批次太大或者索引构建太频繁。Qdrant 在写入时会异步建索引，如果写入速度超过建索引速度，会积压。解决办法是减小批次，并且在写入大批量数据之前，先把hnsw_config里的ef_construct调低，等数据写完再调回来重建索引。

写入失败常见原因是向量维度不匹配，或者 id 重复。维度不匹配会在客户端就报错，比较好排查。id 重复的话，Qdrant 默认是 upsert 语义，相同 id 会覆盖，如果你不希望覆盖，要自己生成唯一 id。

还有一个坑：payload 里的字段类型要一致。比如timestamp一会儿是整数一会儿是字符串，Qdrant 在过滤的时候会报类型错误。建 collection 的时候最好把 payload 的 schema 想清楚，后面改起来麻烦。

5.4 模型回答质量不稳定的排查

回答质量不稳定，可能的原因很多，我整理了一个速查表。

temperature 这个参数控制输出的随机性，设得太高回答会发散，设得太低会死板。边缘设备上的知识问答场景，我一般设 0.1 到 0.3 之间。重复惩罚参数用来抑制模型复读，设 1.1 到 1.2 比较合适，太高会导致用词怪异。

5.5 实操避坑清单

最后整理一份我踩过坑之后总结的清单，都是文档里不会写但实际会遇到的。

• 建 collection 之前一定确认向量维度，建完改不了。
• embedding 模型和生成模型的 tokenizer 要确认兼容。
• 批量写入批次控制在 100 到 200 条，别贪多。
• Qdrant 的 storage 目录不要放在网络盘上。
• 迁移数据前先停进程或者用快照。
• prompt 模板里一定要有“不知道就说不知道”。
• 召回数量不是越多越好，8 条以内比较稳。
• 定期检查 Qdrant 的日志，看有没有内存告警。
• 模型量化等级和回答质量要做 A/B 对比，别凭感觉选。
• 记忆迁移验证要做完整，不能只看数据在不在，要看检索结果一致不一致。

这套东西我在几台不同配置的设备上都跑过，从 8GB 内存的老笔记本到 32GB 的小型工作站，核心逻辑没变，变的只是参数。真正让“记忆归属”成立的，不是某个具体工具，而是这套分层设计加上可迁移的存储格式。工具会换，模型会升级，但只要记忆的存储和检索逻辑掌握在自己手里，换什么都是平滑的。