在数据分析场景中，把业务数据发送到云端大模型，往往会带来隐私、合规和成本方面的顾虑。Ollama 可以在本地运行开放模型，JupyterLab 则擅长交互式编程、数据处理与可视化。将两者结合，就能搭建一个“数据留在本机、模型辅助分析”的 AI 工作台。不过，大模型生成的代码并不天然安全，因此还需要借助容器、权限限制和人工审核建立隔离边界。🧠🔒
一、整体架构：模型服务与代码环境分离
推荐采用“两层运行”架构：Ollama 作为独立模型服务运行在宿主机或专用容器中，JupyterLab 则运行在另一个受限容器中。Notebook 只通过 HTTP API 请求模型，不直接接触模型文件和宿主机系统。
- 模型层：负责提示词推理、代码生成、结果解释和多轮对话。
- 分析层：负责读取授权数据、运行 Python、生成图表和输出结论。
- 隔离层：通过 Docker 限制目录、网络、CPU、内存和用户权限。
Ollama 提供本地 API，可使用聊天、文本生成、模型列表和嵌入等接口；部分接口默认支持流式响应，也可以关闭流式模式后一次性获取 JSON 结果，具体参数可参考 Ollama API 文档。
二、准备 Ollama 本地模型服务
安装 Ollama 后，可先拉取一个与设备资源相匹配的模型。模型越大，通常需要越多内存或显存，不应仅凭参数规模选择，而要结合机器配置、响应速度、分析复杂度和中文能力进行测试。
ollama pull qwen3:8b
ollama run qwen3:8b
模型名称和标签可能随模型库更新，实际使用前应在 Ollama 模型库 中核对。服务启动后，默认情况下可通过本机的 11434 端口调用。若使用 Docker 部署，可参照 官方 Docker 指南 配置 CPU、NVIDIA GPU 或 AMD GPU 环境。⚙️
三、在 JupyterLab 中接入模型
在 Notebook 中安装 requests 或 Ollama 官方 Python 库后，即可封装一个简单的助手函数。为了让返回内容便于处理，建议在系统提示词中明确要求模型区分“分析思路、候选代码、风险提示”，不要让模型生成内容后立即自动执行。
import requests
def ask_local_ai(question):
payload = {
"model": "qwen3:8b",
"messages": [{"role": "user", "content": question}],
"stream": False
}
r = requests.post("http://host.docker.internal:11434/api/chat", json=payload, timeout=120)
r.raise_for_status()
return r.json()["message"]["content"]
其中 host.docker.internal 在部分 Linux 环境中需要额外添加主机映射，也可以把 Ollama 与 JupyterLab 放入同一个自定义 Docker 网络，并使用容器服务名访问。生产环境应设置连接超时、异常捕获、响应长度限制和日志脱敏，避免 Notebook 因模型服务异常而长时间阻塞。
四、让 AI 真正参与数据分析
一个实用的本地分析助手，不应把完整数据集无差别塞进提示词，而应采用“先概览、再取样、后验证”的流程。第一步由 Python 读取列名、数据类型、缺失值比例和基础统计；第二步只向模型提供完成任务所必需的摘要或脱敏样本；第三步让模型生成候选分析代码；第四步由用户检查后在隔离内核中执行；最后再把运行结果交给模型解释。📊
- 限定目标，例如“分析销售额下降的可能因素”，避免使用过于宽泛的提示词。
- 删除姓名、手机号、证件号、密钥和内部地址等敏感字段。
- 要求模型优先输出短小、可审查的代码，并说明所需依赖。
- 执行后检查行数、单位、时间范围和空值处理是否符合预期。
- 把最终结论与原始统计结果交叉验证，不把模型解释当作事实来源。
五、代码安全隔离的关键实践
Jupyter 服务意味着用户可以运行任意代码，因此不能只依靠“模型在本地”来判断系统安全。Jupyter 默认提供令牌认证，相关机制可查看 来源链接 Server 安全文档；如果需要远程访问，还应通过 HTTPS、反向代理、访问控制和防火墙限制入口。
1. 使用非特权容器
JupyterLab 容器应以普通用户运行，避免使用 privileged 模式，也不要随意挂载 Docker Socket。Jupyter Docker Stacks 提供了可直接运行的基础镜像，其使用方式可参考 官方文档。启用 sudo 会扩大容器内权限，只有在隔离主机和可信使用者场景下才应谨慎开放。
2. 只挂载必要目录
不要把整个用户目录或系统根目录映射进容器。建议将原始数据目录设置为只读，把 Notebook、临时文件和导出结果分别放入独立目录。密钥应通过环境变量或专用密钥管理机制注入，不能写入 Notebook 单元格或提交到版本库。
3. 限制资源与外部网络
为容器设置内存、CPU、进程数和执行超时，可以降低死循环、内存爆炸和派生进程过多带来的风险。若分析任务不需要联网，可关闭容器外网访问；如果必须下载依赖，则使用内部镜像源或允许列表，而不是开放任意网络连接。
4. 建立“生成不等于执行”规则
对模型输出执行静态检查，重点拦截文件删除、递归改权、系统命令、动态执行、反序列化未知对象和向外部地址上传数据等行为。更稳妥的做法是让模型只生成建议代码，由人工审核后复制到新的单元格运行。对于多人平台，还可以为每次任务创建一次性容器，任务完成后立即销毁。🛡️
六、提升可维护性与可追溯性
建议固定基础镜像和 Python 依赖版本，并保存模型名称、模型标签、系统提示词、数据版本及执行时间。Notebook 中应保留关键参数和验证过程，但不要持久化敏感提示词或完整模型响应。重要分析可导出为脚本并纳入版本管理，使结果能够复现，也便于代码审查和问题追踪。
总结
Ollama 与 JupyterLab 的组合，可以在本地完成代码生成、数据探索、图表制作和结果解释，适合对隐私与可控性要求较高的个人或团队。真正可靠的方案并不是让 AI 自动接管 Notebook，而是将模型服务、数据环境和执行权限明确分层，并落实脱敏、只读挂载、非特权运行、资源限制、网络控制和人工审核。只有把 AI 当作“候选方案生成器”，把验证权牢牢留在分析人员手中，本地数据分析助手才能兼顾效率、安全与可追溯性。
