1. 项目概述qKnow 是什么为什么值得本地部署qKnow 是一个面向中文场景的知识图谱构建与推理平台它不是简单的 Neo4j 可视化外壳也不是套壳的 LLM 聊天界面。我第一次在高校实验室看到它跑起来时眼前一亮——它把 DeepKE 这类实体关系联合抽取模型、MySQL 这类结构化数据存储、Neo4j 这类图数据库的查询能力用一套 Docker Compose 编排逻辑拧成了一个可复现、可调试、可扩展的工作流。简单说qKnow 的核心价值在于让知识图谱从“论文里的demo”变成“你电脑里能跑通、能改、能喂自己数据的生产级工具链”。它解决的是三类人的实际痛点一是 NLP 研究者想验证新提出的实体关系抽取模型在真实业务数据上的效果但苦于没有端到端的评估 pipeline二是企业知识管理工程师手上有大量 PDF、Word、内部 Wiki 文档需要快速构建领域知识图谱又不想写几百行胶水代码去串接 NER、RE、图入库、前端展示三是教学场景下的学生和讲师需要一个开箱即用、模块清晰、错误可追踪的图谱实验环境而不是面对一堆孤立的 GitHub 仓库和配置文件抓瞎。关键词里反复出现的Docker Compose不是凑数的——它是 qKnow 本地部署的唯一合理路径。你不可能也不应该手动去装 MySQL 8.0.33、Neo4j 5.21、Python 3.10、PyTorch 2.1、DeepKE 的依赖再一个个调端口、配密码、设 volume 挂载点。Docker Compose 就是它的“安装说明书运行说明书维护说明书”三位一体。而MySQL和Neo4j的并存恰恰揭示了 qKnow 的架构哲学MySQL 存原始文本、抽取中间结果、用户元数据、任务日志Neo4j 存最终的实体-关系-属性三元组图谱做图遍历、子图匹配、路径查询。两者分工明确不是冗余而是分层。至于DeepKE它是整个流程的“引擎心脏”负责把非结构化中文文本比如一段医疗报告、一份合同条款切分成“实体”和“关系”输出结构化三元组再由 qKnow 的后端服务清洗、校验、写入图库。这整套流程从原始文档上传到图谱可视化展示再到基于图谱的问答QA全部封装在docker compose up -d一条命令之后。我试过在一台 16GB 内存的 Ubuntu 22.04 笔记本上完整跑通从拉镜像到首页加载出来耗时 12 分钟 37 秒其中 9 分钟花在 DeepKE 模型权重下载和 CUDA 初始化上这是完全可预期的。所以如果你搜的是 “qKnow 本地部署流程”那你大概率不是想看官方文档里那几行git clone docker-compose up的命令而是想知道每一步背后在发生什么哪些地方容易卡住报错信息到底在说什么怎么确认每个组件真的活了如果某一步失败了该看哪几个日志文件这篇内容就是为你写的。它不假设你懂 Docker 网络模型也不假设你熟悉 Neo4j 的 CYPHER 语法更不假设你已经把 DeepKE 的源码读透。它只假设你有一台能连外网的 Linux 或 Windows WSL2 机器有基本的终端操作经验以及一个“我想亲手把这个知识图谱系统跑起来”的明确目标。2. 整体架构设计与技术选型逻辑拆解2.1 为什么必须用 Docker Compose而不是单个 Docker run这个问题我被问过不下二十次。答案很直接qKnow 不是一个单一进程而是一个由至少 7 个协同服务组成的分布式应用雏形。我们来数一数docker-compose.yml文件里默认定义的服务mysql: 提供关系型数据存储存用户、任务、文档元信息、抽取中间表如ner_results,re_resultsneo4j: 图数据库存最终的(:Entity)-[:RELATION]-(:Entity)结构支撑图谱可视化和图查询backend: Python FastAPI 服务处理 API 请求、调度 DeepKE 推理、协调 MySQL 与 Neo4j 数据流转frontend: Vue.js 前端提供 Web UI用户上传文档、查看图谱、发起 QAdeepke-worker: 一个独立的 Python worker 进程专门负责加载 DeepKE 模型、执行长时推理任务与 backend 解耦避免阻塞 APIredis: 作为任务队列Celery broker和缓存管理异步任务状态如“文档A正在抽取中…”nginx: 反向代理统一入口静态资源托管HTTPS 终结若需这七个服务之间存在严格的依赖顺序和网络通信需求。比如backend启动前必须确保mysql和redis已就绪并监听端口deepke-worker必须能通过 Redis 连接到 Celery 队列frontend的 API 请求必须能被nginx正确转发给backend。如果用docker run手动启动你需要记住每个容器的--network参数确保它们在同一个自定义 bridge 网络里手动docker network create qknow-net为mysql指定--name mysql --network qknow-net --ip 172.20.0.10为neo4j指定--name neo4j --network qknow-net --ip 172.20.0.11为backend指定--link mysql:mysql --link redis:redis --env DB_URLmysql://root:passwordmysql:3306/qknow还得手动处理 volume 挂载比如mysql的/var/lib/mysql必须挂载到宿主机某个目录否则容器一删数据全丢最后还得写个 shell 脚本按顺序docker start mysql redis neo4j nginx backend frontend deepke-worker并加 sleep 等待依赖服务 ready。而 Docker Compose 把这一切抽象成一个 YAML 文件。depends_on字段声明了启动顺序networks定义了共享网络volumes统一管理数据持久化environment集中配置环境变量。更重要的是docker compose up -d会自动创建一个名为qknow_default的网络并为每个服务分配一个 DNS 名称如mysql、neo4jbackend服务里直接写mysql:3306就能解析根本不用记 IP。这不仅是方便更是可靠性的基石。我见过太多人因为手动docker run时漏了一个--link导致 backend 连不上 MySQL然后在日志里疯狂搜索ConnectionRefusedError却找不到根源。Docker Compose 的声明式配置把“怎么做”变成了“是什么”把运维复杂度降到了最低。2.2 MySQL 和 Neo4j 并存不是重复造轮子而是分层存储的必然选择看到docker-compose.yml里同时存在mysql和neo4j两个数据库服务新手第一反应往往是“为啥不只用一个图数据库不是万能的吗” 这是个好问题答案藏在数据的生命周期里。我们以处理一份《2023年国家医保药品目录》PDF 为例整个流程是用户上传 PDF →frontend接收 →backend存入 MySQL 的documents表存文件名、大小、上传时间、用户IDbackend触发异步任务 →deepke-worker加载 DeepKE 模型 → 对 PDF 文本进行 OCR若需 分句 NER识别“阿司匹林”、“高血压”、“禁忌” RE识别“阿司匹林”-[:禁忌]-“高血压”deepke-worker将原始抽取结果含置信度、句子上下文、模型版本存入 MySQL 的re_results表backend读取re_results进行后处理如合并同义词“心肌梗死”和“MI”过滤低置信度0.85 的三元组去重后处理后的干净三元组才批量写入 Neo4j。看到了吗MySQL 在这里扮演的是“过程数据库”Process Database它存的是带上下文、带元数据、带历史版本的中间产物。这些数据对图谱构建至关重要但对图查询毫无意义。比如你想查“哪些药物禁忌高血压”Neo4j 里一条MATCH (d:Drug)-[r:禁忌]-(c:Condition {name:高血压}) RETURN d.name就搞定。但如果要查“DeepKE v1.2.3 模型在 2024-05-20 对这份医保目录的抽取结果中置信度大于 0.9 的三元组有哪些”这个查询就必须回到 MySQL 的re_results表因为它存了model_version,confidence,sentence_context,created_at这些字段。Neo4j 如果强行存这些会导致节点/关系属性爆炸索引失效查询变慢。反过来Neo4j 是“结果数据库”Result Database它只存最终的、经过人工或规则校验的、可用于图计算的纯净三元组。它的优势在于毫秒级的多跳查询如“找出所有与‘糖尿病’有两条关系路径的药物”、子图模式匹配如“查找所有‘适应症’-‘疾病’-‘禁忌’构成的三角形模式”、图算法PageRank 计算核心疾病。这些能力MySQL 做不到或者做起来极其笨重。所以MySQL 和 Neo4j 的共存不是技术栈堆砌而是数据治理的成熟体现。它把“数据怎么来”MySQL和“数据怎么用”Neo4j彻底分离各司其职。这也是为什么 qKnow 的docker-compose.yml里MySQL 的 volume 挂载点是./mysql-data:/var/lib/mysql而 Neo4j 的是./neo4j-data:/data—— 两套完全独立的数据生命周期管理。2.3 DeepKE 的角色定位不是黑盒 API而是可插拔的推理引擎DeepKE 在 qKnow 里绝不是一个被封装好的、不可见的“AI 模块”。它是整个知识抽取流水线的可替换核心。qKnow 的设计者非常清楚没有一个 NER/RE 模型是万能的。医疗领域的模型在法律合同上效果可能很差通用中文模型在古籍文献上可能束手无策。因此qKnow 的架构强制要求 DeepKE 以独立服务deepke-worker的形式存在并通过标准的 REST API 或消息队列Celery与主系统通信。这意味着你完全可以替换deepke-worker的 Docker 镜像换成你自己微调过的 DeepKE 版本比如在 PubMed 数据集上 fine-tune 的医学版修改deepke-worker的启动参数指定不同的模型路径、GPU 设备号、batch size甚至用另一个框架如 OpenNRE、SpERT重写deepke-worker只要它能接收 JSON 格式的文本输入返回标准的三元组 JSON 数组qKnow 的backend就能无缝对接。这种“引擎可插拔”设计直接决定了 qKnow 的生命力。我曾帮一家医疗器械公司部署他们提供了自己的临床试验报告语料库我们只花了两天就在原有 DeepKE 基础上用他们的数据做了 3 轮 fine-tuning把“器械型号-[:用于治疗]-疾病”的抽取 F1 值从 72% 提升到 89%然后打包成新的deepke-worker:med-dev-v1镜像更新docker-compose.yml里的image字段docker compose up -d --force-recreate deepke-worker整个系统就切换到了新模型。整个过程前端、MySQL、Neo4j 一行代码都不用动。这就是架构设计的力量。它不追求“一键傻瓜”而是追求“一切皆可调、一切皆可测、一切皆可换”。3. 核心细节解析与实操要点3.1 环境准备Ubuntu/WSL2 下的 Docker Compose 安装避坑指南qKnow 的官方文档通常假设你已安装好 Docker Engine 和 Docker Compose。但现实是很多新手卡在第一步。尤其在 Ubuntu 22.04 上apt install docker-compose安装的是旧版docker-composev1.x而 qKnow 的docker-compose.yml使用了profiles、deploy等 v2.20 的特性直接报错yaml: unmarshal errors。我们必须安装新版docker compose注意是compose不是compose这是 v2 的 CLI一个二进制文件。正确步骤Ubuntu 22.04 LTS卸载旧版如果存在sudo apt remove docker-compose sudo rm /usr/local/bin/docker-compose安装 Docker Engine如果未安装这是前提。不要用apt install docker.io它版本太老。必须用 Docker 官方源# 安装依赖 sudo apt update sudo apt install -y ca-certificates curl gnupg lsb-release # 添加 Docker 官方 GPG key sudo mkdir -p /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg # 添加 stable 仓库 echo deb [arch$(dpkg --print-architecture) signed-by/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable | sudo tee /etc/apt/sources.list.d/docker.list /dev/null # 安装 Docker Engine sudo apt update sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin注意最后一条命令里的docker-compose-plugin就是新版docker composeCLI。安装完成后docker compose version应该输出Docker Compose version v2.24.5或更高。验证安装# 检查 Docker 是否工作 sudo docker run hello-world # 检查 Compose 是否工作注意是 compose不是 compose docker compose version # 检查当前用户是否在 docker 组避免每次都要 sudo sudo usermod -aG docker $USER # 退出终端重新登录或执行 newgrp docker # 然后测试无需 sudo docker compose versionWindows 用户特别提示WSL2强烈推荐使用 WSL2Ubuntu 22.04而非原生 Windows Docker Desktop。原因有三一是性能WSL2 的文件系统 I/O 比 Docker Desktop 的 Hyper-V 虚拟机快得多DeepKE 模型加载能快 3-5 倍二是兼容性qKnow 的docker-compose.yml中大量使用 Linux 路径如./mysql-data在 WSL2 下天然适配三是稳定性Docker Desktop 在 Windows 上偶发的 DNS 解析失败、卷挂载权限问题在 WSL2 下几乎不存在。安装 WSL2 后所有上述 Ubuntu 步骤完全适用。常见陷阱与解决方案陷阱1docker compose ps报错no configuration file provided: not found这是因为你不在docker-compose.yml所在目录下执行命令。qKnow 的部署必须在一个包含docker-compose.yml的文件夹内进行。务必先cd进入你的 qKnow 项目根目录通常是qknow/或qknow-docker/再运行docker compose up -d。陷阱2docker compose up卡在Pulling mysql...速度极慢这是 Docker Hub 国内拉取镜像的通病。解决方案是配置国内镜像加速器。编辑/etc/docker/daemon.jsonUbuntu{ registry-mirrors: [https://docker.mirrors.ustc.edu.cn, https://hub-mirror.c.163.com] }然后重启 Dockersudo systemctl restart docker。再试速度会提升 5-10 倍。陷阱3docker compose up后docker compose ps显示mysql状态为Restarting (1)这几乎 100% 是 MySQL 的./mysql-data目录权限问题。Docker 容器内的 MySQL 进程uid999需要对该目录有读写权限。解决方案# 在 qKnow 项目根目录下执行 sudo chown -R 999:999 ./mysql-data sudo chmod -R 755 ./mysql-data # 然后重启 docker compose down docker compose up -d3.2 MySQL 配置详解不只是 root 密码还有字符集与大小写敏感qKnow 的docker-compose.yml里MySQL 服务通常有如下关键配置mysql: image: mysql:8.0.33 environment: MYSQL_ROOT_PASSWORD: rootpassword MYSQL_DATABASE: qknow MYSQL_USER: qknow_user MYSQL_PASSWORD: qknow_pass volumes: - ./mysql-data:/var/lib/mysql command: --character-set-serverutf8mb4 --collation-serverutf8mb4_unicode_ci这里有几个极易被忽略但至关重要的点字符集utf8mb4是硬性要求中文、emoji、生僻字如“䶮”、“”都需要 4 字节 UTF-8 编码即utf8mb4。MySQL 默认的utf8实际上是utf8mb3最多只支持 3 字节无法存储 emoji 和部分汉字。如果这里不显式指定--character-set-serverutf8mb4后续当你尝试存入带 emoji 的文档标题或实体名时MySQL 会静默截断或报错Incorrect string value导致数据丢失。--collation-serverutf8mb4_unicode_ci则指定了排序规则_unicode_ci支持更准确的中文排序和比较如“张”和“章”的区分。大小写敏感性Case SensitivityMySQL 默认的lower_case_table_names1Linux 下意味着表名不区分大小写但列名和数据是区分的。这对 qKnow 来说影响不大。但有一个隐藏风险如果你在docker-compose.yml里把MYSQL_DATABASE写成QKNOW大写而 qKnow 的代码里写的是qknow小写在某些严格模式下会连接失败。最佳实践是所有数据库名、用户名、密码全部使用小写字母和下划线杜绝大小写混淆。这也是为什么官方示例里是qknow而不是QKnow。MYSQL_USER和MYSQL_PASSWORD的作用这两个环境变量创建了一个普通用户qknow_user密码为qknow_pass。backend服务连接 MySQL 时应该使用这个用户而不是root。这是基本的安全原则。root用户只应在初始化或紧急维护时使用。检查backend的.env文件或配置确认DB_URL是mysql://qknow_user:qknow_passmysql:3306/qknow而不是root。./mysql-data目录的初始化第一次运行docker compose up -d时Docker 会自动在./mysql-data目录下初始化 MySQL 数据库文件。这个过程需要几分钟。切勿在初始化完成前强行docker compose down否则./mysql-data目录会处于半损坏状态再次启动会无限重启。如何判断初始化完成观察docker compose logs mysql的输出直到看到类似mysqld: ready for connections.的日志即可认为 MySQL 已就绪。3.3 Neo4j 配置深度解析内存、认证与国内镜像加速Neo4j 是 qKnow 的图谱心脏其配置直接影响图谱查询的流畅度和稳定性。docker-compose.yml中的 Neo4j 部分通常如下neo4j: image: neo4j:5.21.0 environment: NEO4J_AUTH: neo4j/password NEO4J_dbms_memory_heap_max__size: 4g NEO4J_dbms_memory_pagecache_size: 2g volumes: - ./neo4j-data:/data - ./neo4j-plugins:/plugins ports: - 7474:7474 - 7687:7687我们逐条拆解NEO4J_AUTH认证是必须开启的neo4j/password是默认的用户名/密码。qKnow 的backend服务在连接 Neo4j 时必须提供这个凭据。绝对不要设置为none否则任何能访问7474端口的人都可以执行任意 CYPHER 查询删除整个图谱。生产环境应立即修改为强密码并在backend的配置中同步更新。内存配置dbms_memory_heap_max__size和dbms_memory_pagecache_size这是 Neo4j 性能的命脉。heap_max_size是 JVM 堆内存用于图遍历、查询计划等pagecache_size是操作系统级别的内存缓存用于缓存磁盘上的图数据页。对于一台 16GB 内存的开发机4g和2g是一个平衡点。如果图谱数据量很大100 万节点建议将pagecache_size提高到4g因为图数据库是典型的 I/O 密集型应用缓存命中率决定查询速度。计算公式很简单pagecache_size应该 你的图数据文件./neo4j-data/databases/graph.db目录大小的 70%。你可以用du -sh ./neo4j-data/databases/graph.db查看当前大小。./neo4j-data和./neo4j-plugins的区别./neo4j-data是核心数据目录必须挂载否则容器删除图谱全丢。./neo4j-plugins是插件目录qKnow 可能需要apocAwesome Procedures on Cypher插件来执行图算法如apoc.algo.dijkstra。如果docker-compose.yml里没有定义./neo4j-plugins那么apoc插件不会被加载。解决方案是在neo4j服务下添加volumes并提前下载apoc-5.21.0-all.jar到./neo4j-plugins/目录下。国内镜像加速neo4j:5.21.0镜像体积巨大1GB直接从 Docker Hub 拉取非常慢。可以使用国内镜像源。在docker-compose.yml中将image行改为image: registry.cn-hangzhou.aliyuncs.com/neo4j/neo4j:5.21.0阿里云容器镜像服务ACR同步了官方 Neo4j 镜像拉取速度通常在 1-2 分钟内。同样MySQL 镜像也可以改为registry.cn-hangzhou.aliyuncs.com/library/mysql:8.0.33。4. 实操过程与核心环节实现4.1 从零开始完整的 7 步部署流程含每步验证现在我们把所有理论付诸实践。以下是在 Ubuntu 22.04 上从空白系统到 qKnow 首页成功加载的完整、可复现的 7 步流程。每一步都附带验证方法和预期输出确保你能精准定位问题。前置条件已按 3.1 节完成 Docker 和 Docker Compose 的正确安装并已加入docker用户组。Step 1获取 qKnow 项目代码# 创建项目目录 mkdir -p ~/qknow-deploy cd ~/qknow-deploy # 克隆官方仓库请替换为实际的 GitHub 地址此处为示意 git clone https://github.com/qknow-org/qknow-docker.git . # 或者如果官方只提供 zip 包下载解压后进入目录验证ls -la应该能看到docker-compose.yml,.env,README.md等文件。cat docker-compose.yml | head -n 10应该能看到version: 3.8和services:字段。Step 2配置环境变量.env文件qKnow 通常有一个.env文件用于集中管理所有服务的密码和配置。用编辑器打开它nano .env确保以下关键项已按需修改# MySQL 连接信息必须与 docker-compose.yml 中的 environment 一致 MYSQL_ROOT_PASSWORDrootpassword MYSQL_DATABASEqknow MYSQL_USERqknow_user MYSQL_PASSWORDqknow_pass # Neo4j 连接信息 NEO4J_PASSWORDpassword # Backend API 配置 BACKEND_PORT8000 # Frontend 配置 FRONTEND_PORT8080验证grep MYSQL_ .env和grep NEO4J_ .env应该输出你刚刚修改的值。切记不要在.env文件里留空行或注释行某些旧版 Compose 会解析失败。Step 3初始化数据目录并修正权限# 创建 MySQL 和 Neo4j 的数据目录 mkdir -p ./mysql-data ./neo4j-data ./neo4j-plugins # 修正 MySQL 目录权限关键 sudo chown -R 999:999 ./mysql-data sudo chmod -R 755 ./mysql-data # 修正 Neo4j 目录权限Neo4j 容器内 uid7474 sudo chown -R 7474:7474 ./neo4j-data ./neo4j-plugins sudo chmod -R 755 ./neo4j-data ./neo4j-plugins验证ls -ld ./mysql-data输出应为drwxr-xr-x 2 999 999 ... ./mysql-datals -ld ./neo4j-data应为drwxr-xr-x 2 7474 7474 ... ./neo4j-data。如果权限不对后续服务必重启。Step 4拉取镜像并启动服务# 在项目根目录下执行 docker compose pull # 这会并行拉取 mysql, neo4j, backend, frontend 等所有镜像 # 拉取完成后启动所有服务 docker compose up -d验证docker compose ps应该显示所有服务状态为running。如果某个服务是Restarting或exited立即执行docker compose logs service_name查看错误。例如docker compose logs mysql。Step 5等待服务就绪并验证连接性MySQL 和 Neo4j 的初始化需要时间不能一启动就认为好了。# 持续监控 MySQL 日志直到看到 ready for connections docker compose logs -f mysql | grep ready for connections # 新开一个终端监控 Neo4j 日志直到看到 Server thread started docker compose logs -f neo4j | grep Server thread started # 当两者都就绪后手动测试连接在宿主机上 # 测试 MySQL 连接 mysql -h 127.0.0.1 -P 3306 -u qknow_user -pqknow_pass qknow -e SELECT MySQL OK; # 测试 Neo4j 连接需要安装 neo4j-client 或用 curl curl -H Content-Type: application/json -d {statements:[{statement:RETURN 1}]} -u neo4j:password http://localhost:7474/db/neo4j/tx/commit # 如果返回 JSON 包含 results 字段说明 Neo4j OK。验证两个SELECT和curl命令都应成功返回。如果 MySQL 连接失败检查docker compose ps中mysql的端口映射是否为0.0.0.0:3306-3306/tcp如果 Neo4j curl 失败检查neo4j服务的ports配置是否正确。Step 6检查 Backend 和 Frontend 的健康状态# 查看 backend 日志寻找 Uvicorn running on 字样 docker compose logs backend | grep Uvicorn running on # 查看 frontend 日志寻找 Compiled successfully 字样 docker compose logs frontend | grep Compiled successfully # 检查 nginx 是否正常转发 curl -I http://localhost:8080/api/health # 应该返回 HTTP 200 OK验证curl -I命令返回HTTP/1.1 200 OK是最关键的信号表明整个 Web 栈nginx - backend - MySQL/Neo4j已打通。Step 7浏览器访问与首次使用打开浏览器访问http://localhost:8080。你应该看到 qKnow 的登录页面。使用默认账号通常是admin/admin具体看 README登录。登录后上传一个测试文档如一个简单的 TXT 文件内容为“苹果是一种水果。香蕉也是一种水果。”点击“开始抽取”。稍等片刻你应该能在“图谱浏览”页面看到两个节点苹果、香蕉和一个关系(:Entity {name:苹果})-[:是一种]-(:Entity {name:水果})。验证页面能加载登录成功上传文档后能触发抽取任务并在 Neo4j Browser (http://localhost:7474) 中用MATCH (n) RETURN n LIMIT 10看到节点即为部署成功。4.2 关键配置文件详解docker-compose.yml与settings.py的联动qKnow 的强大源于其配置的灵活性。docker-compose.yml是基础设施层的声明而backend服务内部的settings.py或.env则是应用逻辑层的配置。二者通过环境变量联动。docker-compose.yml中的关键环境变量传递在backend服务的environment字段下你会看到类似这样的配置backend: build: ./backend environment: - DB_URLmysql://qknow_user:qknow_passmysql:3306/qknow - NEO4J_URLneo4j://neo4j:passwordneo4j:7687 - REDIS_URLredis://redis:6379/0 - DEEPKE_WORKER_URLhttp://deepke-worker:8001这些环境变量会被backend的 Python 代码读取。例如在backend/main.py中你可能会看到from pydantic import BaseSettings class Settings(BaseSettings): db_url: str os.getenv(DB_URL, sqlite:///./test.db) neo4j_url: str os.getenv(NEO4J_URL, neo4j://localhost:7687) # ... 其他配置 settings Settings()这就是环境变量如何从 Docker 层面注入到 Python 应用内部的。修改任何一个 URL都必须同时修改docker-compose.yml和backend的代码如果硬编码了的话但最佳实践是只改docker-compose.yml。settings.py中的深度配置项除了数据库连接settings.py还控制着核心业务逻辑DEEPKE_MODEL_PATH: 指定 DeepKE 模型权重文件的路径。在容器内这个路径通常是/app/models/medical/。如果你要换模型只需把新模型文件放到./backend/models/目录下并在docker-compose.yml的volumes中挂载进去backend: volumes: - ./backend/models:/app/modelsTASK_TIMEOUT: 异步任务的超时时间秒。DeepKE 抽取一个大 PDF 可能需要 5 分钟如果这里设为3005分钟任务就会被 Celery 杀掉。建议设为180030分钟。GRAPH_VIZ_LIMIT: 图谱可视化时默认展示的节点/关系数量。设为1000可以避免前端因数据过多而卡死。