fix(rag): 全文索引在容器里根本没持久化 —— 补 /data 卷 + BLEVE_PATH
排查「fulltext 路 0 命中」时发现的真问题,比原以为的分词器问题严重得多。
现状:mcp-go 容器**没有任何 volume**,也没设 BLEVE_PATH,于是索引落到相对
CWD 的 .data/bleve。而运行阶段没有 WORKDIR(CWD=/)、进程又是非 root(uid 10001),
两种结局都糟:
- 在 / 下建不了目录 → openBleve 静默退回内存索引,重启即清零;
- 就算建得了,也只是写进容器可写层,每次发版重建容器一样清零。
更糟的是它不报错:混合检索少一路只表现为召回变差,看不出故障。
改动:
- Dockerfile:建 /data 并 chown 给 app,WORKDIR 设为 /data;
- 两份 compose:BLEVE_PATH=/data/bleve + 挂持久卷(132 那份此前连
顶层 volumes 段都没有);
- .env.example:写清默认相对路径相对的是**启动目录**——本地从仓库根起
和从 sundynix-mcp-go/ 起会写出两份互不相干的索引,排查时极易被坑。
附带澄清:中文分词本身没问题。直接开落盘索引验证过,mapping 里 text 字段
确实是 cjk,实测「星间链」命中 4 条、「海关监管」命中 104 条,BM25 打分正常。
a4852c3 那次修复是有效的,之前怀疑分词器的判断作废。
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
@@ -71,9 +71,14 @@ services:
|
||||
MINIO_BUCKET: sundynix-docs
|
||||
SUNDYNIX_SECRET_KEY: *secret-key
|
||||
OTEL_EXPORTER_OTLP_ENDPOINT: http://jaeger:4318
|
||||
# 全文(bleve)索引落盘位置。不设则相对 CWD,写进容器可写层 → 每次重建容器就清零,
|
||||
# 而混合检索只是静默少一路召回、不报错,很难发现。必须配合下面的持久卷。
|
||||
BLEVE_PATH: /data/bleve
|
||||
depends_on:
|
||||
nats: { condition: service_started }
|
||||
milvus: { condition: service_healthy } # mcp-go 须在 Milvus 后起,否则工具 no responders
|
||||
volumes:
|
||||
- mcp_go_data:/data
|
||||
|
||||
mcp-py:
|
||||
build: { context: sundynix-mcp-py, dockerfile: Dockerfile }
|
||||
@@ -181,3 +186,4 @@ volumes:
|
||||
minio_data:
|
||||
milvus_data:
|
||||
neo4j_data:
|
||||
mcp_go_data:
|
||||
|
||||
Reference in New Issue
Block a user