提供OpenAI格式的查询接口

[hicofeng]

请问开发者，ModelCache可以直接提供标准的OpenAI格式的查询接口吗，比如原先程序是直接调用在线LLM的，直接替换接口链接和模型name，实现无缝接入到缓存当中。 因为对于一些无法编辑改造查询方式的程序来说，可以直接通过替换OpenAI格式的模型接口，就可以实现直接接入ModelCache。因为缓存期待的是快速响应嘛，所以在没有命中缓存的情况下，调用在线LLM接口查询答案，并且以流式的形式返回从LLM拿到的答案，兼容这些特征。 还有一个疑惑：如果历史上下文、prompt较长的情况下，是否会影响整体召回的准确度，有没有考虑将用户消息、prompt、历史上下文分别存储、计算向量呢。还是说我们查询ModelCache的时候应该尽量精简篇幅，只保留用户消息。希望获得解答。谢谢

[peng3307165]

这是2个非常好的问题，分别做下解答：

关于第1个问题：

• 通过OpenAI格式的查询接口无缝接入缓存的模式，可以降低用户接入成本，但这种Cache和大模型调用耦合的形式，会降低产品的灵活性。在我们内部的工作，大模型产品是一个复杂的系统，会涉及流式输出、内容安全、数据安全、商业合规等多个流程，而且这种耦合形式会增加产品侧排查问题的复杂性。通过解耦的形式，ModelCache做为中间件的形式接入，会使得企业级的大模型产品变成模块清晰的系统，也可以做灵活的功能定制，因此我们将ModelCache做为一个类redis的中间件产品进行迭代。

• 当然，你提到的方式对于实验场景以及应用侧场景是很有必要的，可以大幅降低接入成本，因此我们在开源另外一个EasyDeploy项目，帮助用户快速部署大模型应用，很快会集成ModelCache缓存服务，并且完成遵循OpenAI协议，我理解应该和你提到的场景是一致的，repo地址：https://github.com/codefuse-ai/EasyDeploy

关于第2个问题：

• 对于长上线文的情况：大部分embedding模型是基于bert模型，受512token限制，会对超长上下文会自动截断，在ModelCache中，我们增加sliding window， 并二次pooling的能力，为防止降低语义，又做了长、短文本不同threshold的区分。

• prompt较长的情况下：你的想法是对的，是可以和用户的query做分离存储和计算的，因为开源产品中涉及多种向量存储，不太容易做到统一方案，你可以根据自己的实际情况进行定制开发，如果你有通用方案，欢迎联系我们。

• 关于多轮对话的情况：我们根据线上的实际数据做过分析，当会话超过2-3轮时（会带有anwser），相似的语义对话会急剧下降，所以建议将访问Cache的对话轮数控制在3轮以内。