如果你也是那种角色卡越攒越多、世界观设定越写越厚的人一定体会过SillyTavern里那个矛盾的瞬间——设定写得很爽可一旦跑起来上下文窗口根本装不下几页。后来听说SillyTavern有向量存储Vector Storage功能可以把设定集切片、向量化等模型需要时按语义检索出来注入上下文听起来非常优雅。于是某个晚上我打开Vector Storage准备导入资料。然后页面卡死了。准确地说是从一个下载进度条开始卡的进度条停在87%页面假死点哪里都没反应。这篇不是标准教程而是一个踩坑记录记录我从这个卡死的傍晚开始到最后在本地部署Ollama把向量化服务跑通的全过程以及中间所有值得避开的弯路。1. 向量存储在SillyTavern里到底解决什么问题1.1 设定越写越长关键词触发的天花板SillyTavern这个前端最迷人的地方就是你可以把角色背景、世界观、说话风格全部塞进角色卡和世界书里。早期我的做法很粗暴把设定直接写进角色描述或者挂一个超长世界书条目结果对话越到后期越失忆因为上下文窗口就那么大设定占得越多模型能记住的对话越少。世界书的机制本身已经有进步它对条目做关键词触发命中相关词条才把对应内容插入上下文。但关键词触发有天然天花板我写了清晨的咖啡馆我在剧情里需要查早上喝咖啡的地方关键词对不上内容就不会被触发模型自然不知道有这个设定。这就是关键词匹配的硬伤。向量存储解决的问题就是把这个精确匹配换成语义匹配。你把设定集全文导入向量库模型按当前语境去检索最相关的内容不再依赖某个关键字是不是恰好出现在设定里。听起来像把图书馆目录变成了搜索引擎对吧我当时就冲着这点去的。1.2 Vector Storage的两个核心组件Extractor和Collection真去SillyTavern里找这个功能时你会发现它界面里的核心概念有两个。一个是Collection集合相当于一个向量数据库里面装着你导入的所有文档切片。新建集合时通常可以设置分块大小、重叠度等参数。另一个是Extractor提取器负责把文本变成向量。这个组件才是整个系统最关键的部位也是我后面所有坑的来源。你可以从多个方案里选OpenAI的接口、本地transformers.js模型、Ollama、REST等多种服务。如果你之前没接触过这块这里最容易产生第一个认知偏差以为Extractor里的模型和聊天用的模型是一回事。实际上聊天模型负责生成文本Embedding模型负责把一段文本编码成一组向量。两者完全不同后者一般很小跑起来也很快。1.3 一个生活化的理解方式向量化是把语义变成坐标说到向量化网上资料喜欢直接丢公式和余弦相似度反而把人吓跑。我后来用一个类比把它想明白了每个句子都可以被模型映射到多维空间里的一个点语义接近的句子它们对应的点在空间里距离更近。今天天气真糟糕和外面下大雨了虽然在字面上毫无重叠但语义相近向量距离就比这家店的面条好吃更近。SillyTavern干的活就是把你导入的设定集切成小块每个块变成一个向量存在集合里。用户提问时再把问题也变成一个向量去集合里找距离最近的几块文本把它们拼进上下文交给聊天模型。理解了这个原理之后你会发现自己排查问题的思路会清晰很多——后面遇到的维度不匹配、检索为空之类的问题其实都和这个基本原理有关。2. 三次卡死实录白屏转圈、87%的进度条和维度报错2.1 第一次卡死OpenAI提取器的隐形网络依赖第一次配置我跟着一个教程选了OpenAI作为Extractor填上API KeyBase URL留空或者填官方地址然后点Test。页面开始转圈。转了很久不是那种正常等待的转圈而是一种好像永远不会有结果的转圈。我等了大概十分钟期间页面完全无响应最后只能强制刷新。原因其实不复杂我所在的网络环境下这个请求基本发不出去。SillyTavern的界面又不会给你弹一个明确的请求超时提示它就那么一直挂着。当时的我还没意识到向量存储这个功能默认依赖外部API的话网络就是最大的不稳定因素。后来冷静下来想了下就算网络没问题这种方案也不适合我。每次向量化都要调用外部接口如果是用量计费每重建一次索引都是一笔费用。而且自己的角色卡和设定集等于全走了一遍外部服务这个隐私代价对我来说也不划算。所以我果断放弃了OpenAI方案转向本地方案。2.2 第二次卡死浏览器内置模型从下载就开始翻车本地方案在SillyTavern里也有一个看似顺理成章的选择内置的transformers.js方案。选中它的时候我还挺高兴想着这回终于不依赖外网了。结果点下下载模型后一个几百MB的模型权重文件开始从HuggingFace下载。进度条一开始还走得挺快到了87%左右直接停住了。我盯着那个进度条看了几分钟然后整个标签页开始无响应风扇狂转切到任务管理器一看Chrome的内存占用已经到了好几个GB。这个卡死的本质是把重量级任务都压在了浏览器主线程上。模型下载是网络问题下载完成后的模型加载和推理又极度吃内存浏览器不是为这种负载设计的。更要命的是即使下载成功向量库的数据被写在浏览器的IndexedDB里索引越建越大查询时UI一样会变得非常卡。那次我通过任务管理器强杀了标签页进程重新打开后进度条又从零开始。反复试了两次都是同一个位置附近卡住。这也让我彻底对浏览器内部跑Embedding死了心。2.3 第三次被害维度不匹配旧索引与新模型打架第三次不是卡死但比卡死更让人抓狂报错。经过前面两次折腾我换了一个思路不在浏览器里跑模型了改用外部本地的Ollama服务。结果第一次导入向量库倒是成功了但等到我用查询测试的时候界面直接弹出一段红色报错大意是向量维度不匹配。具体来说我之前用内置transformers.js方案时那个模型的输出维度是384维向量库里已经按384维建好了索引。当我切成Ollama里的模型后新模型的输出维度是768维。查询的时候用768维的向量去搜384维的库数据库直接拒了。这是那种原理上想明白了就会觉得自己很蠢的报错。Embedding模型不同输出维度就不同向量库的索引结构在创建集合时就已经固定了。你中途换模型不把旧集合删掉重建那必然报错。但如果你没看过原理第一次遇到这个报错时真的会一头雾水。2.4 三个死法背后同一个问题回头总结这三次翻车的共性我发现它们指向同一件事我把把文本变成向量这个核心操作放在了三个不可控的地方——外部网络、浏览器主线程、以及一个我没搞懂的隐式配置契约里。外部网络不稳定浏览器扛不住重负载模型和索引之间存在隐式的契约关系。如果有一个本地的、独立的、随时可控的Embedding服务这三个问题就会同时消失。这也是我最终决定认真部署一个本地Ollama服务的直接原因。3. 绕开浏览器重活Ollama 本地部署与离线模型搬运3.1 为什么是Ollama而不是继续硬刚内置方案Ollama是目前本地部署大模型最省心的工具之一它对Embedding模型的支持也很完善。我看重它的几个点模型管理简单一条命令就能拉取默认提供OpenAI兼容的API接口SillyTavern原生支持服务独立于浏览器运行不占用前端资源。另外还有一点很重要Ollama可以把Embedding模型和聊天模型都管起来一次部署两个模型一个负责向量化一个负责对话完全不用依赖任何外部服务。所以我在踩完内置模型的坑之后几乎没有犹豫就切到了Ollama。如果你根本没接触过Ollama我可以先给你一个最粗的印象它像一个本地模型管家你告诉它我要用nomic-embed-text它就把模型拉下来跑一个服务然后你通过HTTP接口调用它就这么简单。3.2 下载慢的终极解法在能拉模型的机器上拉然后把整个 .ollama 目录搬过来安装Ollama本身不难难的是下载模型。很多人在ollama pull nomic-embed-text这一步就卡住了网络环境不好时模型文件动辄几百MB下到一半断掉再重来非常痛苦。我当时试过等它自己慢慢下但速度让人绝望。最后我用了另一个思路在一台网络条件好的机器上把模型拉好然后把整个模型目录打包搬运到本机。这个方案的关键点是找到Ollama的模型目录。Windows下通常在C:\Users\你的用户名\.ollama\modelsLinux和macOS通常在~/.ollama/models。具体操作步骤大概是这样的在能正常拉取模型的机器上执行ollama pull nomic-embed-text确认ollama list能看到模型。找到.ollama目录下的models文件夹整个压缩打包。拷贝压缩包到目标机器解压到对应位置的.ollama目录下保持目录结构不变。启动Ollama执行ollama list如果能看到模型就说明导入成功。提示搬运模型文件时最好让两台机器的Ollama版本接近不同版本的模型存储结构可能有差异。我实际在Windows机器之间搬运过几次都没出问题。跨平台搬运理论可行但我没亲自试过就不云评测了。这个方案看起来笨但极其可靠。一旦模型在本地了之后所有操作都不再依赖网络。3.3 两个必设环境变量OLLAMA_HOST 与 OLLAMA_ORIGINS模型装好后还差两步配置。如果你只在本机用OLLAMA_HOST这个变量可以不设但有一个变量几乎必设那就是OLLAMA_ORIGINS。SillyTavern在浏览器里运行它向Ollama发请求属于跨域请求。Ollama默认只允许来自localhost的跨域访问但浏览器和服务的源组合一旦有细微差别就会出现CORS拦截。表现就是在SillyTavern里点测试连接转一下圈然后报错但你用curl直接测接口又是通的。我当时的遇到的正是这个情况。解决方式是在环境变量里加上OLLAMA_ORIGINS*允许所有来源访问然后重启Ollama服务。如果你有局域网内其他设备访问Ollama的需求再把OLLAMA_HOST设为0.0.0.0让服务监听所有网卡地址。这样手机、平板在同一局域网下也能调到你机器上的Embedding服务。Windows下设置环境变量后记得把托盘里的Ollama完全退出再重新打开不是最小化是右键退出否则环境变量不会生效。我在这个细节上又白耗了十分钟。3.4 用 curl 验证 embedding 接口配置完成后先不要急着打开SillyTavern。我强烈建议你先用curl验证一下接口是不是真的通了这一步能帮你把Ollama的问题和SillyTavern的问题快速切分开。在命令行执行curl http://localhost:11434/api/embeddings -d {model: nomic-embed-text, prompt: hello world}如果返回一个包含向量数组的JSON说明Ollama服务正常模型也正常。你也可以在浏览器地址栏直接访问http://localhost:11434看到Ollama is running就说明服务活着。多说一句当时我用的Ollama版本里接口路径是/api/embeddings后来新版还引入了/api/embed之类的路径。如果你发现接口路径不对先看看自己版本的API文档。但SillyTavern走的是OpenAI兼容端点这个我们下一章细说。4. 接线SillyTavern 侧的关键配置与首次全链路测试4.1 Extractor 选 OllamaBase URL 填到什么程度才不会 404Ollama服务跑起来后回到SillyTavern的Vector Storage配置。Extractor下拉框里选择Ollama。这时候最让人迷惑的就是Base URL该填什么。我试过不少版本SillyTavern不同版本对这个字段的容忍度还不一样。有的版本填http://localhost:11434就行有的版本必须填http://localhost:11434/v1不然请求路径直接404。我的经验是先填http://localhost:11434点测试如果报404或者连接失败再改成http://localhost:11434/v1试试。同时打开浏览器开发者工具切到Network面板过滤Fetch/XHR请求你能看到SillyTavern实际请求的完整地址。看到地址是/api/embed还是/v1/embeddings你自然就知道路径该不该带/v1了。提示API Key这一栏如果被SillyTavern要求非空随便填一个字符串就能过比如ollama。因为Ollama本地服务默认不校验密钥。4.2 集合维度、模型参数和最大 Token 的匹配逻辑连接通之后下一个要命的问题就是模型和集合的匹配。前面说过创建集合时索引结构会把维度固定下来。所以你先得知道自己选的Embedding模型输出多少维然后新建集合时确保参数对得上。我用过的几个常见Embedding模型参数大致是这样模型维度体积中文表现适合场景all-MiniLM-L6-v2384小很一般英文轻量场景nomic-embed-text768约300MB尚可中英文混合通用场景bge-m31024较大突出中文为主的知识库mxbai-embed-large1024较大一般英文高质量检索我当时选的是nomic-embed-text768维体积适中中英文都能兼顾。如果你主要是中文场景可以试bge-m3中文语义理解会更好但代价是模型体积和内存占用都更高。确定模型之后新建集合时还要看有没有最大向量化Token数之类的限制参数。这个参数决定了单个文本块能有多长。如果你导入的文本块很长超过模型的上下文限制超出的部分会被截断导致语义丢失。4.3 首次导入与查询测试如何在5分钟内确认全链路可用配置完之后先做一次最小化验证别一上来就导入几万字的大设定。我的建议是先用一段几百字的试文本建一个测试集合走完切片-向量化-导入全流程。操作步骤大概是新建一个Collection命名比如test_collection。把一段测试文本粘贴到导入框里点击导入。等待进度条走完可以观察Network面板你会看到SillyTavern在持续向Ollama发送Embedding请求。导入完成后切换到查询测试输入一个和测试文本语义相关的问题点击查询。如果返回了文本片段恭喜全链路已经通了。这个测试的另一个作用是让你感受一下向量化的速度。我当时导入一个2000字的文本切成几个分块基本是几秒内就完成了。有了这个基准后面再导入大设定集你就知道大概要等多久。4.4 把聊天和向量检索连起来斜杠命令与自动注入全链路通了之后还有一个问题向量库建好了聊天时怎么用它SillyTavern的向量存储扩展通常会注册一个斜杠命令我当时用的是/vector-search这样的形式。在聊天输入框里敲这个命令加你的查询文本就可以手动检索并注入上下文。比如在写剧情时想确认某个细节就可以搜一下。如果你想做得更自动化还可以结合SillyTavern的扩展机制把查询结果自动注入系统提示或世界信息里。这个配置方式因版本而异我就不写死步骤了但核心思路都是把向量检索当作一个工具模型在对话时决定是否需要调用它。5. 跑通之后的调优分块、中文效果和索引维护5.1 分块大小与重叠度太大有噪音太小会断章向量存储跑通只是第一步检索效果好不好很大程度取决于你导入文档时的分块设置。分块大小直接决定了检索的粒度。分块太大比如一次切2000字检索召回的一段文本里什么都有模型消化起来噪音很大。分块太小比如切100字又容易把关键信息拦腰截断一条设定被切成两半两头都不完整。我的经验是中文设定集场景下一个分块控制在500到800字比较合适。如果设定涉及大量专有名词或人名适当提高重叠度。重叠度是指相邻两个分块之间重复的部分比如你chunk size设700overlap设100那么每两个块之间会有100个字的重复内容这样能尽量避免关键实体恰好被切在两块的边界上。我的一份两万字的世界设定用700字符分块、100字符重叠最后生成30多个分块检索时大概能覆盖绝大部分有效信息。这个数字你可以参考但最后还是要根据自己文档的内容密度来微调。5.2 中文场景下模型怎么选nomic 还是 bge-m3如果你的内容以中文为主而且检索质量要求不低我建议你认真对比一下nomic-embed-text和bge-m3。nomic-embed-text的优势是小、快、省内存日常跑完全够用。但它的中文训练占比有限在涉及古风、方言、专业术语这些中文特色内容时语义召回偶尔会出现偏差。bge-m3明显更懂中文对中文长文本的语义理解好不少但模型体积和内存占用也上了一个台阶。我当时是因为机器的内存不算富裕最终锁定了nomic。如果你的内存有16GB以上且主要跑中文设定直接上bge-m3会更省心省得以后换模型又要重建索引。对了换模型之前千万记得先新建一个集合等验证新模型检索没问题后再删除旧的集合。别一上来就把旧集合删了万一新模型效果不如预期想回退还得重新导入所有文档。5.3 向量库的维护重建、备份与内存控制向量库跑一段时间后会有几个容易被忽略的维护点。首先是索引重建。当你修改了导入文档的内容或者换了Embedding模型旧索引不会自动更新。你需要在Collection里重新导入或者直接删掉旧集合重建。不要试图在原集合上覆盖SillyTavern的向量库对这种操作支持得并不好。其次是备份。向量库默认存储在浏览器的IndexedDB里这意味着它绑定在浏览器环境上。换台电脑、换个浏览器、或者手滑清了站点数据整个向量库就没了。建议在导入完一批重要设定后用浏览器DevTools的Application面板找到IndexedDB或者用SillyTavern自带的导出功能把向量库数据导出一份本地备份。最后是内存控制。Ollama的Embedding模型虽然小但常驻内存也要占几百MB。如果同时还在用Ollama跑聊天模型两边叠加起来内存压力不小。不用向量检索时可以执行ollama stop nomic-embed-text把Embedding模型从内存里卸下来下次调用时会自动重新加载。6. 复盘这些坑的根源与我建议的排查顺序6.1 浏览器里搞重型任务为什么是一个结构性错误回看整个踩坑过程我最开始犯的根本错误是把向量化这种计算密集和网络敏感的任务直接丢给了浏览器。SillyTavern本质上是一个前端界面它擅长的是展示、交互、组织配置而不是承载一个重型模型。浏览器主线程一旦被模型下载、权重加载、推理计算占用整个UI会直接冻结。而且浏览器对网络请求的限制更严格超时、CORS、缓存等机制都可能让事情变得不可控。把向量化服务独立出来放到Ollama这种系统级服务里等于把干活的人和展示界面分开了。界面负责好看服务负责干活各司其职。这个思路不止适用于向量存储你在SillyTavern里接其他重活时都可以参考凡是吃内存、吃CPU、吃网络的尽量往服务端放别塞给浏览器。6.2 我的排查链路curl先行浏览器F12次之最后才看UI经过这次折腾我形成了一个排查链路的习惯现在分享出来。第一步永远是curl。先确认服务活着curl http://localhost:11434看返回。再确认接口正常调一次/api/embeddings看能不能返回向量。这一步能排除掉80%的服务端问题。第二步开浏览器F12看Network面板。SillyTavern的请求到底发出去没有、返回什么状态码、是不是被CORS拦截了全部一目了然。特别是CORS问题UI上只给你一个失败提示但Network面板里能明确看到类似Access-Control-Allow-Origin的错误描述。第三步才是看SillyTavern的配置界面。如果前两步都没问题那就几乎必然是配置项的问题比如模型名写错、Base URL路径不对、集合参数不匹配。这时候再回去检查配置效率非常高。提示排查时不要反复点SillyTavern里的测试按钮那是无效操作。先用工具把底层问题看清楚再动UI每次改动后只测一次这样才不会把问题搞混。6.3 给后来人的几条少走弯路清单最后我把这次踩坑沉淀成几条清单给正准备折腾SillyTavern向量存储的朋友不要用浏览器内置方案处理大批量文档它是给轻度试用场景准备的。不要依赖外部API做向量化一是网络不稳二是隐私不值。模型选定后就不要频繁换换模型等于重建整个向量库。创建集合前先确认Embedding模型的维度选好模型再创建集合。配置本地服务时OLLAMA_ORIGINS这个环境变量一定要检查否则CORS会拦你。大文档导入前先小规模试跑一遍确认检索效果再正式导入。按照这个顺序来你大概率能在一个晚上跑通而不是像我一样从一个87%的进度条开始整整折腾两天。跑通之后的日子就舒服多了。我现在把角色卡的世界观、历史背景、人设细节都放进了向量库聊天时模型需要什么就检索什么角色卡的体积反而变小了上下文里全是有效信息。后来我还把一堆乱七八糟的知识笔记也导了进去相当于给SillyTavern配了一个私人的知识库。可以说这个坑虽然踩得深但跳出来之后的路确实宽了很多。 
长河君 · 2026/9/20 12:45:28 · 阅读 1.2k SillyTavern向量存储踩坑：用Ollama本地部署Embedding服务
如果你也是那种角色卡越攒越多、世界观设定越写越厚的人一定体会过SillyTavern里那个矛盾的瞬间——设定写得很爽可一旦跑起来上下文窗口根本装不下几页。后来听说SillyTavern有向量存储Vector Storage功能可以把设定集切片、向量化等模型需要时按语义检索出来注入上下文听起来非常优雅。于是某个晚上我打开Vector Storage准备导入资料。然后页面卡死了。准确地说是从一个下载进度条开始卡的进度条停在87%页面假死点哪里都没反应。这篇不是标准教程而是一个踩坑记录记录我从这个卡死的傍晚开始到最后在本地部署Ollama把向量化服务跑通的全过程以及中间所有值得避开的弯路。1. 向量存储在SillyTavern里到底解决什么问题1.1 设定越写越长关键词触发的天花板SillyTavern这个前端最迷人的地方就是你可以把角色背景、世界观、说话风格全部塞进角色卡和世界书里。早期我的做法很粗暴把设定直接写进角色描述或者挂一个超长世界书条目结果对话越到后期越失忆因为上下文窗口就那么大设定占得越多模型能记住的对话越少。世界书的机制本身已经有进步它对条目做关键词触发命中相关词条才把对应内容插入上下文。但关键词触发有天然天花板我写了清晨的咖啡馆我在剧情里需要查早上喝咖啡的地方关键词对不上内容就不会被触发模型自然不知道有这个设定。这就是关键词匹配的硬伤。向量存储解决的问题就是把这个精确匹配换成语义匹配。你把设定集全文导入向量库模型按当前语境去检索最相关的内容不再依赖某个关键字是不是恰好出现在设定里。听起来像把图书馆目录变成了搜索引擎对吧我当时就冲着这点去的。1.2 Vector Storage的两个核心组件Extractor和Collection真去SillyTavern里找这个功能时你会发现它界面里的核心概念有两个。一个是Collection集合相当于一个向量数据库里面装着你导入的所有文档切片。新建集合时通常可以设置分块大小、重叠度等参数。另一个是Extractor提取器负责把文本变成向量。这个组件才是整个系统最关键的部位也是我后面所有坑的来源。你可以从多个方案里选OpenAI的接口、本地transformers.js模型、Ollama、REST等多种服务。如果你之前没接触过这块这里最容易产生第一个认知偏差以为Extractor里的模型和聊天用的模型是一回事。实际上聊天模型负责生成文本Embedding模型负责把一段文本编码成一组向量。两者完全不同后者一般很小跑起来也很快。1.3 一个生活化的理解方式向量化是把语义变成坐标说到向量化网上资料喜欢直接丢公式和余弦相似度反而把人吓跑。我后来用一个类比把它想明白了每个句子都可以被模型映射到多维空间里的一个点语义接近的句子它们对应的点在空间里距离更近。今天天气真糟糕和外面下大雨了虽然在字面上毫无重叠但语义相近向量距离就比这家店的面条好吃更近。SillyTavern干的活就是把你导入的设定集切成小块每个块变成一个向量存在集合里。用户提问时再把问题也变成一个向量去集合里找距离最近的几块文本把它们拼进上下文交给聊天模型。理解了这个原理之后你会发现自己排查问题的思路会清晰很多——后面遇到的维度不匹配、检索为空之类的问题其实都和这个基本原理有关。2. 三次卡死实录白屏转圈、87%的进度条和维度报错2.1 第一次卡死OpenAI提取器的隐形网络依赖第一次配置我跟着一个教程选了OpenAI作为Extractor填上API KeyBase URL留空或者填官方地址然后点Test。页面开始转圈。转了很久不是那种正常等待的转圈而是一种好像永远不会有结果的转圈。我等了大概十分钟期间页面完全无响应最后只能强制刷新。原因其实不复杂我所在的网络环境下这个请求基本发不出去。SillyTavern的界面又不会给你弹一个明确的请求超时提示它就那么一直挂着。当时的我还没意识到向量存储这个功能默认依赖外部API的话网络就是最大的不稳定因素。后来冷静下来想了下就算网络没问题这种方案也不适合我。每次向量化都要调用外部接口如果是用量计费每重建一次索引都是一笔费用。而且自己的角色卡和设定集等于全走了一遍外部服务这个隐私代价对我来说也不划算。所以我果断放弃了OpenAI方案转向本地方案。2.2 第二次卡死浏览器内置模型从下载就开始翻车本地方案在SillyTavern里也有一个看似顺理成章的选择内置的transformers.js方案。选中它的时候我还挺高兴想着这回终于不依赖外网了。结果点下下载模型后一个几百MB的模型权重文件开始从HuggingFace下载。进度条一开始还走得挺快到了87%左右直接停住了。我盯着那个进度条看了几分钟然后整个标签页开始无响应风扇狂转切到任务管理器一看Chrome的内存占用已经到了好几个GB。这个卡死的本质是把重量级任务都压在了浏览器主线程上。模型下载是网络问题下载完成后的模型加载和推理又极度吃内存浏览器不是为这种负载设计的。更要命的是即使下载成功向量库的数据被写在浏览器的IndexedDB里索引越建越大查询时UI一样会变得非常卡。那次我通过任务管理器强杀了标签页进程重新打开后进度条又从零开始。反复试了两次都是同一个位置附近卡住。这也让我彻底对浏览器内部跑Embedding死了心。2.3 第三次被害维度不匹配旧索引与新模型打架第三次不是卡死但比卡死更让人抓狂报错。经过前面两次折腾我换了一个思路不在浏览器里跑模型了改用外部本地的Ollama服务。结果第一次导入向量库倒是成功了但等到我用查询测试的时候界面直接弹出一段红色报错大意是向量维度不匹配。具体来说我之前用内置transformers.js方案时那个模型的输出维度是384维向量库里已经按384维建好了索引。当我切成Ollama里的模型后新模型的输出维度是768维。查询的时候用768维的向量去搜384维的库数据库直接拒了。这是那种原理上想明白了就会觉得自己很蠢的报错。Embedding模型不同输出维度就不同向量库的索引结构在创建集合时就已经固定了。你中途换模型不把旧集合删掉重建那必然报错。但如果你没看过原理第一次遇到这个报错时真的会一头雾水。2.4 三个死法背后同一个问题回头总结这三次翻车的共性我发现它们指向同一件事我把把文本变成向量这个核心操作放在了三个不可控的地方——外部网络、浏览器主线程、以及一个我没搞懂的隐式配置契约里。外部网络不稳定浏览器扛不住重负载模型和索引之间存在隐式的契约关系。如果有一个本地的、独立的、随时可控的Embedding服务这三个问题就会同时消失。这也是我最终决定认真部署一个本地Ollama服务的直接原因。3. 绕开浏览器重活Ollama 本地部署与离线模型搬运3.1 为什么是Ollama而不是继续硬刚内置方案Ollama是目前本地部署大模型最省心的工具之一它对Embedding模型的支持也很完善。我看重它的几个点模型管理简单一条命令就能拉取默认提供OpenAI兼容的API接口SillyTavern原生支持服务独立于浏览器运行不占用前端资源。另外还有一点很重要Ollama可以把Embedding模型和聊天模型都管起来一次部署两个模型一个负责向量化一个负责对话完全不用依赖任何外部服务。所以我在踩完内置模型的坑之后几乎没有犹豫就切到了Ollama。如果你根本没接触过Ollama我可以先给你一个最粗的印象它像一个本地模型管家你告诉它我要用nomic-embed-text它就把模型拉下来跑一个服务然后你通过HTTP接口调用它就这么简单。3.2 下载慢的终极解法在能拉模型的机器上拉然后把整个 .ollama 目录搬过来安装Ollama本身不难难的是下载模型。很多人在ollama pull nomic-embed-text这一步就卡住了网络环境不好时模型文件动辄几百MB下到一半断掉再重来非常痛苦。我当时试过等它自己慢慢下但速度让人绝望。最后我用了另一个思路在一台网络条件好的机器上把模型拉好然后把整个模型目录打包搬运到本机。这个方案的关键点是找到Ollama的模型目录。Windows下通常在C:\Users\你的用户名\.ollama\modelsLinux和macOS通常在~/.ollama/models。具体操作步骤大概是这样的在能正常拉取模型的机器上执行ollama pull nomic-embed-text确认ollama list能看到模型。找到.ollama目录下的models文件夹整个压缩打包。拷贝压缩包到目标机器解压到对应位置的.ollama目录下保持目录结构不变。启动Ollama执行ollama list如果能看到模型就说明导入成功。提示搬运模型文件时最好让两台机器的Ollama版本接近不同版本的模型存储结构可能有差异。我实际在Windows机器之间搬运过几次都没出问题。跨平台搬运理论可行但我没亲自试过就不云评测了。这个方案看起来笨但极其可靠。一旦模型在本地了之后所有操作都不再依赖网络。3.3 两个必设环境变量OLLAMA_HOST 与 OLLAMA_ORIGINS模型装好后还差两步配置。如果你只在本机用OLLAMA_HOST这个变量可以不设但有一个变量几乎必设那就是OLLAMA_ORIGINS。SillyTavern在浏览器里运行它向Ollama发请求属于跨域请求。Ollama默认只允许来自localhost的跨域访问但浏览器和服务的源组合一旦有细微差别就会出现CORS拦截。表现就是在SillyTavern里点测试连接转一下圈然后报错但你用curl直接测接口又是通的。我当时的遇到的正是这个情况。解决方式是在环境变量里加上OLLAMA_ORIGINS*允许所有来源访问然后重启Ollama服务。如果你有局域网内其他设备访问Ollama的需求再把OLLAMA_HOST设为0.0.0.0让服务监听所有网卡地址。这样手机、平板在同一局域网下也能调到你机器上的Embedding服务。Windows下设置环境变量后记得把托盘里的Ollama完全退出再重新打开不是最小化是右键退出否则环境变量不会生效。我在这个细节上又白耗了十分钟。3.4 用 curl 验证 embedding 接口配置完成后先不要急着打开SillyTavern。我强烈建议你先用curl验证一下接口是不是真的通了这一步能帮你把Ollama的问题和SillyTavern的问题快速切分开。在命令行执行curl http://localhost:11434/api/embeddings -d {model: nomic-embed-text, prompt: hello world}如果返回一个包含向量数组的JSON说明Ollama服务正常模型也正常。你也可以在浏览器地址栏直接访问http://localhost:11434看到Ollama is running就说明服务活着。多说一句当时我用的Ollama版本里接口路径是/api/embeddings后来新版还引入了/api/embed之类的路径。如果你发现接口路径不对先看看自己版本的API文档。但SillyTavern走的是OpenAI兼容端点这个我们下一章细说。4. 接线SillyTavern 侧的关键配置与首次全链路测试4.1 Extractor 选 OllamaBase URL 填到什么程度才不会 404Ollama服务跑起来后回到SillyTavern的Vector Storage配置。Extractor下拉框里选择Ollama。这时候最让人迷惑的就是Base URL该填什么。我试过不少版本SillyTavern不同版本对这个字段的容忍度还不一样。有的版本填http://localhost:11434就行有的版本必须填http://localhost:11434/v1不然请求路径直接404。我的经验是先填http://localhost:11434点测试如果报404或者连接失败再改成http://localhost:11434/v1试试。同时打开浏览器开发者工具切到Network面板过滤Fetch/XHR请求你能看到SillyTavern实际请求的完整地址。看到地址是/api/embed还是/v1/embeddings你自然就知道路径该不该带/v1了。提示API Key这一栏如果被SillyTavern要求非空随便填一个字符串就能过比如ollama。因为Ollama本地服务默认不校验密钥。4.2 集合维度、模型参数和最大 Token 的匹配逻辑连接通之后下一个要命的问题就是模型和集合的匹配。前面说过创建集合时索引结构会把维度固定下来。所以你先得知道自己选的Embedding模型输出多少维然后新建集合时确保参数对得上。我用过的几个常见Embedding模型参数大致是这样模型维度体积中文表现适合场景all-MiniLM-L6-v2384小很一般英文轻量场景nomic-embed-text768约300MB尚可中英文混合通用场景bge-m31024较大突出中文为主的知识库mxbai-embed-large1024较大一般英文高质量检索我当时选的是nomic-embed-text768维体积适中中英文都能兼顾。如果你主要是中文场景可以试bge-m3中文语义理解会更好但代价是模型体积和内存占用都更高。确定模型之后新建集合时还要看有没有最大向量化Token数之类的限制参数。这个参数决定了单个文本块能有多长。如果你导入的文本块很长超过模型的上下文限制超出的部分会被截断导致语义丢失。4.3 首次导入与查询测试如何在5分钟内确认全链路可用配置完之后先做一次最小化验证别一上来就导入几万字的大设定。我的建议是先用一段几百字的试文本建一个测试集合走完切片-向量化-导入全流程。操作步骤大概是新建一个Collection命名比如test_collection。把一段测试文本粘贴到导入框里点击导入。等待进度条走完可以观察Network面板你会看到SillyTavern在持续向Ollama发送Embedding请求。导入完成后切换到查询测试输入一个和测试文本语义相关的问题点击查询。如果返回了文本片段恭喜全链路已经通了。这个测试的另一个作用是让你感受一下向量化的速度。我当时导入一个2000字的文本切成几个分块基本是几秒内就完成了。有了这个基准后面再导入大设定集你就知道大概要等多久。4.4 把聊天和向量检索连起来斜杠命令与自动注入全链路通了之后还有一个问题向量库建好了聊天时怎么用它SillyTavern的向量存储扩展通常会注册一个斜杠命令我当时用的是/vector-search这样的形式。在聊天输入框里敲这个命令加你的查询文本就可以手动检索并注入上下文。比如在写剧情时想确认某个细节就可以搜一下。如果你想做得更自动化还可以结合SillyTavern的扩展机制把查询结果自动注入系统提示或世界信息里。这个配置方式因版本而异我就不写死步骤了但核心思路都是把向量检索当作一个工具模型在对话时决定是否需要调用它。5. 跑通之后的调优分块、中文效果和索引维护5.1 分块大小与重叠度太大有噪音太小会断章向量存储跑通只是第一步检索效果好不好很大程度取决于你导入文档时的分块设置。分块大小直接决定了检索的粒度。分块太大比如一次切2000字检索召回的一段文本里什么都有模型消化起来噪音很大。分块太小比如切100字又容易把关键信息拦腰截断一条设定被切成两半两头都不完整。我的经验是中文设定集场景下一个分块控制在500到800字比较合适。如果设定涉及大量专有名词或人名适当提高重叠度。重叠度是指相邻两个分块之间重复的部分比如你chunk size设700overlap设100那么每两个块之间会有100个字的重复内容这样能尽量避免关键实体恰好被切在两块的边界上。我的一份两万字的世界设定用700字符分块、100字符重叠最后生成30多个分块检索时大概能覆盖绝大部分有效信息。这个数字你可以参考但最后还是要根据自己文档的内容密度来微调。5.2 中文场景下模型怎么选nomic 还是 bge-m3如果你的内容以中文为主而且检索质量要求不低我建议你认真对比一下nomic-embed-text和bge-m3。nomic-embed-text的优势是小、快、省内存日常跑完全够用。但它的中文训练占比有限在涉及古风、方言、专业术语这些中文特色内容时语义召回偶尔会出现偏差。bge-m3明显更懂中文对中文长文本的语义理解好不少但模型体积和内存占用也上了一个台阶。我当时是因为机器的内存不算富裕最终锁定了nomic。如果你的内存有16GB以上且主要跑中文设定直接上bge-m3会更省心省得以后换模型又要重建索引。对了换模型之前千万记得先新建一个集合等验证新模型检索没问题后再删除旧的集合。别一上来就把旧集合删了万一新模型效果不如预期想回退还得重新导入所有文档。5.3 向量库的维护重建、备份与内存控制向量库跑一段时间后会有几个容易被忽略的维护点。首先是索引重建。当你修改了导入文档的内容或者换了Embedding模型旧索引不会自动更新。你需要在Collection里重新导入或者直接删掉旧集合重建。不要试图在原集合上覆盖SillyTavern的向量库对这种操作支持得并不好。其次是备份。向量库默认存储在浏览器的IndexedDB里这意味着它绑定在浏览器环境上。换台电脑、换个浏览器、或者手滑清了站点数据整个向量库就没了。建议在导入完一批重要设定后用浏览器DevTools的Application面板找到IndexedDB或者用SillyTavern自带的导出功能把向量库数据导出一份本地备份。最后是内存控制。Ollama的Embedding模型虽然小但常驻内存也要占几百MB。如果同时还在用Ollama跑聊天模型两边叠加起来内存压力不小。不用向量检索时可以执行ollama stop nomic-embed-text把Embedding模型从内存里卸下来下次调用时会自动重新加载。6. 复盘这些坑的根源与我建议的排查顺序6.1 浏览器里搞重型任务为什么是一个结构性错误回看整个踩坑过程我最开始犯的根本错误是把向量化这种计算密集和网络敏感的任务直接丢给了浏览器。SillyTavern本质上是一个前端界面它擅长的是展示、交互、组织配置而不是承载一个重型模型。浏览器主线程一旦被模型下载、权重加载、推理计算占用整个UI会直接冻结。而且浏览器对网络请求的限制更严格超时、CORS、缓存等机制都可能让事情变得不可控。把向量化服务独立出来放到Ollama这种系统级服务里等于把干活的人和展示界面分开了。界面负责好看服务负责干活各司其职。这个思路不止适用于向量存储你在SillyTavern里接其他重活时都可以参考凡是吃内存、吃CPU、吃网络的尽量往服务端放别塞给浏览器。6.2 我的排查链路curl先行浏览器F12次之最后才看UI经过这次折腾我形成了一个排查链路的习惯现在分享出来。第一步永远是curl。先确认服务活着curl http://localhost:11434看返回。再确认接口正常调一次/api/embeddings看能不能返回向量。这一步能排除掉80%的服务端问题。第二步开浏览器F12看Network面板。SillyTavern的请求到底发出去没有、返回什么状态码、是不是被CORS拦截了全部一目了然。特别是CORS问题UI上只给你一个失败提示但Network面板里能明确看到类似Access-Control-Allow-Origin的错误描述。第三步才是看SillyTavern的配置界面。如果前两步都没问题那就几乎必然是配置项的问题比如模型名写错、Base URL路径不对、集合参数不匹配。这时候再回去检查配置效率非常高。提示排查时不要反复点SillyTavern里的测试按钮那是无效操作。先用工具把底层问题看清楚再动UI每次改动后只测一次这样才不会把问题搞混。6.3 给后来人的几条少走弯路清单最后我把这次踩坑沉淀成几条清单给正准备折腾SillyTavern向量存储的朋友不要用浏览器内置方案处理大批量文档它是给轻度试用场景准备的。不要依赖外部API做向量化一是网络不稳二是隐私不值。模型选定后就不要频繁换换模型等于重建整个向量库。创建集合前先确认Embedding模型的维度选好模型再创建集合。配置本地服务时OLLAMA_ORIGINS这个环境变量一定要检查否则CORS会拦你。大文档导入前先小规模试跑一遍确认检索效果再正式导入。按照这个顺序来你大概率能在一个晚上跑通而不是像我一样从一个87%的进度条开始整整折腾两天。跑通之后的日子就舒服多了。我现在把角色卡的世界观、历史背景、人设细节都放进了向量库聊天时模型需要什么就检索什么角色卡的体积反而变小了上下文里全是有效信息。后来我还把一堆乱七八糟的知识笔记也导了进去相当于给SillyTavern配了一个私人的知识库。可以说这个坑虽然踩得深但跳出来之后的路确实宽了很多。