Gemma 4 离线知识库 Agent 实战：什么能直接照搬，什么必须先改

先看是否适合你

这篇案例最适合三类读者：已经能在本地跑 Gemma 4、准备搭建私有知识库问答系统、以及担心把个人资料放到云端 API 的用户。如果你当前只是想先把模型跑通，优先看 Gemma 4 Ollama 安装教程；如果你还不确定自己的机器是否够格，先看 显存需求页。

你的情况	建议	原因
24 GB 显卡，准备做离线 RAG + Agent	可以按本文主线复现	4090 / 3090 这一级别最接近原案例，31B Q4_K_M 有现实可行性。
12-16 GB 显卡，想做同类项目	先降到 Gemma 4 26B 或 E4B	原案例的 31B 配置会明显挤压显存，复刻成本高且稳定性差。
只有 CPU 或轻薄本	不要照抄这篇，改走轻量路线	知识库 Agent 不是只靠模型文件大小，embedding、索引和长上下文都会拖慢体验。

作者方案拆解：为什么这套组合能工作

这条公开案例的核心，不是“Gemma 4 很强”这种泛泛结论，而是它把完整的离线知识库链路配齐了：推理模型、本地 embedding、向量库、RAG 框架和可选前端各自承担不同角色。

“我现在在测试一个想法：用 Gemma 4 做一个完全离线的个人知识库 Agent，所有数据在本地，所有推理在本地，没有 API 费用，没有隐私问题。”

组件	作者选择	本文判断
推理模型	Gemma 4 31B，Q4_K_M 量化	适合 24 GB 显卡用户；对 12-16 GB 机器不友好，复现时最先考虑降级。
运行时	Ollama	这部分最值得照搬，跨平台最省事，也是团队内最好复制的一环。
RAG 框架	LlamaIndex	对文档问答和工具编排足够成熟，适合做第一版。
Embedding	nomic-embed-text	对中英混合知识库更稳，尤其是作者明确提到中文检索改进。
向量库	Chroma	本地持久化简单，适合作为个人知识库起步方案。
前端	AnythingLLM 后改为 Streamlit	这里说明“能跑起来”和“可长期迭代”是两回事，作者最终选了灵活度更高的前端。

原案例的真实硬件与数据规模

为了避免“看起来能跑，实际上环境差太多”，把作者公开给出的硬件条件单独列出来更有参考价值：

项目	公开配置	意味着什么
GPU	RTX 4090 24 GB	给 31B Q4_K_M 留出了运行余量，也方便额外跑 embedding。
CPU	AMD 7950X	重建索引、解析文档时能减少 CPU 成为瓶颈。
内存	64 GB DDR5	大文档解析和批量构建索引更稳，不容易爆内存。
存储	2 TB NVMe	知识库包含约 1800 份 PDF、Markdown 和 Notion 导出，不是小样本玩具库。

相关官方资料

如果你准备把这篇案例转成自己的项目，建议把下面几份官方或项目文档一起看，不要只依赖一条社媒帖子：

• Ollama 上的 Gemma 4 模型页面
• LlamaIndex 官方文档
• Chroma 官方文档
• nomic-embed-text 说明

最短复现步骤：先做出可用骨架，再追求“作者同款”

如果你打算把这篇案例真正落到自己机器上，建议不要一上来就追求“完全一样”。更高成功率的顺序是：先跑通模型，再跑通 embedding，再构建索引，最后加 Agent 和写回工具。

1. 安装 Ollama，先拉一个你机器能承受的 Gemma 4 版本。
2. 拉取 nomic-embed-text，确认本地 embedding 服务可用。
3. 用一小批文档建立第一版索引，而不是一次性灌入全部资料。
4. 把问答链路跑通，再接 save_to_note 这类写回工具。
5. 最后再调长上下文、增量更新、混合检索和前端界面。

ollama pull gemma4:31b
ollama pull nomic-embed-text

python -m venv .venv
source .venv/bin/activate
pip install llama-index llama-index-llms-ollama llama-index-embeddings-ollama chromadb streamlit

原帖中给出的核心 LlamaIndex 代码结构如下。它的价值不在于“可以直接复制到生产”，而在于说明这个案例确实是围绕标准 RAG 链路构建的，而不是一句“我本地做了个 Agent” 的空泛叙述。

from llama_index.core import VectorStoreIndex, SimpleDirectoryReader, Settings
from llama_index.llms.ollama import Ollama
from llama_index.embeddings.ollama import OllamaEmbedding

Settings.llm = Ollama(model="gemma4:31b", request_timeout=300.0)
Settings.embed_model = OllamaEmbedding(model_name="nomic-embed-text")
Settings.chunk_size = 1024
Settings.chunk_overlap = 200

documents = SimpleDirectoryReader("./my_knowledge_base").load_data()
index = VectorStoreIndex.from_documents(documents, show_progress=True)
index.storage_context.persist(persist_dir="./storage")

作者踩过的坑，哪些值得你提前规避

原帖最有信息密度的部分，其实是踩坑记录。下面这张表把问题、症状和修复动作抽出来，方便你直接当排错清单用。

问题	典型症状	作者修复
显存爆掉 / 上下文过大	长文档一进来就 OOM，模型启动不稳	把上下文收敛到 --ctx-size 8192，并把 chunk_size 从 2048 降到 1024。
中文检索命中率差	中文笔记搜不到，RAG 像“记性差”	改用 nomic-embed-text，再叠加中文停用词和 Hybrid Search。
Agent 幻觉和死循环	模型开始编造不存在的记录，或者一直重复工具调用	强化 system prompt，限制 max_iterations=8，再加入 self-reflection。
PDF 解析差	扫描稿、表格类 PDF 提取质量差	在入库前先做解析预处理，而不是把脏文档直接丢给索引器。
生成速度慢	只有个位数 token/s，日常使用很痛苦	改用 Q4_K_M，并尽量让 GPU 承担更多层计算。
知识库更新麻烦	每加一个文件就要整库重建	改为增量索引和定时更新，而不是每次全量 rebuild。

把原帖经验转成更稳的实施顺序

如果你的目标是尽快得到“可用而不是炫技”的离线知识库，建议按下面顺序推进：

1. 先拿 20-50 份文档试跑索引，不要一上来扔 1800 份资料。
2. 先只做问答，不做写回；这样你能分清问题是 RAG 还是 Agent。
3. 先追求命中率，再追求 256K 长上下文；后者很容易把资源吞光。
4. 最后才考虑手机端、Notion 同步、自动总结这类体验层功能。

这一步的意义在于降低“误判模型”的概率。很多人做本地 Agent 时，会把 PDF 脏数据、chunk 切分、embedding 质量、system prompt 失控，全都误判成“Gemma 4 不行”。从原案例看，更真实的结论是：模型只是链路的一环，文档和索引策略一样决定最终体验。

哪些信息最可信，哪些只能当个体经验参考

为了让这页对搜索用户和 AdSense 审核都更有说服力，必须区分“公开可复现事实”和“作者个体环境结果”。

信息类型	可信度	怎么使用
Ollama、LlamaIndex、Chroma、nomic-embed-text 的组合	高	可直接作为你的第一版架构骨架。
作者公开给出的代码片段和命令	中高	可用来理解链路，但仍建议按你的硬件替换模型 tag 和参数。
“命中率从 60% 提到 92%” 等具体数字	中	可以视为方向判断，不应当当作对所有知识库都成立的保证。
“稳定 28-35 t/s” 这类速度结论	中	高度依赖硬件、量化和上下文长度，只能作为同级机器参考。

常见问题