OpenHuman：构建本地优先、深度个性化的个人AI超级助手

1. 项目概述：当AI助手回归“本地”

最近几年，AI助手这个概念快被说烂了。从手机里的语音助手，到各种云端大模型驱动的聊天机器人，我们似乎已经习惯了“把问题抛出去，等待一个来自远方的答案”这种模式。但不知道你有没有过这样的瞬间：想用AI整理一下自己电脑里积攒多年的照片和文档，却担心隐私泄露；或者想让它深度理解你的工作流和习惯，却发现它对你的了解仅限于几次对话的上下文。云端AI很强大，但它始终像个“外人”。

这就是我今天想聊的OpenHuman这个开源项目让我眼前一亮的原因。它的定位非常清晰：一个真正懂你的、本地优先的个人AI超级助手。简单来说，它不是一个聊天网站，也不是一个API接口，而是一个你可以部署在自己电脑上的“数字大脑”。它的核心目标，是成为你数字生活的延伸，一个完全私密、深度个性化、且能主动为你工作的伙伴。想象一下，你所有的文件、笔记、浏览记录、聊天记录（在获得你授权的前提下）都能被一个本地的AI安全地分析、索引，并据此提供真正契合你需求的帮助——这才是“个人助手”该有的样子。

这个项目适合谁？首先，是像我一样对数据隐私有较高要求的用户。其次，是知识工作者、研究者、创作者，他们拥有大量本地资料，需要AI进行深度梳理和连接。最后，它也适合那些喜欢折腾、希望完全掌控自己数字工具的技术爱好者。OpenHuman不是开箱即用的傻瓜软件，它需要你付出一些部署和调教的精力，但换来的，是一个真正属于你、为你而生的智能体。

2. 核心设计理念与架构拆解

2.1 “本地优先”到底意味着什么？

OpenHuman的“本地优先”不是一句简单的口号，而是贯穿其整个架构的设计哲学。这主要体现为三个层面：

1. 数据本地化：所有你的个人数据，包括文档、笔记、邮件（通过插件）、浏览器历史等，其原始数据和分析后的向量索引，都存储在你自己的硬盘上。AI模型对数据的处理过程完全发生在你的设备内部，没有数据被上传到任何第三方服务器。这从根本上杜绝了隐私泄露的风险，也让你对自己的数据拥有绝对的所有权。

2. 模型本地化（可选）：OpenHuman支持运行本地的大语言模型（LLM）。你可以选择部署像Llama 3、Qwen2.5、DeepSeek等开源模型。这意味着，从问题理解、逻辑推理到最终答案生成，整个智能链条都可以在离线环境下完成。当然，项目也提供了对接云端大模型API（如OpenAI GPT、Claude）的选项，但核心设计鼓励并优先支持本地模型，确保在断网或你不想使用云服务时，助手依然能正常工作。

3. 计算本地化：所有的数据处理、模型推理任务都利用你本机的CPU/GPU资源。这带来两个直接影响：一是性能取决于你的硬件，二是你无需为云端的计算时长付费。对于拥有较强显卡（如消费级RTX 4060以上）的用户，运行一个70亿参数（7B）的量化模型，已经能获得非常流畅的交互体验。

注意：“本地优先”不等于“只能本地”。OpenHuman的架构是灵活的。它的核心是确保你的数据和处理过程的控制权在你手中。模型可以本地运行，也可以按需调用云端API，但你的数据不会因此离开你的设备。这种混合架构在保证隐私的同时，也提供了利用更强大云端模型的可能性。

2.2 如何实现“真正懂你”？—— 个人知识库与记忆系统

一个只会聊天的AI算不上“助手”。OpenHuman实现“懂你”的关键，在于构建了一个动态的、持续更新的个人知识库（Personal Knowledge Base, PKB）。

这个知识库的构建流程可以拆解如下：

1. 数据摄取（Ingestion）：OpenHuman通过一系列“连接器”（Connectors）来获取你的数据。这些连接器就像是助手的感官。

   • 文件系统连接器：扫描并索引你指定文件夹内的文档（PDF、Word、PPT、TXT、Markdown等）。
   • 笔记应用连接器：例如对接Obsidian、Logseq的仓库，直接读取你的双链笔记，理解笔记间的关联。
   • 浏览器插件：记录你的浏览历史（需授权），甚至能总结你看过的网页内容。
   • 邮件客户端插件：分析你的邮件往来，了解你的工作联系和项目脉络。
   • 日历连接器：读取你的日程安排，让助手知晓你未来的计划和过去的行程。

2. 处理与向量化（Processing & Embedding）：获取的原始文本数据会被切分成有意义的片段（Chunking），然后通过一个嵌入模型（Embedding Model）转换为向量（Vector）。这个向量是一串数字，它以一种数学模型的方式“理解”了这段文本的语义。语义相近的文本，其向量在数学空间里的距离也更近。

3. 向量数据库存储（Vector Database Storage）：所有这些文本片段对应的向量，会被存储在一个本地的向量数据库（如ChromaDB、LanceDB或Qdrant）中。同时，原始的文本片段也会被关联存储，以便后续检索。

4. 记忆与上下文管理（Memory & Context）：OpenHuman不仅存储静态知识，还维护一个关于你与它交互的记忆系统。这包括：

   • 对话历史：记住之前的聊天内容，让对话有连续性。
   • 用户偏好：你纠正过它的地方、你常用的指令风格、你喜欢的输出格式等。
   • 行为模式：通过分析你的操作（如经常查询某类文档、在特定时间处理特定任务），逐渐学习你的习惯。

当你要问助手一个问题时，比如“我上个月写的关于项目复盘的报告主要结论是什么？”，系统会先将你的问题也转换成向量，然后在向量数据库中搜索与之最相关的文档片段（即向量距离最近的几个片段）。这些片段作为“参考材料”，连同你的对话历史、用户偏好等记忆上下文，一起送给大语言模型。模型基于这些专属于你的背景信息来生成回答，因此答案会异常精准和个性化。

2.3 架构总览：模块化与可扩展性

OpenHuman采用了清晰的微服务/模块化架构，这使得它功能强大且易于扩展。我们可以将其核心模块分解如下：

[用户界面 (Web UI / Desktop App)] | v [核心协调器 (Core Orchestrator)] — 负责任务调度、工作流管理、模块间通信 | |————————————————————————————————————————————————————— | | | | v v v v [大语言模型接口] [个人知识库管理器] [工具执行引擎] [记忆管理器] (LLM Gateway) (PKB Manager) (Tool Engine) (Memory Manager) | | | | [本地模型/云API] [向量数据库] [插件/工具集] [向量/关系型存储] [原始文档存储] (如：发送邮件、 查询天气、 控制智能家居)

• 核心协调器：这是大脑的“前额叶”，负责解析你的指令，决定调用哪个模块，并串联整个执行流程。例如，你问“总结我昨天看的关于神经网络的三篇论文”，协调器会先命令知识库管理器检索相关论文，然后将结果发给LLM进行总结，最后通过UI返回给你。
• 工具执行引擎：这是助手的“手和脚”。OpenHuman可以通过插件调用外部工具，比如帮你发送一封写好的邮件、在你的待办列表中添加一项任务、甚至控制连接到电脑的智能设备。这实现了从“信息处理”到“实际行动”的跨越。
• 可扩展性：每个模块都是相对独立的。你可以轻松更换向量数据库（从ChromaDB换成Weaviate），可以同时配置多个LLM后端（本地小模型处理日常问答，复杂任务自动切换调用GPT-4），也可以自己开发新的连接器来支持新的数据源（如你的专属CRM系统）。

这种架构设计让OpenHuman不仅仅是一个应用，更是一个个人AI基础设施。你可以根据自身需求，像搭积木一样定制你的专属助手。

3. 从零开始部署与核心配置实战

3.1 环境准备与基础部署

OpenHuman通常提供Docker部署和本地源码部署两种方式。对于大多数用户，Docker方式最为简单可靠。以下是我在Linux/macOS系统上的实战步骤，Windows用户使用Docker Desktop过程类似。

第一步：安装前置依赖确保你的系统已安装：

• Docker 与 Docker Compose：这是运行容器化服务的基础。
• Git：用于克隆项目代码。
• Python 3.10+（如需源码开发）：如果你想修改代码或开发插件。

第二步：获取项目代码

git clone https://github.com/openhuman-ai/openhuman.git cd openhuman

项目目录结构清晰，docker-compose.yml文件定义了所有服务。

第三步：关键配置修改部署前，最关键的一步是配置环境变量。复制示例配置文件并编辑：

cp .env.example .env

用文本编辑器打开.env文件，你需要关注以下几个核心配置：

# 1. LLM 配置：选择你的“大脑” # 选项A：使用本地模型（推荐有显卡的用户） LLM_TYPE=local LOCAL_MODEL_NAME=Qwen2.5-7B-Instruct-Chat-GGUF # 指定模型文件名（需提前下载至指定目录） LOCAL_MODEL_PATH=/path/to/your/models # 本地模型存放路径 # 选项B：使用OpenAI API（网络方便，效果强大） # LLM_TYPE=openai # OPENAI_API_KEY=sk-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx # OPENAI_BASE_URL=https://api.openai.com/v1 # 或你的代理地址 # 2. 嵌入模型配置：选择你的“理解力” # 用于将文本转换为向量，轻量级模型即可，也分本地和云端 EMBEDDING_TYPE=local LOCAL_EMBEDDING_MODEL_NAME=BAAI/bge-small-zh-v1.5 # 一个优秀的中文小模型 # 3. 向量数据库配置：选择你的“记忆存储方式” VECTOR_DB_TYPE=chroma # 可选 chroma, qdrant, lancedb # 4. 数据持久化路径：确保你的数据在容器重启后不丢失 DATA_PATH=./data # 映射到本地的数据目录，存放知识库、向量数据库、配置文件等

第四步：启动服务配置完成后，一键启动所有服务：

docker-compose up -d

这个命令会启动包括Web UI、后端API、向量数据库、模型服务（如果配置了本地模型）在内的所有容器。

第五步：访问与初始化在浏览器中打开http://localhost:3000（端口可能根据配置调整），你将看到OpenHuman的Web界面。首次使用，系统会引导你进行初始化设置：

1. 创建管理员账户。
2. 配置你的第一个“智能体”（Agent），可以理解为助手的一个特定人格或角色，比如“研究助理”、“写作伙伴”、“效率教练”。
3. 添加“数据源”，即告诉助手去哪里获取你的资料。这里就是配置前面提到的“连接器”，例如添加一个本地文件夹路径。

实操心得：在首次启动时，如果选择了本地模型，下载模型文件可能会耗时较长。建议提前在Hugging Face或ModelScope等平台下载好GGUF格式的量化模型文件（4-8位量化在效果和速度间比较平衡），并放置到LOCAL_MODEL_PATH指定的目录下，可以大大节省初始化时间。对于没有独立显卡的用户，可以选择3B以下参数的小模型，或直接使用CPU推理，但速度会慢一些。

3.2 核心功能配置详解：打造你的专属助手

部署成功只是开始，让OpenHuman变得“懂你”，需要进行精细化的配置。这主要围绕两个核心：数据源和智能体。

数据源配置：喂养你的知识库在Web界面的“数据源”管理页面，点击“添加数据源”。以最常见的“本地文件夹”为例：

• 路径：选择你存放文档的文件夹，如~/Documents/MyResearch。
• 摄取策略：
  • 增量同步：助手会监控文件夹变化，自动索引新增或修改的文件。这是保持知识库新鲜的推荐方式。
  • 文件类型过滤：可以指定只处理.pdf,.md,.docx等格式。
  • 分块策略：这是影响检索效果的关键。OpenHuman通常提供按段落、按固定字符数（如512个token）或重叠分块等选项。对于技术文档，按段落分块语义更完整；对于长篇小说，固定字符数可能更均匀。建议根据文档类型调整。
• 高级选项：可以设置嵌入模型、为来自此数据源的片段添加特定标签（如“工作”、“学习”），便于后续筛选。

添加完成后，点击“同步”，后台的worker服务就会开始读取文件、分块、生成向量并存入向量数据库。你可以在任务中心查看进度。

智能体配置：定义助手的角色与能力“智能体”是与你交互的实体。你可以创建多个智能体，分管不同领域。

1. 创建智能体：在“智能体”页面，点击“新建”。给它起个名字，比如“我的学术秘书”。
2. 选择模型：为该智能体分配一个LLM。你可以让不同的智能体使用不同的模型。比如，“学术秘书”使用强大的Qwen-72B（如果硬件允许），而“快速记事员”使用轻快的Phi-3-mini。
3. 系统提示词（System Prompt）：这是塑造智能体性格和能力的核心！在这里，你需要用自然语言详细描述它的角色、职责、说话风格和限制。

   你是一个严谨、专业的学术研究助理。你的知识主要来源于我本地知识库中的学术论文、实验笔记和项目报告。 你的职责是： - 根据我的问题，从知识库中精准查找并引用相关材料来回答。 - 帮我总结长篇文献的核心观点和方法论。 - 对比不同文献中对同一概念的不同阐述。 - 以清晰、有条理的Markdown格式输出，重要概念需加粗。 - 对于不确定的信息，必须明确指出“根据知识库中某文档的记载...”，切勿捏造信息。 你的回答风格应冷静、客观、注重事实。

   一个详细、具体的系统提示词，比一个模糊的“请帮我”要有效得多。
4. 绑定知识库：选择这个智能体可以访问哪些数据源。你可以让“学术秘书”只能访问/MyResearch文件夹，而“生活管家”可以访问日历和邮件。
5. 授予工具权限：决定这个智能体可以调用哪些工具。比如，你可以允许“生活管家”调用“发送邮件”和“添加日历事件”的工具，但“学术秘书”可能只需要“文件搜索”和“网页搜索”。

通过这样的配置，当你向“我的学术秘书”提问时，它就会自动带上严谨的学术风格，并且只在你指定的研究资料中寻找答案，不会混淆你的个人邮件内容。

4. 高级玩法与深度集成场景

4.1 工作流自动化：让助手主动干活

OpenHuman的终极形态不是“问答机”，而是“自动执行者”。这通过工作流（Workflow）功能实现。工作流是一系列预定义步骤的自动化流程，可以由时间、事件（如新文件到来）或手动触发。

场景示例：每日晨报自动生成假设你希望每天上午9点，助手自动总结你前一天的工作进展、待办事项和日程安排，并发送到你的Slack或钉钉。

1. 创建工作流：在“工作流”编辑器中，创建一个定时触发（Cron表达式：0 9 * * *）的新工作流。
2. 设计步骤：
   • 步骤1（获取数据）：调用“知识库查询”工具，检索过去24小时内你创建或修改的所有文档（可通过标签或路径过滤）。
   • 步骤2（获取日程）：调用“日历读取”工具，获取你当天的日程安排。
   • 步骤3（生成报告）：将步骤1和2的结果作为上下文，发送给一个指定的智能体（如“简报生成员”），并给出指令：“请根据提供的昨日工作文档和今日日程，生成一份简洁的每日晨报，突出已完成项、今日重点和潜在风险。”
   • 步骤4（发送通知）：调用“Webhook”或“消息推送”工具，将生成的晨报内容发送到你的协作平台。
3. 保存并激活：工作流配置完成后，它就会在后台自动运行。你每天早上一到公司，就能在Slack上收到一份为你量身定制的简报。

更复杂的场景：你可以设置当你的Obsidian笔记库里新增一个带有“#项目复盘”标签的笔记时，自动触发工作流，让助手分析笔记内容，提取行动项，并添加到你的项目管理工具（如Trello、Jira）中。这真正实现了从信息产生到任务落地的无缝自动化。

4.2 插件生态与外部工具集成

OpenHuman的强大离不开其可扩展的插件系统。社区已经开发了许多插件来连接外部服务：

• 通信工具：Slack、Discord、Telegram插件，让你可以在这些聊天工具中直接与你的OpenHuman助手对话。
• 生产力工具：集成Notion、Google Calendar、Gmail（通过OAuth）、Feedly（RSS阅读器）。例如，你可以让助手每天下午5点，将Notion中标记为“今日完成”的条目汇总成日志。
• 智能家居：通过Home Assistant或MQTT插件，你可以用自然语言控制家里的灯光、空调。比如对助手说“我十分钟后到家，把客厅空调打开”，它就会在后台计算时间并执行。
• 开发工具：GitHub插件可以让助手总结仓库的Pull Request变更，甚至根据代码变更自动生成提交信息。

安装插件通常很简单，在Docker Compose文件中添加对应的服务配置，或者在管理界面中上传插件包即可。开发自己的插件也遵循清晰的规范，主要就是实现标准的工具调用接口。

4.3 模型管理与性能调优

对于使用本地模型的用户，模型管理是一项重要工作。

模型格式选择：目前最推荐的是GGUF格式。它是为Llama.cpp框架设计的量化格式，具有出色的跨平台兼容性和CPU/GPU混合推理效率。在Hugging Face上，很多模型都会提供GGUF版本下载。

量化策略权衡：量化是在保持模型性能的同时减小其体积和降低计算需求的技术。常见的量化等级有Q4_K_M, Q5_K_M, Q8_0等。数字越小（如Q4），模型体积越小、推理越快，但精度损失可能越大。对于7B模型，Q4_K_M或Q5_K_M通常在速度和效果上取得了很好的平衡，在16GB内存的电脑上就能流畅运行。对于13B或更大模型，如果显存不足，可能需要使用更低的量化等级（如Q3_K_L）或完全依赖CPU推理。

推理后端配置：OpenHuman可以通过llama.cpp、vLLM或Ollama等后端来运行本地模型。在.env配置中，你可以指定：

LOCAL_INFERENCE_BACKEND=llama.cpp # 或 vllm, ollama

llama.cpp兼容性最好，资源占用低；vLLM吞吐量高，适合同时处理多个请求；Ollama则以其易用性著称。你需要根据你的硬件和需求选择，并确保在Docker Compose中启动了对应的后端服务容器。

性能监控与优化：通过docker stats命令或Portainer等工具，监控容器的CPU、内存和GPU占用。如果发现响应慢，可以尝试：1) 使用更小的量化模型；2) 调整llama.cpp的线程数(-t参数)和批处理大小；3) 确保向量数据库的索引是建立在SSD硬盘上，而非机械硬盘。

5. 常见问题与故障排查实录

在实际部署和使用OpenHuman的过程中，我踩过不少坑。这里把一些典型问题和解决方法整理出来，希望能帮你节省时间。

5.1 部署与启动问题

问题1：Docker Compose启动失败，提示端口被占用。

• 排查：OpenHuman默认会占用多个端口（如3000用于Web， 8000用于后端API， 6379用于Redis等）。使用netstat -tulpn | grep <端口号>或lsof -i :<端口号>命令查看是哪个进程占用了端口。
• 解决：
  1. 修改端口：在docker-compose.yml文件中，找到对应服务的ports映射，例如将"3000:3000"改为"3001:3000"，这样外部就通过3001端口访问。
  2. 停止冲突服务：如果确认是其他不重要的服务占用了端口，可以将其停止。
  3. 检查旧容器：有时是之前未正确退出的OpenHuman容器占用了端口。运行docker ps -a查看所有容器，并用docker rm -f <容器名>清理旧的容器实例。

问题2：Web界面能打开，但添加数据源后一直显示“同步中”或失败。

• 排查：这是最常见的问题之一。首先查看后台worker容器的日志：docker logs openhuman-worker-1 -f（容器名可能略有不同）。
• 常见原因与解决：
  • 文件权限问题：Docker容器内的进程通常以非root用户运行，可能没有权限读取你挂载的本地文件夹。确保你的本地数据文件夹（DATA_PATH）有足够的读取权限（chmod 755 /your/data/path）。
  • 嵌入模型下载失败：如果配置了本地嵌入模型（如BAAI/bge-small-zh-v1.5），首次运行需要从Hugging Face下载。网络问题可能导致超时。可以尝试：
    1. 使用国内镜像源，在.env中设置HF_ENDPOINT=https://hf-mirror.com。
    2. 手动下载模型文件到~/.cache/huggingface/hub/目录下对应位置。
  • 文档解析器缺失：对于某些特殊格式文件（如老版本的.doc），可能需要额外的系统库。确保基础镜像包含了完整的字体库和文档处理工具。可以在Dockerfile中增加apt-get install -y poppler-utils tesseract-ocr libsm6 libxext6 libxrender-dev等包，然后重新构建镜像。

5.2 模型相关问题

问题3：配置了本地模型，但对话时提示“模型未加载”或响应极慢。

• 排查：检查模型服务容器的日志：docker logs openhuman-llm-service-1。
• 解决：
  • 模型路径错误：确认.env中的LOCAL_MODEL_PATH在容器内是否能正确挂载。在docker-compose.yml中检查 volumes 映射。可以进入容器内部查看：docker exec -it openhuman-llm-service-1 bash，然后ls /path/to/models。
  • 模型格式不支持：确保下载的模型文件是项目支持的格式（如GGUF）。文件名需与LOCAL_MODEL_NAME完全匹配。
  • 硬件资源不足：运行nvidia-smi（N卡）或查看系统监控，确认GPU内存或系统内存是否耗尽。7B的Q4模型需要约4-5GB的GPU内存或更多系统内存。如果资源紧张，尝试更小的模型（如3B）或更高的量化等级（如Q2）。
  • 推理后端配置错误：确认LOCAL_INFERENCE_BACKEND设置正确，且对应的服务（如llama.cpp服务器）已成功启动并监听了正确的端口。

问题4：使用云端API（如OpenAI）时，助手回复慢或经常超时。

• 排查：检查网络连接和API密钥配额。
• 解决：
  • 在.env中，可以尝试设置OPENAI_BASE_URL为更稳定的代理地址（如果网络环境需要）。
  • 在后端服务的配置中，调整API调用的超时时间（timeout），默认可能太短。
  • 如果请求量不大但速度慢，可能是云端模型加载冷启动导致的。可以考虑在系统提示词中要求助手回复简洁，或使用更快的模型（如gpt-3.5-turbo）。

5.3 功能与使用问题

问题5：助手回答的内容与我的知识库无关，像是在胡编乱造。

• 原因：这是检索增强生成（RAG）流程中“检索”环节失效的典型表现。即系统没有从你的知识库中找到相关文档，导致大语言模型只能基于其自身训练数据（先验知识）“幻觉”出一个答案。
• 解决：
  1. 检查数据源同步状态：确认你提问所涉及的文件已经被成功同步和索引。在数据源管理界面查看同步日志和文档数量。
  2. 优化检索策略：
     • 调整分块大小：块太大可能包含无关信息稀释关键内容；块太小可能丢失上下文。对于问答，256-512字符的块通常不错；对于摘要，可以更大。
     • 使用重叠分块：设置块之间有10%-20%的重叠，可以避免一个概念被生硬地切分到两个块边缘。
     • 优化查询：尝试在问题中包含更具体的关键词。或者，利用智能体的系统提示词，要求它“必须严格基于提供的上下文回答，如果上下文不包含相关信息，请直接说‘根据现有资料无法回答’”。
  3. 检查嵌入模型：用于索引和查询的嵌入模型是否一致且适合你的语言（中文还是英文）？可以尝试更换一个更强大的嵌入模型。

问题6：智能体调用工具（如发邮件）失败。

• 排查：查看核心协调器或具体工具容器的日志。
• 解决：
  • 权限问题：工具调用往往需要API密钥或OAuth授权。检查对应插件的配置页面，是否已正确填写了所有必填的认证信息（如邮箱的SMTP密码、第三方服务的API Token）。
  • 参数错误：工具调用需要特定格式的参数。检查工作流或对话中，传递给工具的输入是否符合其要求。可以在开发模式下查看工具调用的输入输出详情。
  • 网络问题：工具需要访问的外部服务（如邮件服务器、Slack API）可能无法从Docker容器内访问。确保网络配置正确，有时需要配置容器的网络模式或代理。

5.4 性能优化问题

问题7：随着知识库文档增多，检索速度变慢。

• 分析：向量数据库进行相似性搜索的速度，与向量数量成正比。当你有数十万甚至上百万个向量片段时，线性搜索会变得很慢。
• 优化：
  1. 使用带索引的向量数据库：确保你使用的向量数据库（如Qdrant, Weaviate）创建了高效的索引（如HNSW）。在配置中检查索引参数，如ef_construction和M，适当增加这些值可以提高召回率，但会占用更多内存和构建时间。
  2. 元数据过滤：在检索时，尽量利用你在添加数据源时设置的标签、路径等元数据进行过滤。例如，当你问一个工作相关的问题时，可以限定只在“标签=工作”的向量中搜索，这能大幅缩小搜索范围。
  3. 分层检索：先使用简单的关键词匹配（BM25）快速筛选出一批候选文档，再在这批文档的向量中进行精细的语义搜索。一些高级的检索框架支持这种混合检索策略。
  4. 定期清理：移除不再需要或过时的文档源，或者为文档设置TTL（生存时间），让旧文档自动过期。

问题8：本地模型推理时GPU内存占用高，导致系统卡顿。

• 解决：
  1. 量化：使用更低比特的量化模型（如从Q4降到Q3）。
  2. 卸载层数：对于llama.cpp，可以通过-ngl参数控制将多少层模型加载到GPU，其余部分放在CPU。虽然会降低速度，但能极大减少显存占用。例如，-ngl 20表示只把前20层放在GPU。
  3. 使用CPU推理：如果GPU显存实在太小，可以完全使用CPU推理。在.env中设置相关后端参数，如为llama.cpp设置更高的线程数(-t)来利用多核CPU。
  4. 批处理大小：降低推理的批处理大小（batch size），每次处理更少的token，可以减少峰值显存占用。

部署和运行一个完整的本地AI助手系统，确实比使用一个网页应用要复杂。但每一次故障排查和性能调优，都让你对这套系统的掌控更深一分。当你看到它终于能流畅地基于你多年的笔记回答一个复杂问题，或者自动帮你完成一个重复性工作时，那种“这是我亲手打造的智能伙伴”的成就感，是使用任何云端服务都无法替代的。OpenHuman就像一个乐高套装，它给了你所有的零件和说明书，而最终搭建出一个怎样的数字生命，完全取决于你的想象力和动手能力。