尧图网站开发 
“零成本本地 AI 全栈”这个说法听起来像是个大工程但实际拆开看就是我把自己家里那台老爷机当服务器把大模型、后端服务、文档检索和智能问答入口全串了起来。整个过程没买云服务器也没开 API 付费套餐用的全是开源组件和家里现有硬件。如果你手头有一台 16GB 内存以上的电脑并且想折腾一套真正属于自己的“本地 AI 工作台”这篇文章就是给你准备的。我会把这条完整链路讲明白模型怎么选、推理服务怎么起、后端怎么封装、搜索怎么接进去、最后怎么在前端用起来。不是纯概念科普而是按我可复现的真实架构来讲。1. 本地 AI 全栈先想清楚到底在搭什么做之前我其实犹豫过直接用市面上的 AI 助手客户端不就行了吗为什么还要自己在家里搭一套后来想通了本地全栈和用别人的服务是两回事。本地跑意味着你拥有全部控制权数据不出门、提示词自己定、模型随便换、什么时候想加个搜索插件就加。1.1 我为什么没用云端 API最初我也试过各种云端大模型服务确实方便但有两个始终绕不开的问题一是按量计费聊多了、搜索多了账单压力会慢慢上来二是数据边界家里的文档、流水、笔记这些东西我不想为了一个摘要功能就传到一个我不知道在哪里的机房去。另外家里很多终端设备都需要同一个智能入口电脑上想用手机浏览器也想用可能以后还要接到 NAS 上给全家人用。如果每个设备都各自对接云 API管理和成本都是一团乱麻。而在本机跑一个标准接口服务所有设备都指向这一个端点这就是最朴素的全栈思路。1.2 我的目标架构地图我先说清楚整个系统的分层后面所有步骤都围绕这四层展开模型推理层负责加载大模型、生成回复也能做向量化处理后端服务层封装模型接口做提示词组装、历史记录管理、搜索调度搜索与检索层负责从本地文档和个人资料里找回相关内容也能接在线搜索服务前端交互层浏览器里的聊天面板用来传问题、看回复我喜欢把每一层拆成独立进程。这样做的好处很直接模型卡了替换模型文件就行前端不满意换一套界面不影响后端搜索服务挂了聊天功能照样能跑。分层带来的自由度是全栈架构里最值钱的部分。2. 模型与推理你的机器能承担哪些本地模型本地 AI 的第一步是让模型真正跑起来。但本地不是云硬件性能就摆在那里所以选模型不能盲目追求大参数。2.1 先算内存账本地模型大小的估算方法本地部署大模型最关键的不是 CPU 多快而是内存带宽和容量。以我的经验最实用的估算法则很简单一个 7B 参数模型如果是半精度加载大约需要 14GB 内存如果用 4-bit 量化比如 Q4_K_M只需要大约 4.5GB 到 5GB 的模型权重空间。在推理时还要给 KV Cache、上下文窗口和系统程序留出几 GB 余量。我自己的机器是 32GB 内存的普通台式机没有独立显卡所以选型目标很明确单模型尽量控制在 8B 参数以内使用 4-bit 量化版本。如果你只有 16GB 内存可以跑 3B 到 7B 的量化模型如果内存更大或者有支持 CUDA 的显卡就可以尝试 13B 甚至更大的模型。先看内存预算再谈模型能力。模型规模量化方式大致内存占用建议最低整机内存3BQ4_K_M2GB 左右8GB7B~8BQ4_K_M4.5GB~5.5GB16GB13B~14BQ4_K_M8GB~9GB32GB7B~8B半精度 FP1614GB 左右32GB 且建议有显卡ollama输出的模型列表里其实也会标注大小但你最好在下载前就按这个估算逻辑排一遍别等到启动时被 OOM 打死才回头。2.2 推荐的模型选型与安装本地方案里我用的是 Ollama 作为模型运行时。它特别适合我这种不想反复折腾环境的全栈玩家装好后一条命令就能拉模型一条命令就能起服务而且直接暴露 HTTP API后端很好对接。就模型本身而言日常对话我推荐qwen2.5系列中文效果好指令跟随也稳。没有独显、CPU 推理的场景下7B 的 4-bit 版本足够应付绝大多数问答、总结和写作任务。3B 版本更快适合丢给搜索环节做快速分类。安装过程非常简单装完 Ollama 后拉取模型ollama pull qwen2.5:7b-instruct-q4_K_M如果机器性能紧张拉 3Bollama pull qwen2.5:3b-instruct-q4_K_M完整跑起来之前还需要一个向量模型用来给后面的文档搜索做文本转向量ollama pull nomic-embed-text这里我踩过一个小坑Ollama 默认会把上下文窗口限制在 2048 token 左右。本地做资料问答时经常不够用所以启动模型时最好主动设大一点。我一般通过环境变量或模型参数把上下文调到 8192。2.3 为什么选 Ollama 而不是自己从零部署推理引擎自己用 transformers 加载模型、写推理脚本也不是不行但那等于每个模型都要写一套加载逻辑很不适合全栈项目维护。Ollama 内部底层用的是 llama.cpp它对 CPU 和各类 GPU 都有优化屏蔽掉了大量细节。对我来说Ollama 最大的价值是把“模型加载”变成了“系统服务”。它会常驻后台第一次请求会启动模型之后一直驻留内存后续对话延迟能低很多。这也让我后面所有的后端代码只需要面向一个标准 HTTP 接口写逻辑不需要关心模型底层细节。3. 后端服务给模型加一层属于你自己的“全栈粘合剂”模型装好以后如果你只是ollama run开个命令行窗口那充其量算“本地能用”谈不上“全栈”。真正让整个项目灵活起来的是中间那层后端服务。我在这里用 FastAPI 写了一个轻量封装作用不是重复造轮子而是统一整个家庭 AI 的调度逻辑。3.1 为什么要自建后端层直接让前端页面去请求 Ollama 也可以但问题很现实一旦你想在回复前注入系统提示词、把用户问题先做一次文档搜索、再控制一下历史轮数这些逻辑堆在哪里如果你把它写死在页面里那么每次换终端都要重写一套。中心化封装以后所有终端都只会调用你定义好的业务接口。另外全栈后面经常会遇到换模型的需求。今天用 7B发现速度慢想换 3B如果每个端都直接写死模型名那就要改所有端。用后端统一管理后只需要改一处默认模型配置前端完全无感。3.2 搭建最小后端工程我建了这样一个目录结构home-ai/ ├── provider/ │ └── llm.py ├── retriever/ │ ├── local_store.py │ └── search_web.py ├── app/ │ ├── api.py │ └── chat_ui.py └── scripts/ ├── download_models.sh └── run.sh其实就是一个很普通的 Python 项目。先准备好环境依赖mkdir -p ~/home-ai cd ~/home-ai python3 -m venv venv source venv/bin/activate pip install fastapi uvicorn requests streamlit chromadb然后用 provider 封装对 Ollama 的调用# provider/llm.py import requests OLLAMA_URL http://127.0.0.1:11434/api/chat MODEL qwen2.5:7b-instruct-q4_K_M def chat(messages, system_promptNone): if system_prompt: messages [{role: system, content: system_prompt}] messages payload { model: MODEL, messages: messages, stream: False, options: {num_ctx: 8192}, } resp requests.post(OLLAMA_URL, jsonpayload, timeout300) resp.raise_for_status() return resp.json()[message][content]这里的num_ctx很重要我前面说过不显式设置的话长文本经常“失忆”。FastAPI 后端再把 provider 封装成 HTTP 接口# app/api.py from fastapi import FastAPI from pydantic import BaseModel from provider.llm import chat app FastAPI() class ChatRequest(BaseModel): messages: list system_prompt: str | None None class ChatResponse(BaseModel): reply: str app.post(/api/chat, response_modelChatResponse) def handle_chat(req: ChatRequest): reply chat(req.messages, req.system_prompt) return ChatResponse(replyreply)启动后端uvicorn app.api:app --host 0.0.0.0 --port 8000--host 0.0.0.0是为了让局域网内其他设备也能访问。如果只是本机自己用改成127.0.0.1会更安全。3.3 前端交互用 Streamlit 快速做一个家庭聊天面板前端我选 Streamlit 不是为了炫技而是因为它让我能把注意力放在交互逻辑而不是页面工程上。特别适合自用或者家里内网使用的轻量界面。# app/chat_ui.py import streamlit as st import requests API http://127.0.0.1:8000/api/chat st.title(Home AI) if messages not in st.session_state: st.session_state.messages [] for msg in st.session_state.messages: with st.chat_message(msg[role]): st.write(msg[content]) prompt st.chat_input(输入问题) if prompt: st.session_state.messages.append({role: user, content: prompt}) with st.chat_message(user): st.write(prompt) resp requests.post(API, json{messages: st.session_state.messages}, timeout300) reply resp.json()[reply] st.session_state.messages.append({role: assistant, content: reply}) with st.chat_message(assistant): st.write(reply)启动前端streamlit run app/chat_ui.py --server.port 8501到这一步最基本的“家里聊天机器人”已经能用了。但这还远谈不上搜索能力。4. 搜索增强让模型回答它训练时不知道的问题大模型的知识有时间天花板而且完全不知道你硬盘里那些私人文档。所以“搜索”这个能力是全栈里最值得加的一层。我把它拆成了两种本地文档检索和在线搜索接入。4.1 本地文档检索搭一个私人知识库我主要用 ChromaDB 做向量数据库同时让 Ollama 提供向量化模型。整个流程和常见 RAG 没有区别先把文档切块再把切好的片段转成向量存进库用户提问时把问题也转成向量从库里找出最相近的片段最后把这些片段拼进提示词送给大模型。先给文档拆块。拆块参数是我调试过很多次的经验值每块 400 字、重叠 60 字对中文文档来说信息重复少检索也不容易漏。# retriever/splitter.py def split_text(text, chunk_size400, overlap60): chunks [] start 0 while start len(text): end start chunk_size chunks.append(text[start:end]) if end len(text): break start end - overlap return chunks然后把拆分的结果写入 ChromaDB。我会用 OllamaEmbeddingFunction 让 Chroma 直接调用本地向量模型# retriever/local_store.py import chromadb from chromadb.utils import embedding_functions from retriever.splitter import split_text embed_fn embedding_functions.OllamaEmbeddingFunction( urlhttp://127.0.0.1:11434/api/embeddings, model_namenomic-embed-text, ) client chromadb.PersistentClient(path./chroma) collection client.get_or_create_collection( namehome_docs, embedding_functionembed_fn, ) def index_document(doc_id: str, content: str): chunks split_text(content) ids [f{doc_id}_{i} for i in range(len(chunks))] collection.upsert(idsids, documentschunks) return len(chunks) def search_documents(query: str, top_k: int 3): res collection.query(query_texts[query], n_resultstop_k) return res[documents][0]这一步让本地文档真正“活”了起来。比如我把自己已经导出的博客 Markdown 文件、工作笔记、各种操作手册全部写入库后再提问时模型就能基于这些资料回答而不是凭空乱编。所有检索和推理都发生在本地。接入后端的方式也很简单先执行一次检索把片段放进系统提示词context \n\n.join(search_documents(user_question)) system_prompt f请基于以下资料回答问题 {context} 如果资料中没有相关信息请直接说明不知道。这个“直接说明不知道”特别重要。不加这句话模型容易把搜索片段里不相关的内容也强行组织成看似合理的答案误导性非常强。4.2 在线搜索给本地模型接上可用的信息通道本地文档解决不了两件事最新新闻、自己库里没有的内容。我选择在自己家里额外起一个搜索服务实例让后端统一通过它来查询。作为自用方案最常见的方式是跑一个 SearXNG 容器它本身是一个聚合搜索服务通过浏览器界面或 JSON 格式暴露查询结果。如果你不想自己维护容器也可以用正规搜索服务商提供的搜索 API前提是你能正常申请到对应权限。后者要花钱所以我的默认方案是本地容器docker run -d --name searxng -p 8888:8080 searxng/searxng然后后端封装一个简单的在线搜索函数# retriever/search_web.py import requests def search_web(query: str, top_k: int 5): params {q: query, format: json, language: zh-CN} resp requests.get(http://127.0.0.1:8888/search, paramsparams, timeout20) resp.raise_for_status() results resp.json().get(results, []) return [r.get(url) \n r.get(title, ) \n r.get(content, ) for r in results[:top_k]]使用在线搜索结果时后端逻辑需要稍微调整。不能把搜索结果一股脑塞进上下文而是让模型先判断搜索出的哪些片段和问题真正相关再从这些片段里提炼答案。否则很容易被一个标题党页面带偏。5. 完整联调把全链路跑起来后端代码、向量库、在线搜索都准备好了最后把它们拼成一个真正的全栈服务。我强烈建议把这个过程脚本化别每次靠手工启动。5.1 一键启动脚本#!/bin/bash # scripts/run.sh ollama serve /tmp/ollama.log 21 cd ~/home-ai source venv/bin/activate uvicorn app.api:app --host 0.0.0.0 --port 8000 /tmp/api.log 21 streamlit run app/chat_ui.py --server.port 8501 /tmp/ui.log 21 echo AI service is running.每次改动代码后只需要重启对应的服务进程不需要整机重启。测试时最顺手的方式是直接用 curl 打后端接口curl -X POST http://127.0.0.1:8000/api/chat \ -H Content-Type: application/json \ -d {messages:[{role:user,content:帮我总结一下我上周笔记里关于量化模型的结论}]}如果文档检索和模型都正常返回内容里就能看到参考资料的痕迹。我第一次跑通这个完整链路时是在一次局域网内用手机浏览器访问 Streamlit 页面提问问完家里 NAS 上的一个项目说明后手机端直接给出了带项目术语的回答那一刻才真正觉得整套架构立住了。5.2 联调时的性能观察本地推理会出现一个特殊状态第一次提问很慢可能要等十几秒甚至几十秒但紧接着第二次提问会快很多。原因是 Ollama 第一次需要把模型权重加载进内存加载后模型驻留后续就能直接推理。所以做全栈时要有点耐心不要在第一次慢请求时就开始排查网络问题。如果整机资源紧张我建议把向量模型和对话模型分开部署到不同服务端口或者错峰调用。否则同时加载两个模型内存会翻倍增长。6. 常见问题速查跑本地 AI 以来我踩过的坑现象常见原因处理方式模型回答总是断在中间上下文窗口太小或超时设置过短把num_ctx设为 8192后端请求timeout调到 300 秒首字输出特别慢模型首次加载或 CPU 推理保持模型常驻避免频繁换模型问文档内容回答与资料无关检索返回了错误片段调整分块大小增加 top_k 后让模型二次筛选检索效果差关键词换了就找不到向量模型无法理解专业缩写先在文档片段里补充分词前缀或使用更强的 embedding 模型局域网其他设备访问不了后端启动时绑定了 127.0.0.1启动参数改为--host 0.0.0.0内存占用越来越高模型和向量库都驻留在内存不用时调用 Ollama 的卸载接口或部署成按需加载模式有一个问题最隐蔽我一开始把本地文档的索引做在内存里ChromaDB 数据没持久化每次重启进程就得重新 embed 一遍。后来改成PersistentClient(path./chroma)把索引落到磁盘重启就再也不用重建了。另外中文内容做向量化时模型对术语的敏感度差异很大。我实测过用nomic-embed-text处理常见中文文档效果尚可但遇到代码类或强术语资料时一个简单的办法是索引前手动把文档标题作为前缀加到每个分块的开头比如“关于FastAPI部署……”这样检索命中率会提升不少。7. 给这套全栈继续加码的建议跑通“本地模型后端搜索”之后你就会自然地想给它加更多东西。我自己接下来准备做的扩展方向有三个。第一个是接语音输入。本地跑一个开源的语音识别模型把录音转成文字再丢给后端这样全家使用门槛会低很多老人和孩子不用打字也能提问。第二个是定时自动化任务。比如每天早上让本地模型总结昨天新增的文档生成一份日报推送给我。因为整套系统都在本地这种定时任务可以非常个人化不用怕数据泄露。第三个是加多用户隔离。目前这个架构所有对话历史都放在前端会话里如果家里有多个人用可以在后端增加一个简单的用户字段把每个人的搜索历史和偏好分开保存。最后再分享一个我在实际维护中的体会本地全栈项目最容易被低估的是日常维护成本模型版本更新、向量索引重建、服务崩溃恢复这些都需要投入时间。但也正因为这些事都需要自己处理你才会真正理解大模型应用是怎么协作的。想清楚这一点再动手这套折腾才值。 
“零成本本地 AI 全栈”这个说法听起来像是个大工程但实际拆开看就是我把自己家里那台老爷机当服务器把大模型、后端服务、文档检索和智能问答入口全串了起来。整个过程没买云服务器也没开 API 付费套餐用的全是开源组件和家里现有硬件。如果你手头有一台 16GB 内存以上的电脑并且想折腾一套真正属于自己的“本地 AI 工作台”这篇文章就是给你准备的。我会把这条完整链路讲明白模型怎么选、推理服务怎么起、后端怎么封装、搜索怎么接进去、最后怎么在前端用起来。不是纯概念科普而是按我可复现的真实架构来讲。1. 本地 AI 全栈先想清楚到底在搭什么做之前我其实犹豫过直接用市面上的 AI 助手客户端不就行了吗为什么还要自己在家里搭一套后来想通了本地全栈和用别人的服务是两回事。本地跑意味着你拥有全部控制权数据不出门、提示词自己定、模型随便换、什么时候想加个搜索插件就加。1.1 我为什么没用云端 API最初我也试过各种云端大模型服务确实方便但有两个始终绕不开的问题一是按量计费聊多了、搜索多了账单压力会慢慢上来二是数据边界家里的文档、流水、笔记这些东西我不想为了一个摘要功能就传到一个我不知道在哪里的机房去。另外家里很多终端设备都需要同一个智能入口电脑上想用手机浏览器也想用可能以后还要接到 NAS 上给全家人用。如果每个设备都各自对接云 API管理和成本都是一团乱麻。而在本机跑一个标准接口服务所有设备都指向这一个端点这就是最朴素的全栈思路。1.2 我的目标架构地图我先说清楚整个系统的分层后面所有步骤都围绕这四层展开模型推理层负责加载大模型、生成回复也能做向量化处理后端服务层封装模型接口做提示词组装、历史记录管理、搜索调度搜索与检索层负责从本地文档和个人资料里找回相关内容也能接在线搜索服务前端交互层浏览器里的聊天面板用来传问题、看回复我喜欢把每一层拆成独立进程。这样做的好处很直接模型卡了替换模型文件就行前端不满意换一套界面不影响后端搜索服务挂了聊天功能照样能跑。分层带来的自由度是全栈架构里最值钱的部分。2. 模型与推理你的机器能承担哪些本地模型本地 AI 的第一步是让模型真正跑起来。但本地不是云硬件性能就摆在那里所以选模型不能盲目追求大参数。2.1 先算内存账本地模型大小的估算方法本地部署大模型最关键的不是 CPU 多快而是内存带宽和容量。以我的经验最实用的估算法则很简单一个 7B 参数模型如果是半精度加载大约需要 14GB 内存如果用 4-bit 量化比如 Q4_K_M只需要大约 4.5GB 到 5GB 的模型权重空间。在推理时还要给 KV Cache、上下文窗口和系统程序留出几 GB 余量。我自己的机器是 32GB 内存的普通台式机没有独立显卡所以选型目标很明确单模型尽量控制在 8B 参数以内使用 4-bit 量化版本。如果你只有 16GB 内存可以跑 3B 到 7B 的量化模型如果内存更大或者有支持 CUDA 的显卡就可以尝试 13B 甚至更大的模型。先看内存预算再谈模型能力。模型规模量化方式大致内存占用建议最低整机内存3BQ4_K_M2GB 左右8GB7B~8BQ4_K_M4.5GB~5.5GB16GB13B~14BQ4_K_M8GB~9GB32GB7B~8B半精度 FP1614GB 左右32GB 且建议有显卡ollama输出的模型列表里其实也会标注大小但你最好在下载前就按这个估算逻辑排一遍别等到启动时被 OOM 打死才回头。2.2 推荐的模型选型与安装本地方案里我用的是 Ollama 作为模型运行时。它特别适合我这种不想反复折腾环境的全栈玩家装好后一条命令就能拉模型一条命令就能起服务而且直接暴露 HTTP API后端很好对接。就模型本身而言日常对话我推荐qwen2.5系列中文效果好指令跟随也稳。没有独显、CPU 推理的场景下7B 的 4-bit 版本足够应付绝大多数问答、总结和写作任务。3B 版本更快适合丢给搜索环节做快速分类。安装过程非常简单装完 Ollama 后拉取模型ollama pull qwen2.5:7b-instruct-q4_K_M如果机器性能紧张拉 3Bollama pull qwen2.5:3b-instruct-q4_K_M完整跑起来之前还需要一个向量模型用来给后面的文档搜索做文本转向量ollama pull nomic-embed-text这里我踩过一个小坑Ollama 默认会把上下文窗口限制在 2048 token 左右。本地做资料问答时经常不够用所以启动模型时最好主动设大一点。我一般通过环境变量或模型参数把上下文调到 8192。2.3 为什么选 Ollama 而不是自己从零部署推理引擎自己用 transformers 加载模型、写推理脚本也不是不行但那等于每个模型都要写一套加载逻辑很不适合全栈项目维护。Ollama 内部底层用的是 llama.cpp它对 CPU 和各类 GPU 都有优化屏蔽掉了大量细节。对我来说Ollama 最大的价值是把“模型加载”变成了“系统服务”。它会常驻后台第一次请求会启动模型之后一直驻留内存后续对话延迟能低很多。这也让我后面所有的后端代码只需要面向一个标准 HTTP 接口写逻辑不需要关心模型底层细节。3. 后端服务给模型加一层属于你自己的“全栈粘合剂”模型装好以后如果你只是ollama run开个命令行窗口那充其量算“本地能用”谈不上“全栈”。真正让整个项目灵活起来的是中间那层后端服务。我在这里用 FastAPI 写了一个轻量封装作用不是重复造轮子而是统一整个家庭 AI 的调度逻辑。3.1 为什么要自建后端层直接让前端页面去请求 Ollama 也可以但问题很现实一旦你想在回复前注入系统提示词、把用户问题先做一次文档搜索、再控制一下历史轮数这些逻辑堆在哪里如果你把它写死在页面里那么每次换终端都要重写一套。中心化封装以后所有终端都只会调用你定义好的业务接口。另外全栈后面经常会遇到换模型的需求。今天用 7B发现速度慢想换 3B如果每个端都直接写死模型名那就要改所有端。用后端统一管理后只需要改一处默认模型配置前端完全无感。3.2 搭建最小后端工程我建了这样一个目录结构home-ai/ ├── provider/ │ └── llm.py ├── retriever/ │ ├── local_store.py │ └── search_web.py ├── app/ │ ├── api.py │ └── chat_ui.py └── scripts/ ├── download_models.sh └── run.sh其实就是一个很普通的 Python 项目。先准备好环境依赖mkdir -p ~/home-ai cd ~/home-ai python3 -m venv venv source venv/bin/activate pip install fastapi uvicorn requests streamlit chromadb然后用 provider 封装对 Ollama 的调用# provider/llm.py import requests OLLAMA_URL http://127.0.0.1:11434/api/chat MODEL qwen2.5:7b-instruct-q4_K_M def chat(messages, system_promptNone): if system_prompt: messages [{role: system, content: system_prompt}] messages payload { model: MODEL, messages: messages, stream: False, options: {num_ctx: 8192}, } resp requests.post(OLLAMA_URL, jsonpayload, timeout300) resp.raise_for_status() return resp.json()[message][content]这里的num_ctx很重要我前面说过不显式设置的话长文本经常“失忆”。FastAPI 后端再把 provider 封装成 HTTP 接口# app/api.py from fastapi import FastAPI from pydantic import BaseModel from provider.llm import chat app FastAPI() class ChatRequest(BaseModel): messages: list system_prompt: str | None None class ChatResponse(BaseModel): reply: str app.post(/api/chat, response_modelChatResponse) def handle_chat(req: ChatRequest): reply chat(req.messages, req.system_prompt) return ChatResponse(replyreply)启动后端uvicorn app.api:app --host 0.0.0.0 --port 8000--host 0.0.0.0是为了让局域网内其他设备也能访问。如果只是本机自己用改成127.0.0.1会更安全。3.3 前端交互用 Streamlit 快速做一个家庭聊天面板前端我选 Streamlit 不是为了炫技而是因为它让我能把注意力放在交互逻辑而不是页面工程上。特别适合自用或者家里内网使用的轻量界面。# app/chat_ui.py import streamlit as st import requests API http://127.0.0.1:8000/api/chat st.title(Home AI) if messages not in st.session_state: st.session_state.messages [] for msg in st.session_state.messages: with st.chat_message(msg[role]): st.write(msg[content]) prompt st.chat_input(输入问题) if prompt: st.session_state.messages.append({role: user, content: prompt}) with st.chat_message(user): st.write(prompt) resp requests.post(API, json{messages: st.session_state.messages}, timeout300) reply resp.json()[reply] st.session_state.messages.append({role: assistant, content: reply}) with st.chat_message(assistant): st.write(reply)启动前端streamlit run app/chat_ui.py --server.port 8501到这一步最基本的“家里聊天机器人”已经能用了。但这还远谈不上搜索能力。4. 搜索增强让模型回答它训练时不知道的问题大模型的知识有时间天花板而且完全不知道你硬盘里那些私人文档。所以“搜索”这个能力是全栈里最值得加的一层。我把它拆成了两种本地文档检索和在线搜索接入。4.1 本地文档检索搭一个私人知识库我主要用 ChromaDB 做向量数据库同时让 Ollama 提供向量化模型。整个流程和常见 RAG 没有区别先把文档切块再把切好的片段转成向量存进库用户提问时把问题也转成向量从库里找出最相近的片段最后把这些片段拼进提示词送给大模型。先给文档拆块。拆块参数是我调试过很多次的经验值每块 400 字、重叠 60 字对中文文档来说信息重复少检索也不容易漏。# retriever/splitter.py def split_text(text, chunk_size400, overlap60): chunks [] start 0 while start len(text): end start chunk_size chunks.append(text[start:end]) if end len(text): break start end - overlap return chunks然后把拆分的结果写入 ChromaDB。我会用 OllamaEmbeddingFunction 让 Chroma 直接调用本地向量模型# retriever/local_store.py import chromadb from chromadb.utils import embedding_functions from retriever.splitter import split_text embed_fn embedding_functions.OllamaEmbeddingFunction( urlhttp://127.0.0.1:11434/api/embeddings, model_namenomic-embed-text, ) client chromadb.PersistentClient(path./chroma) collection client.get_or_create_collection( namehome_docs, embedding_functionembed_fn, ) def index_document(doc_id: str, content: str): chunks split_text(content) ids [f{doc_id}_{i} for i in range(len(chunks))] collection.upsert(idsids, documentschunks) return len(chunks) def search_documents(query: str, top_k: int 3): res collection.query(query_texts[query], n_resultstop_k) return res[documents][0]这一步让本地文档真正“活”了起来。比如我把自己已经导出的博客 Markdown 文件、工作笔记、各种操作手册全部写入库后再提问时模型就能基于这些资料回答而不是凭空乱编。所有检索和推理都发生在本地。接入后端的方式也很简单先执行一次检索把片段放进系统提示词context \n\n.join(search_documents(user_question)) system_prompt f请基于以下资料回答问题 {context} 如果资料中没有相关信息请直接说明不知道。这个“直接说明不知道”特别重要。不加这句话模型容易把搜索片段里不相关的内容也强行组织成看似合理的答案误导性非常强。4.2 在线搜索给本地模型接上可用的信息通道本地文档解决不了两件事最新新闻、自己库里没有的内容。我选择在自己家里额外起一个搜索服务实例让后端统一通过它来查询。作为自用方案最常见的方式是跑一个 SearXNG 容器它本身是一个聚合搜索服务通过浏览器界面或 JSON 格式暴露查询结果。如果你不想自己维护容器也可以用正规搜索服务商提供的搜索 API前提是你能正常申请到对应权限。后者要花钱所以我的默认方案是本地容器docker run -d --name searxng -p 8888:8080 searxng/searxng然后后端封装一个简单的在线搜索函数# retriever/search_web.py import requests def search_web(query: str, top_k: int 5): params {q: query, format: json, language: zh-CN} resp requests.get(http://127.0.0.1:8888/search, paramsparams, timeout20) resp.raise_for_status() results resp.json().get(results, []) return [r.get(url) \n r.get(title, ) \n r.get(content, ) for r in results[:top_k]]使用在线搜索结果时后端逻辑需要稍微调整。不能把搜索结果一股脑塞进上下文而是让模型先判断搜索出的哪些片段和问题真正相关再从这些片段里提炼答案。否则很容易被一个标题党页面带偏。5. 完整联调把全链路跑起来后端代码、向量库、在线搜索都准备好了最后把它们拼成一个真正的全栈服务。我强烈建议把这个过程脚本化别每次靠手工启动。5.1 一键启动脚本#!/bin/bash # scripts/run.sh ollama serve /tmp/ollama.log 21 cd ~/home-ai source venv/bin/activate uvicorn app.api:app --host 0.0.0.0 --port 8000 /tmp/api.log 21 streamlit run app/chat_ui.py --server.port 8501 /tmp/ui.log 21 echo AI service is running.每次改动代码后只需要重启对应的服务进程不需要整机重启。测试时最顺手的方式是直接用 curl 打后端接口curl -X POST http://127.0.0.1:8000/api/chat \ -H Content-Type: application/json \ -d {messages:[{role:user,content:帮我总结一下我上周笔记里关于量化模型的结论}]}如果文档检索和模型都正常返回内容里就能看到参考资料的痕迹。我第一次跑通这个完整链路时是在一次局域网内用手机浏览器访问 Streamlit 页面提问问完家里 NAS 上的一个项目说明后手机端直接给出了带项目术语的回答那一刻才真正觉得整套架构立住了。5.2 联调时的性能观察本地推理会出现一个特殊状态第一次提问很慢可能要等十几秒甚至几十秒但紧接着第二次提问会快很多。原因是 Ollama 第一次需要把模型权重加载进内存加载后模型驻留后续就能直接推理。所以做全栈时要有点耐心不要在第一次慢请求时就开始排查网络问题。如果整机资源紧张我建议把向量模型和对话模型分开部署到不同服务端口或者错峰调用。否则同时加载两个模型内存会翻倍增长。6. 常见问题速查跑本地 AI 以来我踩过的坑现象常见原因处理方式模型回答总是断在中间上下文窗口太小或超时设置过短把num_ctx设为 8192后端请求timeout调到 300 秒首字输出特别慢模型首次加载或 CPU 推理保持模型常驻避免频繁换模型问文档内容回答与资料无关检索返回了错误片段调整分块大小增加 top_k 后让模型二次筛选检索效果差关键词换了就找不到向量模型无法理解专业缩写先在文档片段里补充分词前缀或使用更强的 embedding 模型局域网其他设备访问不了后端启动时绑定了 127.0.0.1启动参数改为--host 0.0.0.0内存占用越来越高模型和向量库都驻留在内存不用时调用 Ollama 的卸载接口或部署成按需加载模式有一个问题最隐蔽我一开始把本地文档的索引做在内存里ChromaDB 数据没持久化每次重启进程就得重新 embed 一遍。后来改成PersistentClient(path./chroma)把索引落到磁盘重启就再也不用重建了。另外中文内容做向量化时模型对术语的敏感度差异很大。我实测过用nomic-embed-text处理常见中文文档效果尚可但遇到代码类或强术语资料时一个简单的办法是索引前手动把文档标题作为前缀加到每个分块的开头比如“关于FastAPI部署……”这样检索命中率会提升不少。7. 给这套全栈继续加码的建议跑通“本地模型后端搜索”之后你就会自然地想给它加更多东西。我自己接下来准备做的扩展方向有三个。第一个是接语音输入。本地跑一个开源的语音识别模型把录音转成文字再丢给后端这样全家使用门槛会低很多老人和孩子不用打字也能提问。第二个是定时自动化任务。比如每天早上让本地模型总结昨天新增的文档生成一份日报推送给我。因为整套系统都在本地这种定时任务可以非常个人化不用怕数据泄露。第三个是加多用户隔离。目前这个架构所有对话历史都放在前端会话里如果家里有多个人用可以在后端增加一个简单的用户字段把每个人的搜索历史和偏好分开保存。最后再分享一个我在实际维护中的体会本地全栈项目最容易被低估的是日常维护成本模型版本更新、向量索引重建、服务崩溃恢复这些都需要投入时间。但也正因为这些事都需要自己处理你才会真正理解大模型应用是怎么协作的。想清楚这一点再动手这套折腾才值。