用户隐私协议与模型服务协议

用户隐私协议与模型服务协议【免费下载链接】LightRAG[EMNLP2025] LightRAG: Simple and Fast Retrieval-Augmented Generation项目地址: https://gitcode.com/GitHub_Trending/li/LightRAG用户隐私协议…模型服务协议… **合并的文档必须自己署名。** 前端的兜底链接文字是通用的「隐私政策协议」。只要你的文件除了隐私政策还包含别的内容——模型服务协议、服务条款、可接受使用政策等——这个兜底就低估了访问者正在勾选的范围请用 consent_documents 填上它真实的名称。 这也包括该字段出现之前写好的 bundle它们照常加载但勾选框现在显示的是「隐私政策协议」。**如果你的 agreements.md 合并了多份文档请在升级时补上 consent_documents。** #### 给链接命名 consent_documents 就是勾选框中被做成链接的那段文字——填写你的部署对这份文档的真实称呼即可 jsonc consent_documents: 《示例公司服务条款》链接外围的那句话「同意……」仍然来自前端自身的翻译因此在每种界面语言下都是自然的表达可定制的只是文档的名称。不写这个字段时链接的名称也由该翻译提供——即通用的「隐私政策协议」中文为《隐私政策协议》它只适合确实就是一份隐私政策的文件其它情况都会低估实际范围见上面的提示。弹窗会显示什么弹窗会原样渲染agreements.md不会在其上方再打印一行标题。因此请给这个文件写上它自己的标题该标题就是屏幕上这份文档的标题。# 用户隐私协议与模型服务协议 ## 用户隐私协议 …代码不会去读这份文档——弹窗只负责渲染它。读屏软件朗读的弹窗名称取自勾选框自己的链接文字consent_documents未声明时为前端的兜底值那也正是访问者刚刚勾选的东西。这个名称与文件标题是否一致、与文件实际内容是否相符由你自己维护。标题、段落、列表、表格、引用块、代码块、分隔线和链接都会以标准的文档排版渲染。Markdown 中的原始 HTML 会被丢弃——与其它所有 bundle 模板一致见 §10。6.2 需要知道的规则要么都写要么都不写。只写login会得到一个有品牌文案但没有门禁的登录页只写agreements则是一份没有任何入口链接的文档。两者都不会开启门禁——半份配置就按半份配置处理不会被当作已获得同意。按 locale 生效。解析到的 locale 若两个字段都没声明访问者就看不到勾选框。请为每个需要门禁的 locale 都声明这一对字段或者用fallbacks把未覆盖的 locale 导向已声明的 locale。声明了但内容为空的文件会导致启动失败。门禁绝不能指向一份空白文档。consent_documents为空白字符串同样会失败。链接文字可选文档不可选。单独写consent_documents永远不会开启门禁某个 locale 只声明了loginagreements而没写它勾选框照常工作只是名称来自前端翻译。勾选状态不会被记住。它只存活于登录页本身并且绑定到屏幕上那份文档的确切文本因此每次访问都需要重新勾选。中途切换界面语言会替换文档并清除勾选除非新 locale 的文本逐字节相同。仅作用于 WebUI不覆盖 API。同上POST /login没有同意相关字段因此该门禁只约束前端登录表单此外别无约束。仅覆盖账号密码登录。未配置认证AUTH_ACCOUNTS未设置的部署会以 guest 身份直接放行不受门禁约束。这是刻意设计而非缺口没有认证就没有可被约束的用户身份而免认证本就是开发/演示形态。若必须要求接受协议请配置AUTH_ACCOUNTS并配置TOKEN_SECRET。接口不可达只在「首次加载」时 fail-open。若第一次定制内容请求就失败此时没有任何快照前端回落到自带的默认内容门禁保持关闭而不是把所有人锁在部署之外。而「语言切换失败」保留的是上一次成功的裁决。一旦已经加载过快照切换到另一个 locale 的请求失败时屏幕上仍是那份旧快照重试耗尽后门禁重新按它执行。因此若先前加载的 locale 需要勾选勾选框依然存在——访问者仍受其最后看到的那份协议约束不会因为一次网络故障被放行。这是两者中更安全的一种且是刻意为之只有从未加载成功过的情况才会打开门禁。7. 部署7.1 模板目录放在哪里部署方式模板目录UI_TEMPLATES_DIR源码部署lightrag_webui/ui_templates/已 gitignore./lightrag_webui/ui_templatesDocker / Compose宿主机./data/ui_templates/→ 容器/app/data/ui_templates/app/data/ui_templatesKubernetesConfigMap 或 PVC 挂载到/app/data/ui_templates/app/data/ui_templates相对路径以服务器进程的工作目录为基准解析因此在不确定进程从哪里启动时使用绝对路径更稳妥。7.2 Docker Composedocker-compose.yml和docker-compose-full.yml都已内置这两半配置services: lightrag: volumes: - ./data/ui_templates:/app/data/ui_templates:ro environment: UI_TEMPLATES_DIR: /app/data/ui_templates在你写入模板包之前两者都是惰性的。已配置但不含manifest.json的目录被视为「尚未填充的挂载点」而不是「损坏的模板包」服务器记录一条写明该目录的警告继续提供内置品牌内容。因此默认部署可以正常启动而启用该功能的全部步骤就是把模板包放进./data/ui_templates再重启——永远不需要改 compose。这种宽容止步于 manifest一旦manifest.json存在模板包就会被完整校验任何问题都会导致拒绝启动见 §9——复制到一半的模板包绝不会被悄悄降级成 LightRAG 内容。三点实务提示首次up之前先创建该目录。如果交给 Docker 自动创建目录属主会是root之后往里复制文件需要sudo。挂载落错位置现在表现为「品牌内容没变」而不是启动失败——这是「开箱即可启动」的代价。区分它与「我还没写模板包」的手段是启动警告和/ui/customization的customized: false两者都会写明服务器实际读到的路径。:ro是刻意的——服务器只读取模板包从不写入。Podmandocker-compose.podman.yml里挂载和UI_TEMPLATES_DIR都仍是注释掉的。Podman 对「宿主机源不存在」的绑定挂载比 Docker 更严格无条件挂载会把该功能变成所有人的启动前置条件。在那里请先mkdir -p ./data/ui_templates再同时取消注释两者。这一条刻意压过.env。compose 的environment:条目优先级高于挂载进容器的.env中的同名 keyUI_TEMPLATES_DIR正是要利用这一点——与WORKING_DIR、INPUT_DIR、PROMPT_DIR完全一致。这个值是容器内路径把它挡在.env之外才能让同一份.env里面写的是./lightrag_webui/ui_templates这类宿主机路径同时服务源码运行与本部署。因此在.env里设置UI_TEMPLATES_DIR只影响源码运行容器使用的是 compose 中的值。若要让容器指向别处的模板包请改 compose 中的这一条向导会保留它见 §7.3或改挂载的宿主机一侧。7.3 向导生成的 compose 文件make env-base/make env-storage/make env-server会生成docker-compose.final.yml这套向导的完整背景见 docs/InteractiveSetup.md。生成器现在会在该挂载不存在时补上同样的只读挂载因此重新生成已有文件即可获得make env-server # 或任意其他 make env-* 目标 grep ui_templates docker-compose.final.yml向导同时会把UI_TEMPLATES_DIR: /app/data/ui_templates作为种子值写入lightrag服务的environment:块因此向导生成的部署与仓库自带的 compose 文件行为完全一致在./data/ui_templates出现模板包之前保持惰性。只播种、不接管——向导绝不改动你填写的值。WORKING_DIR/INPUT_DIR/PROMPT_DIR每次运行都会被重写手工改动不会保留UI_TEMPLATES_DIR只在 compose 文件尚未声明该键时才写入你在docker-compose.final.yml中手工修改的值会在每次重新生成后原样保留——包括UI_TEMPLATES_DIR: 部署用它关闭该功能以及 list 风格下的- UI_TEMPLATES_DIR。若要从其它宿主机目录提供模板包完全不需要改环境变量改挂载的宿主机一侧即可./my-branding:/app/data/ui_templates:ro。种子值同样压过.env这正是让.env中的宿主机路径UI_TEMPLATES_DIR仍可用于源码运行的前提见 §7.2。用户新增的绑定挂载和其它用户新增的环境变量与之前一样在重新生成时被保留。7.4 Kubernetes自带的 Helm Chart 目前还没有专门的配置项因此需要自行修改 Deployment 来挂载模板包Chart 的位置在 k8s-deploy/lightrag/可参考其deployment.yaml的结构做扩展。ConfigMap 没有目录结构。它的 key 是扁平的每个 key 直接成为挂载点下的一个文件--from-file目录只会把该目录下的文件按其基本名打包并跳过所有子目录。因此以 ConfigMap 方式交付的模板包必须是扁平的且 manifest 中的路径要与这些 key 完全一致。直接照搬嵌套的示例布局会导致启动失败报locales/zh/welcome.md does not exist or is not a file。为这种部署单独写一份扁平的 manifest{ schema_version: 1, default_locale: zh, brand: { logo: logo.svg }, locales: { zh: { welcome: welcome.zh.md, query_empty: query_empty.zh.md, login: login.zh.md, agreements: agreements.zh.md, logo_alt: 示例公司 } } }并逐个显式指定被引用的文件包括 Logo——key路径的形式已经完成了扁平化因此你的源码目录可以保持嵌套。manifest 引用了但 ConfigMap 中缺失的文件会导致启动失败kubectl create configmap lightrag-ui-templates \ --from-filemanifest.json./k8s/ui-manifest.json \ --from-filewelcome.zh.md./ui_templates/locales/zh/welcome.md \ --from-filequery_empty.zh.md./ui_templates/locales/zh/query_empty.md \ --from-filelogin.zh.md./ui_templates/locales/zh/login.md \ --from-fileagreements.zh.md./ui_templates/locales/zh/agreements.md \ --from-filelogo.svg./ui_templates/assets/logo.svg \ --dry-runclient -o yaml | kubectl apply -f -非 UTF-8 的 LogoPNG、JPEG、WebP会被kubectl自动放入 ConfigMap 的binaryData。但请注意 ConfigMap 总大小上限约为 1 MiB低于本功能单个 Logo 2 MiB 的限制Logo 较大的模板包需要改用 PVCPVC 同时也允许保留嵌套目录结构。然后在容器上添加volumeMounts: - name: ui-templates mountPath: /app/data/ui_templates readOnly: true env: - name: UI_TEMPLATES_DIR value: /app/data/ui_templates volumes: - name: ui-templates configMap: name: lightrag-ui-templatesmountPath要与UI_TEMPLATES_DIR保持一致。投射卷内部的..data符号链接始终指向挂载点内部因此模板包的路径包含性校验可以通过——扁平的 ConfigMap 挂载与磁盘上的普通目录加载表现完全一致。更新 ConfigMap不会重新加载模板包请重启 Pod见 §7.5。7.5 让修改生效没有热加载。整个模板包在启动时被一次性校验并作为不可变的内存快照激活此后处理请求不再访问磁盘。修改模板包后需要重启服务器——使用lightrag-gunicorn或任何多 worker 部署时必须重启所有worker否则部分 worker 仍在提供旧版本内容。不需要手动清缓存文案接口以Cache-Control: no-store返回Logo 的 URL 内嵌文件内容哈希字节变化就会产生新的 URL资产响应为public, max-age31536000, immutable的长期缓存见 lightrag/api/routers/ui_customization_routes.py。8. 验证部署结果启动日志。以下三行必有其一INFO: UI customization: no bundle configured (UI_TEMPLATES_DIR unset) WARNING: UI customization: UI_TEMPLATES_DIR/app/data/ui_templates holds no manifest.json — serving the built-in LightRAG branding. … INFO: UI customization: bundle sha256 [en, zh]中间那一行就是 Docker 默认状态变量由自带的 compose 文件设置而挂载的目录还是空的。它被记为 WARNING 而非 INFO是因为「挂载指向了错误的宿主机目录」也会落到同一状态——日志中写明了服务器实际读取的目录供你区分这两种情况。bundle_revision是对所有被引用文件计算出的哈希。如果你改了文件后它没有变化说明服务器读取的目录并非你以为的那个——或者根本没有真正重启。接口。该接口是公开的欢迎页在登录之前显示因此直接curl即可curl -s http://localhost:9621/ui/customization?localezh | jq{ customized: true, requested_locale: zh, locale: zh, fallback_used: false, direction: ltr, brand: { title: My Graph KB, description: Simple and Fast Graph Based RAG System, logo_url: /ui/customization/assets/9f2a…/brand-logo, logo_alt: 示例公司, copyright: © 2025 示例公司 版权所有 }, welcome: { format: markdown, content: ## 欢迎… }, query_empty: { format: markdown, content: … }, login: { format: markdown, content: … }, agreements: { format: markdown, content: … }, consent_documents: 《用户隐私协议》和《模型服务协议》, consent_required: true }【免费下载链接】LightRAG[EMNLP2025] LightRAG: Simple and Fast Retrieval-Augmented Generation项目地址: https://gitcode.com/GitHub_Trending/li/LightRAG创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考