你正在向文档上传器上传哪种类型的文件？崩溃可能是由于一些不完整的隐藏文件导致的，但同时，为什么你会一次上传3000个文件？关于发生的延迟，这只是因为你一次加载了这么多文件，而你的CPU无法跟上渲染所有3000个文件。
如果你想在不依赖于你的CPU的情况下嵌入这么多文件，我们建议你使用像OpenAI这样的云嵌入模型，因为它可以处理的不仅仅是你的本地CPU。

感谢你的回复。
我正在上传PDF文件，但不是同时上传。即使我只添加一个文件，崩溃也会发生。一旦文件夹被清空，系统又可以正常工作了。
有必要保留这些文件吗？似乎如果我删除它们，可能会得到一个质量较低的响应，但我不确定是否真的是这样。这些文件是否与检索过程有关，还是仅使用数据库中的信息？

It is necessary to keep the files in that folder because that file is a metadata file and is how the document picker knows which files are in the workspace and available. If you delete those files in the custom-documents folder manually, the documents are still embedded in your vector database so even though your workspace says there are no documents, you will still get context from that document and the RAG will still happen (this does not make the results less accurate by deleting those files).
This makes me think that you have a PDF file that may be corrupt or empty that is causing the crash. Is there a certain file that you can upload to replicate this bug consistently or does this only happen when you just upload lots of documents?

感谢您的解释。我现在更好地理解了数据库和json文件是如何一起工作的。
同时，我已经上传并处理了新文件。一开始一切都运行得很好，流畅，当我达到2600个文件时，同样的错误又开始出现了。有时候在重启后，我能够添加新文档，但一旦文件夹中包含超过2700个文件，错误就会出现。这意味着在"我的文档"中选择一个文件很慢，当我按下"将1个文件移动到工作区"时，任何事情都会在20秒后出现白屏崩溃。
所以我认为这个错误与文件夹中的单个损坏文件无关，而是与"custom-documents"文件夹中的文件大小有关。

我也看到了这个问题。大约在180k个向量左右，有一个悬崖被撞到了。我可以上传更多的文件，但是如果我尝试嵌入多一个文件，我就会得到一个白色的屏幕死亡，没有与后台处理相关的任务管理器活动。使用Desktop v.1.40

感谢您的确认。但我认为这与数据库和向量无关，因为当您从custom-documents中删除文件时，问题就消失了，这一步并没有影响到数据库。

我认为这个错误仅仅是由于Windows文件资源管理器处理大量文件的限制所导致的。这个过程似乎是单核应用程序，当响应时间过长时，任何东西似乎都会陷入超时错误。

也许问题可以通过将文件存储在子文件夹结构中来解决，并通过索引来进行新旧文件的比较？

你可能在某种程度上触及了矢量数据库的限制。
一个解决办法是能够部署不同的lancedb示例，而不是只用一个数据库示例连接所有的文档。在一定数量的矢量块之后，它会将数据库“切分”到另一个矢量中

Look at this:
https://lancedb.github.io/lancedb/ann_indexes/