1. 百人共学场景下的架构选型思路1.1 为什么不是直接买个SaaS账号了事一百个人同时在线学AI这个规模说大不大说小也绝对不小。我一开始也想过直接用现成的云端服务开一百个账号每人发一个省事。但实际跑了两天就发现几个绕不过去的问题第一成本是线性增长的一百个人就是一百份订阅费而且很多学员只是偶尔上来问两句资源浪费严重第二数据不在自己手里学员的提问记录、知识库内容、模型调用日志全都散落在别人的服务器上后期想做学情分析或者优化知识库根本拿不到原始数据第三网络延迟和稳定性不可控高峰期大家一起用的时候响应速度肉眼可见地往下掉。所以最终决定自己搭一套。核心诉求很明确私有化部署、支持多人并发、能挂知识库、前端体验不能太差、后期可扩展。这四个条件一摆出来选型范围其实就收窄了很多。1.2 最终敲定的技术栈组合经过几轮对比和压测最后落地的方案是Ollama做本地模型推理Open WebUI做前端交互层Svelte负责定制化页面的开发RAG知识库做垂直领域的内容增强。这套组合不是拍脑袋定的每个组件都有明确的选型理由。Ollama的优势在于模型管理足够简单一条命令就能拉取和运行模型而且对硬件的要求相对友好。我们用的是两台机器做推理节点一台配了双卡另一台单卡通过Ollama的API对外提供服务。Open WebUI则是目前开源社区里对Ollama支持最完善的前端之一自带用户管理、对话历史、模型切换、知识库上传这些功能省去了大量从零开发的工作。Svelte用在我们需要定制的一些页面比如学习进度看板、共学任务面板这些Open WebUI原生不支持但通过Svelte可以轻量地嵌进去。RAG这块是重点。一百个人学AI问题五花八门但很多基础概念是重复的。如果没有知识库模型每次都要重新“回忆”不仅慢而且答案质量不稳定。挂上RAG之后常见问题直接命中知识库模型只需要做润色和补充响应速度和准确率都有明显提升。提示选型时不要追求“最新最热”要看社区活跃度和文档完整度。Ollama和Open WebUI的GitHub issue响应速度都很快遇到问题基本能搜到解决方案这对后期维护至关重要。1.3 架构分层与数据流向整套架构我分成了四层接入层、应用层、推理层、数据层。接入层就是Open WebUI的Web界面学员通过浏览器访问应用层跑的是Svelte定制的几个页面和Open WebUI的API网关推理层是Ollama集群负责实际跑模型数据层包括向量数据库、对话历史库和知识库文件存储。数据流向是这样的学员在Open WebUI里提问请求先到应用层应用层判断是否需要走RAG。如果需要就去向量数据库里检索相关片段把检索结果和原始问题拼成新的prompt再发给Ollama。Ollama返回结果后应用层把答案写回对话历史同时返回给前端展示。整个过程对学员是透明的他们只看到一个输入框和一个回答。这个分层的好处是每一层都可以独立扩展。比如后期学员增加到两百人只需要在推理层加机器其他层不用动。知识库内容多了也只需要扩容向量数据库不影响前端体验。2. 核心组件部署与参数调优实操2.1 Ollama的安装与模型管理Ollama的安装本身不复杂但有几个细节容易踩坑。官方提供了一键安装脚本但在内网环境下直接跑脚本可能会卡在下载模型那一步。我的做法是先在能联网的机器上把模型拉下来然后整个目录打包拷贝到内网机器上。模型选择上我们试过好几个。最开始用的是7B级别的模型跑起来确实快但回答质量在涉及代码和逻辑推理的问题上明显不够用。后来换到14B级别质量上来了但单卡推理速度下降明显。最终定下来的是主力模型用14B级别做复杂问答轻量模型用7B级别做简单检索和分类。这样根据问题类型动态路由既保证了质量又控制了响应时间。Ollama的默认并发数比较保守一百人同时用肯定不够。需要调整两个参数OLLAMA_NUM_PARALLEL和OLLAMA_MAX_LOADED_MODELS。前者控制同时处理的请求数后者控制内存里同时加载的模型数量。我们的配置是并行数设为8最大加载模型数设为2这样在双卡机器上能比较充分地利用显存。# Ollama服务启动参数示例 OLLAMA_NUM_PARALLEL8 OLLAMA_MAX_LOADED_MODELS2 OLLAMA_HOST0.0.0.0注意并行数不是越大越好。设得过高会导致显存碎片化反而降低整体吞吐。建议从4开始逐步往上压测找到适合自己硬件的平衡点。2.2 Open WebUI的部署与用户管理Open WebUI我们用Docker部署这样升级和迁移都方便。Docker Compose文件里主要挂载三个卷数据卷、模型卷和知识库卷。数据卷存对话历史和用户信息模型卷挂载Ollama的模型目录知识库卷存上传的文档。用户管理这块Open WebUI原生支持管理员和普通用户两种角色。一百个学员全部设为普通用户只开放对话和知识库查询权限不让他们碰模型设置和系统配置。管理员账号只留两个一个是我自己用一个给助教做日常维护。批量创建用户是个麻烦事。Open WebUI的Web界面只能一个一个加一百个人手动加太痛苦。后来发现它支持通过API批量导入写个简单的Python脚本就能搞定。import requests url http://your-openwebui-address/api/v1/auths/add headers {Authorization: Bearer YOUR_ADMIN_TOKEN} users [ {name: 学员001, email: student001example.com, password: 初始密码}, {name: 学员002, email: student002example.com, password: 初始密码}, # ... 更多用户 ] for user in users: response requests.post(url, jsonuser, headersheaders) print(response.status_code, response.text)这个脚本跑一遍一百个账号几分钟就建好了。初始密码统一设置然后让学员第一次登录后自己改。2.3 Svelte定制页面的嵌入方式Svelte在我们这套架构里扮演的是“补丁”角色。Open WebUI原生没有学习进度追踪和共学任务分配功能这两个页面是用Svelte写的。嵌入方式有两种一种是作为独立页面通过Nginx反向代理挂到同一个域名下的子路径另一种是作为iframe嵌到Open WebUI的侧边栏里。我们选了第一种因为独立页面在移动端的体验更好而且不受Open WebUI版本升级的影响。Svelte的构建产物是纯静态文件扔到Nginx的html目录下就能跑非常轻量。共学任务面板的数据来源是Open WebUI的API。Svelte页面通过fetch调用Open WebUI的用户对话统计接口拿到每个学员的提问次数、活跃天数、知识库命中率这些数据然后在前端做可视化展示。这样助教一眼就能看出哪些学员掉队了及时跟进。3. RAG知识库的构建与检索优化3.1 知识库内容的分层设计RAG的效果好不好七分靠知识库内容三分靠检索策略。我们一开始把所有的文档一股脑全塞进去结果检索出来的片段经常驴唇不对马嘴。后来做了分层设计把知识库分成三个层次基础概念层、操作指南层、案例实战层。基础概念层放的是AI领域的术语解释、原理说明这部分内容相对稳定更新频率低。操作指南层放的是工具使用步骤、配置方法这部分跟着工具版本走需要定期更新。案例实战层放的是学员常见问题和标准答案这部分是动态增长的每次共学活动结束后都会补充一批。分层的好处是检索时可以指定层级。比如学员问“什么是RAG”就只在基础概念层检索问“Ollama怎么装”就在操作指南层检索。这样命中率明显提高也避免了不同层级内容互相干扰。3.2 文档切片与向量化参数文档切片是RAG里最容易被忽视但影响最大的环节。切片太大检索出来的内容冗余模型处理慢切片太小上下文丢失答案不完整。我们试过几种切片策略最终定下来的是按语义段落切片每片控制在300到500字之间重叠部分留50字。向量化用的是Open WebUI内置的嵌入模型没有额外部署。嵌入维度是768这个维度在效果和存储成本之间比较平衡。向量数据库用的是Chroma轻量、易部署跟Open WebUI集成也方便。# Chroma配置示例 chroma: persist_directory: /data/chroma collection_name: ai_learning_kb embedding_model: default chunk_size: 400 chunk_overlap: 50提示切片大小没有绝对标准跟文档类型有关。技术文档可以小一点叙事性内容可以大一点。建议先拿一批典型问题做测试看检索出来的片段是否完整回答了问题再反过来调整切片参数。3.3 检索策略与命中率提升检索策略上我们用的是混合检索向量相似度检索加关键词检索两个结果做加权融合。纯向量检索有时候会漏掉一些关键词匹配但语义相似度不高的内容加上关键词检索能补上这个短板。命中率的评估我们做了一个简单的埋点每次RAG检索后记录检索到的片段和最终答案的相关性。助教每周抽查一批标记哪些是“命中”哪些是“未命中”。跑了一个月下来命中率从最初的百分之六十多提升到了百分之八十五左右。提升主要来自三个方面的优化一是知识库内容的补充把学员问得多但知识库里没有的内容加进去二是切片参数的调整把一些过长的片段拆细三是检索权重的调整把关键词检索的权重从0.3提到了0.4。4. 百人并发下的性能调优与问题排查4.1 并发瓶颈的定位方法一百个人同时用瓶颈可能出现在任何一个环节。我的排查思路是从外到内逐层压测先用压测工具模拟一百个并发请求打到Open WebUI看响应时间如果前端就慢了说明是Open WebUI的问题如果前端没问题但模型响应慢那就是Ollama的瓶颈如果模型响应也正常但答案质量下降那可能是RAG检索拖了后腿。实际跑下来最先扛不住的是Ollama的并发处理。默认配置下同时来十几个请求就开始排队了。调整并行数之后好转但显存占用也上去了。后来加了一台推理节点用Nginx做负载均衡把请求分散到两台机器上才算彻底解决。4.2 常见问题速查表问题现象可能原因排查方法解决方案学员反馈回答很慢Ollama并发数不够查看Ollama日志中的请求排队情况调高OLLAMA_NUM_PARALLEL或增加推理节点回答内容不相关RAG检索命中率低检查检索到的片段和问题的匹配度调整切片参数补充知识库内容部分学员无法登录用户账号未正确创建检查Open WebUI用户列表用API脚本重新批量导入模型加载失败显存不足查看GPU显存占用减少同时加载的模型数或换更小的模型知识库上传后检索不到向量化未完成检查Chroma中的向量数量重新触发向量化或检查文件格式4.3 实操心得与避坑经验第一个坑是模型下载。内网环境下Ollama拉取模型经常超时。后来我们建了一个内部的文件服务器把常用模型放在上面Ollama通过本地路径加载速度快了很多。第二个坑是对话历史膨胀。一百个人用了一个月对话历史表涨到了几百万条查询明显变慢。后来加了一个定时任务每天凌晨把超过三十天的历史归档到冷存储主表只保留近期数据查询速度就回来了。第三个坑是知识库版本混乱。同一个文档改了又改旧版本没删干净检索的时候新旧内容一起出来答案自相矛盾。后来给知识库加了版本标记每次更新先下线旧版本再上线新版本避免了这个问题。5. 架构的扩展性与后续演进方向5.1 从百人到千人的扩展路径这套架构目前支撑一百人没问题但如果要扩展到一千人需要做几个调整。推理层肯定要加机器单靠两台不够。Open WebUI可以做成无状态的多实例前面挂负载均衡。向量数据库也要考虑分片单机Chroma在数据量大了之后检索会变慢。还有一个容易被忽视的点是用户认证。一百人的时候Open WebUI自带的用户管理够用。上千人的时候最好对接统一的身份认证系统比如LDAP或者OAuth这样账号管理不用重复造轮子。5.2 知识库的自动化更新流水线目前知识库更新还是半自动的助教手动整理文档然后上传。后续想做成全自动的学员在对话中标记“这个答案有帮助”或者“这个答案不对”系统自动收集这些反馈定期生成知识库更新建议助教审核后一键入库。这个流水线可以用Dify或者类似的工作流工具来搭把反馈收集、内容生成、人工审核、向量化入库这几个环节串起来。这样知识库就能跟着学员的使用不断进化越用越准。5.3 多模型路由与成本控制现在模型选择是手动切换的学员自己选。后续想做成自动路由简单问题走小模型复杂问题走大模型代码相关的问题走专门微调过的模型。这样既能保证回答质量又能控制推理成本。路由的判断逻辑可以基于问题的长度、关键词、历史对话的复杂度来综合打分。比如问题里出现了“代码”“报错”“原理”这些词就路由到大模型只是简单问候或者查定义小模型就够了。这套逻辑用Svelte写个中间层就能实现不需要改动Ollama本身。提示多模型路由的阈值需要根据实际使用数据不断调整。建议先跑一段时间收集数据看看哪些问题用小模型回答也够好再逐步放宽小模型的适用范围。这套架构跑到现在差不多半年了中间经历过几次共学活动的高峰期整体稳定性还可以。最大的体会是不要追求一步到位先跑起来再优化。一开始不用把每个参数都调到最优先把核心链路打通让学员能用起来然后在实际使用中发现问题、解决问题。很多坑只有真正跑起来才会遇到光靠前期设计是想不到的。