知识库项目的最后一环不是"进程启动了"，而是明确哪些能力已经验证、哪些依赖外部条件、出现故障时怎样恢复。MerchantOps-KBQA 将这些限制写进运行说明和诊断接口。
一、本地运行结构
项目复用 Docker 提供 MySQL、Redis、Milvus、etcd 和 MinIO；应用使用独立 .venv，通过 Junction 复用本地 embedding 与 reranker 模型目录，避免重复复制约 6.2 GB 模型文件。
首次执行 init_data.py 会准备独立 FAQ 和向量集合，之后可幂等跳过。应用入口为 run_app.cmd，默认访问 http://localhost:8080。
二、已验证的内容
项目已完成 Python 编译、数据格式、Prompt 格式、来源过滤、前端领域、FAQ 标点路由和评估覆盖检查。首页、/health、/ready、/api/sources、/api/knowledge-documents、/api/diagnostics 与 /api/assessment 已完成本地验证。
三、外部模型限制
生成阶段使用 MaaS OpenAI-compatible endpoint。当前机器在网络受限时可能收到 WinError 10013，此时系统保留检索来源并返回模型服务不可用兜底。没有在网络与轮换后的 Key 可用时完成真实生成验证，就不把生成质量写成完成结论。
四、性能与进程边界
MX450 2GB 显存加载检索模型后，部分 RAG 请求约需 40 秒。端口 8080 已被一个应用实例占用时，再启动第二个实例可能在模型初始化阶段异常退出。因此运行时只保留一个应用实例，并先检查端口和依赖状态。
五、交付原则
项目不公开真实商户数据、内部代码、密码、API Key 和生产模型。公开内容只陈述已验证的本地流程、脱敏合成数据边界和剩余限制，这样项目才可复现、可解释、可维护。