vllm开发的优势
1.环境是现成的
2.已经有了当前打包流程
3.已经有一部分写好的代码
4.不影响与ragflow的流式接口
vllm劣势
1.gpu资源有限，在开发时，ragflow的请求会受影响
2.vllm编译时间较长，CPU满负荷运转，执行pip install -e . 初次要15~20分钟
3.vllm属于推理引擎，与模型的关系很近，未来如果想换vllm版本是无法更换的
open web ui 开发优势
1.open web ui开发不影响现有ragflow的请求，开发环境可以选择windows
2.vllm未来升级，只要open ai api不变，就不用处理
3.前端ui本来就要变，业务上本来就要二次开发open web ui的代码
4.一些功能可以直接对接open web ui，如：统计
5.vllm 和 open web ui的代码都是py的，迁移一定是可以的
6.据官网的文档，open web ui有 “滤波功能”，可以在数据发送到大型语言模型（LLM）（输入）之前或从LLM返回（输出）后修改数据。
Filter Function | Open WebUI
open web ui开发的劣势
1.之前的代码要迁移，不过涉及的代码也不多，目前只有敏感词过滤的逻辑
2.对open web ui不熟悉
3.open web ui作为ragflow的中转站会多一次请求，中间的流式衔接好不好搞尚未可知，但open web ui有滤波功能，或许可以参考
我的想法：选择open web ui
1.与业务贴合近
2.开发不影响推理引擎
3.开发不必非要在linux上，调试直接在windows上
4.AI辅助开发
对比方向：
1、开放模型接口是否可以转移到openWebUI; /v1/chat/completion
a、rag接入
b、第三方开放接口
2、敏感词过滤业务：在openWebUI和vllm的效率、作用、性能【敏感词至少W的量级】是否差别
3、开发工作量：未完成功能的开发难易度，已完成部分迁移的时间
a、一些功能可以直接对接open web ui，如：统计
4、补充其他
迁移到open web ui上
接口上：
rag 与 open web ui的接口对接？
如果真的要在 rag 上 请求 open web ui的接口，让open web ui 做中间跳板，那么
1.rag上的模型配置怎么改？
2.rag上和open web ui上用户信息的对接
3.rag 与 open web ui上的流式接口的数据格式也要对接
open web ui上的流：
data: {"id":"chatcmpl-92b287c8e85c61da","object":"chat.completion.chunk","created":1773292369,"model":"DeepSeek-R1-0528-Qwen3-8B","choices":[{"index":0,"delta":{"content":"有什么","reasoning_content":null},"logprobs":null,"finish_reason":null,"token_ids":null}]}
rag 则是直接对接的vllm的数据流
这里有个难点,就是需要修改原有的open web ui的代码,记录用户的对话信息,原有的sse不会记录用户的会话信息
4.bge模型怎么做?
向bge模型进行提问，open web ui -> The model does not support Chat Completions API
当前方案,包一个中间接口,做转发.
open web ui 第三方使用？
敏感词业务：
内置过滤函数，但这个过滤函数是open webui提供的一项功能，可以在
写了一个日志打印的filter，sse只看到了入模型前的数据，没有看到从模型出来的数据，这一块需要再修改。
前端：
用的不是vue，是svelte
保持原有的vllm，将用户与统计信息传递给open web ui
接口上：
rag 与 open web ui 在会话接口上
对接用户信息
对接会话信息
研究统计信息
第三方开放接口？
敏感词迁移上：
当前已经有 “数据入模型前的过滤代码”,需要调试和测试
1.服务启动时敏感词数据结构的构建
2.敏感词数据库的增删改查与接口
模型出来的数据尚未处理.
open web ui：
接口：
前台向后台请求的接口是 api/chat/completions
后台返回有两种情况：
第一种：异步返回，返回给前端json串，json串中带有taskid，然后走websocket
地址是：ws://localhost:8080/ws/socket.io/?EIO=4&transport=websocket
第二种：同步返回，返回的流协议是sse
接口中区分以上两种的类型就是不传递 session_id、chat_id、message_id三个中的任意一个
影响：
1.同步返回的sse，不会统计模型的用量、用户的动态，不会记录用户与模型的问答
新会话的创建会先调用 http://localhost:8080/api/v1/chats/new 获取chat_id 和 message_id
当传递chat_id 与 message_id，平台只记录对话数量，但没有记录用户对话与tokens数值，用户的对话记录和websocket绑定。
注意点：
1.token统计功能，需要在模型设置界面，将“用量”打钩
sse的调用流程：
接口
@app.post("/api/chat/completions")
@app.post("/api/v1/chat/completions")
async def chat_completion
return await process_chat(request, form_data, user, metadata, model)
async def process_chat(request, form_data, user, metadata, model)
请求前的参数配置：
form_data, metadata, events = await process_chat_payload(
request, form_data, user, metadata, model
)
处理聊天请求的主要函数，它会根据请求的参数和状态来调用不同的聊天生成函数：
response = await chat_completion_handler(request, form_data, user)
创建处理聊天响应所需的所有上下文信息：
ctx = build_chat_response_context(
request, form_data, user, model, metadata, tasks, events
)
处理模型返回数据：
return await process_chat_response(response, ctx)