pdf导入知识库时每次都会闪退

[laokuke]

What happened / 发生了什么
在管理知识库中添加文档，索引时会直接闪退。再次打开后，发现已经添加进去，但勾选文档启用知识库后，问模型问题，模型不用知识库回答。

Environment / 环境

• Chaty version / 版本:v2.1.7
• OS / 系统 (Windows 11)
• Model / 模型 (name + quantization / 名称与量化):
  Qwen3.5-9B-Q4_K_M，gemma-4-E4B-it-Q4_K_M
  Error log / 错误日志 (please attach! / 请务必附上!)

闪退没有记录错误日志，只有8月28日的日志：
[2026-08-28 15:23:39] chaty v2.1.3 windows [info]
log created — no errors recorded yet

Screenshots / video / 截图或录屏 (optional / 可选)

[Fangyuan025]

感谢反馈，这条报告很有用 —— 尤其是「闪退没有记录错误日志」，那本身就是个缺陷，已经修了。

已经修好的部分

1. 闪退不再什么都不留。 这类死法（原生库里分配失败、显卡驱动 abort、栈溢出）不会触发任何可捕获的错误，Windows 上也没有系统崩溃报告可扫，所以日志确实是空的 —— 不是你没找到，是根本没写。现在索引开始前会先把「正在做什么」落盘，正常结束就删掉；下次启动时如果它还在，说明上一次死在这儿，日志里会出现一条，带文件名、大小和确切阶段，例如：

[... ] chaty v2.1.8 windows [died-during]
上一次运行在这一步中途退出(未留下崩溃可捕获的错误)……
kb-index: book.pdf (pdf, 12.4 MB): embedding chunk 240/1500

2.「已经添加进去，但模型不用知识库回答」是我们的 bug。 文档记录是在一个 chunk 都还没嵌入之前就带着完整数量写进库的，所以中途一死，就留下一个「声称有 1500 个片段、实际只有 4 个」的文档 —— 列表里看着正常，能勾选，但检索不到任何东西。现在改成：先记为「索引中」，全部片段落库后才写入真实数量；失败会把这条记录撤掉；已经存在于你库里的这种残缺文档，会在下次打开时自动清掉（你需要重新导入一次）。

还需要你提供的信息

闪退的根本原因还不知道，上面第 1 条是为了下次能知道。在下个版本发布前，这几个问题能帮我们缩小范围：

1. PDF 多大？多少页？（几 MB / 几百 KB，页数大概多少）
2. 是不是扫描件？ 也就是：用别的阅读器打开后，正文文字能不能选中复制？
   • 能选中 = 有文字层
   • 不能选中（整页是图）= 扫描件。目前 Chaty 不对扫描 PDF 做 OCR，这种文件本应报错「多半是扫描件」而不是闪退 —— 如果你的是扫描件而且闪退了，那是另一条线索。
   • （单独的图片文件 png/jpg 是走 OCR 的，PDF 不走。）
3. PDF 里有没有图片/图表？大概几张？ 这一条比较关键：PDF 导入时，Chaty 会把里面最多 6 张内嵌图片交给视觉模型去描述，好让图表也能被检索到。这一步是在你已经加载的对话模型之外额外占显存/内存的，是目前最可疑的闪退嫌疑点。
4. 闪退发生在哪一步？ 进度条当时显示的是「提取中 / extract」还是「嵌入中 / embed」，大概百分之几？
5. 当时加载着哪个模型？ 你提到 Qwen3.5-9B-Q4_K_M 和 gemma-4-E4B —— 闪退时是哪一个，还是两个都试过都闪？
6. 机器内存/显存多大？
7. 顺带一试：**换一个很小的纯文字 PDF（比如 1-2 页、没有任何图）**导入，会不会也闪退？这一条最能分开「是这个文件的问题」还是「是 PDF 导入本身的问题」。

如果方便，也可以试试把同一份内容存成 .txt 或 .md 再导入 —— 如果那样不闪退，就说明问题出在 PDF 解析/内嵌图片这条路上，而不是嵌入模型上。

---

English summary: two fixes landed — (1) a crash during indexing now leaves a
log entry naming the file, its size and the phase it died in (Windows has no OS
crash report to sweep, which is why your log was empty), and (2) the
"added but the model ignores it" half was our bug: the document row was written
with its full chunk count before any chunk was embedded, so an interrupted
index left a document that looked ready and contained almost nothing. Existing
ones are cleared automatically on the next start; please re-import.

Still unknown: what actually causes the crash. Could you tell us the PDF's size
and page count, whether it is a scanned document (text selectable elsewhere or
not — Chaty does not OCR scanned PDFs), whether it contains images/charts
and roughly how many (PDF import sends up to 6 embedded images to the vision
model, which is the most memory-hungry step), which phase the progress bar was
in, which model was loaded, and your RAM/VRAM. A tiny text-only PDF as a control
would help a lot.

[Fangyuan025]

安装包已经更新，版本号仍然是 v2.1.7，但里面的东西变了 —— 请从 release 页面重新下载一次：

https://github.com/Fangyuan025/Chaty/releases/tag/v2.1.7

（Windows 安装包 sha256 a89328ae4026d959…，2026-09-10 重新构建。若你手上那个装出来仍是旧行为，说明下的是旧包。）

你的报告里，这些已经修好

1. 闪退不再什么都不留。 这类死法不会触发可捕获的错误，Windows 上也没有系统崩溃报告可扫，所以日志确实是空的。现在索引开始前会先把「正在做什么」落盘，正常结束就删；下次启动如果它还在，日志里会出现一条带文件名、大小和确切阶段的记录：

[... ] chaty v2.1.7 windows [died-during]
上一次运行在这一步中途退出(未留下崩溃可捕获的错误)……
kb-index: book.pdf (pdf, 12.4 MB): embedding chunk 240/1500

如果还会闪退，麻烦重启一次应用后把这条日志贴上来 —— 有了它才能定位根本原因。

2.「已经添加进去，但模型不用知识库回答」是我们的 bug。 文档记录在一个片段都还没嵌入之前就带着完整数量写进库了，所以中途一死就留下「声称 1500 个片段、实际只有 4 个」的文档：列表里看着正常、能勾选、但检索不到任何东西。现在改成全部片段落库后才写入真实数量，失败会撤回，你库里已有的这种残缺文档会在下次打开时自动清掉 —— 那几个文档需要重新导入一次。

3. 扫描件不再直接报错。 导入 PDF 时视觉模型本来就会描述里面的图片，但之前提取文字失败会把整轮连同这些描述一起扔掉。对没有文字层的扫描件来说，那些描述就是这份文档的全部内容 —— 现在会用它们来索引。

4. 新增开关：设置 → 对话 →「识别文档内嵌图片」（在「知识库引用条数」下面）。这一步会对文档里最多 6 张图各跑一次视觉模型，是叠加在你已加载的对话模型之上的额外内存开销，也是目前最可疑的闪退嫌疑点。如果重新下载后仍然闪退，请先关掉这个开关再试一次 —— 无论结果如何都是很有价值的线索。

仍然需要你的信息

闪退的根本原因还没定位（上面第 1 条是为了下次能定位）。之前问的几个问题如果方便，还是很有帮助：PDF 多大/多少页、是不是扫描件、里面有没有图、大概几张、闪退在「提取中」还是「嵌入中」阶段、当时加载的是哪个模型、机器内存多大。另外拿一个很小的纯文字无图 PDF 做对照最能分开「是这个文件的问题」还是「是 PDF 导入本身的问题」。

---

English: the installers have been rebuilt — same version number, new
binaries, so please download v2.1.7 again. Fixed from your report: a crash
during indexing now leaves a log entry naming the file and the phase (Windows
has no OS crash report to sweep, which is why your log was empty — please
attach that entry if it happens again); the "added but ignored" half was our
bug (the record claimed every chunk before any was stored — existing broken
documents are cleared automatically, please re-import them); a scanned PDF is
now indexed from the vision model's descriptions of its pages instead of being
refused. There is also a new switch, Settings → Chat → "Describe images inside
documents" — it is the most memory-hungry part of an import, so if it still
crashes, try turning that off first. The root cause of the crash is still
unknown; the details asked for earlier would still help.

[laokuke]

刚才我下载了新的版本，安装后导入pdf，仍然闪退。之后我试了400K的pdf，能成功导入，没有更多pdf可以试了。

闪退的PDF为10 MB大小，共348页。不是扫描件，能直接选中复制文字。
PDF 里有图，有几十张。
闪退发生在索引时，进度为0的时候就闪退了。
Qwen3.5-9B-Q4_K_M 和 gemma-4-E4B都会闪退。
机器内存16GB/显存8GB

以下是错误日志：
[2026-09-10 11:49:49] chaty v2.1.7 windows [died-during]
上一次运行在这一步中途退出(未留下崩溃可捕获的错误),提 issue 请附上本条 (the previous run vanished during this step — no catchable error was raised):
kb-index: 许嵩博客集 185篇 (许嵩) (Z-Library).pdf: embedding chunk 8/377

[2026-09-10 11:51:43] chaty v2.1.7 windows [kb-repair]
移除了 1 个索引未完成的文档(需要重新导入) (removed 1 document(s) whose indexing never finished — re-import them)

[Fangyuan025]

找到根因了,v2.1.8 已发布,请下载:https://github.com/Fangyuan025/Chaty/releases/tag/v2.1.8

（Windows 安装包 sha256 70dc43202a5c6278bd8b2eb59874f40314447ea369ac78e4036159577af87882）

非常感谢你把日志贴上来 —— 那一条就是破案的关键:

kb-index: 许嵩博客集 185篇.pdf: embedding chunk 8/377

8/377 是第一批,而且那条记录是在这批开始嵌入之前写的 —— 说明提取、切块都成功了,死在第一次调用嵌入模型的那一刻。

真正的原因

知识库用的嵌入模型(bge-m3)是编码器,它读一个片段必须一次读完,llama.cpp 没法把它拆开。那一次能读的上限是 512 个 token,而我们切片段时按 1020 个 token 截断。

• 英文 800 字大约 200 token,永远碰不到这条线
• 中文 800 字大约 650 token —— 用你这本书实测:377 个片段里有 283 个超过 512(中位数 652,最长 882),第一批里最长的就有 606

超过这条线时,llama.cpp 不会返回错误,而是直接终止整个进程 —— 所以窗口消失、日志里什么都没有。你那个 400K 的 PDF 能导进去,是因为它的片段没有超线。

这跟用哪个模型(Qwen3.5-9B 还是 gemma)、内存显存多大都没关系,而且在 Mac 上用 CPU 也一样会崩 —— 我用你这本书在自己机器上复现出了一模一样的崩溃,修复后整本 377 个片段全部导入成功,并能正确回答书里的问题。

我之前的两次回复里,一次怀疑是图片描述、一次说是嵌入模型要显存过多 —— 都不是这个崩溃的原因,抱歉让你多试了。显存那一条倒确实是另一个真问题,也一起修了(8GB 显存上本来就驻留着对话模型时,嵌入模型不会再一口气要光所有显存)。

这一版还修了什么

• 嵌入模型一次能读的上限改成和截断长度一致,并且按实际拿到的上限截断 —— 这类崩溃不会再出现
• 嵌入模型在显卡上按空闲显存分配,和对话模型用同一套规则
• Mac 上的知识库索引也改用 GPU,快约 4.5 倍

麻烦你

装好 v2.1.8 后,用同一本书再导入一次。之前导到一半的残缺记录会被自动清掉(日志里会看到一条 kb-repair),重新导入即可。之前让你关掉的「识别文档内嵌图片」可以重新打开。

如果还有任何问题,重启一次应用后把错误日志贴上来就行。

---

English: found it — v2.1.8 is out. Your log line (embedding chunk 8/377)
pinpointed the first batch. The embedding model is an encoder and must read a
piece in one pass; that pass held 512 tokens while pieces were cut at 1020.
English stays near 200 tokens a piece, but 800 characters of Chinese runs near
650 — 283 of your book's 377 pieces were over the line — and past it llama.cpp
aborts the process instead of returning an error. It had nothing to do with the
model or your GPU, and it reproduced on a Mac on the CPU; after the fix the
whole book (all 377 pieces) imports and answers questions correctly. My earlier
guesses (the image descriptions, the embedder's VRAM) were not the cause of
this crash — sorry for the extra round-trips; the VRAM issue was real and is
fixed too. Please import the same book again on v2.1.8; the half-imported record
is cleaned up automatically, and you can switch "Describe images inside
documents" back on.

[laokuke]

现在没有闪退了