推荐语

深入解析Kimi知识库接口文档，搭建本地私有知识库的最佳选择。

核心内容：
1. 调研多家服务商，Kimi文档的完善度对比
2. Kimi支持的接口功能及兼容性
3. 实际代码示例，快速上手操作

杨芳贤

53A创始人/腾讯云(TVP)最具价值专家

from pathlib import Pathfrom openai import OpenAIclient = OpenAI(    api_key = "$MOONSHOT_API_KEY",    base_url = "https://api.moonshot.cn/v1",)# xlnet.pdf 是一个示例文件, 我们支持 pdf, doc 以及图片等格式, 对于图片和 pdf 文件，提供 ocr 相关能力file_object = client.files.create(file=Path("xlnet.pdf"), purpose="file-extract")# 获取结果# file_content = client.files.retrieve_content(file_id=file_object.id)# 注意，之前 retrieve_content api 在最新版本标记了 warning, 可以用下面这行代替# 如果是旧版本，可以用 retrieve_contentfile_content = client.files.content(file_id=file_object.id).text# 把它放进请求中messages = [    {        "role": "system",        "content": "你是 Kimi，由 Moonshot AI 提供的人工智能助手，你更擅长中文和英文的对话。你会为用户提供安全，有帮助，准确的回答。同时，你会拒绝一切涉及恐怖主义，种族歧视，黄色暴力等问题的回答。Moonshot AI 为专有名词，不可翻译成其他语言。",    },    {        "role": "system",        "content": file_content,    },    {"role": "user", "content": "请简单介绍 xlnet.pdf 讲了啥"},]# 然后调用 chat-completion, 获取 Kimi 的回答completion = client.chat.completions.create(  model="moonshot-v1-32k",  messages=messages,  temperature=0.3,)print(completion.choices[0].message)

它支持的文档格式非常多，不仅支持文本文档，还支持图片格式。估计是最全的一家吧，连阿里云都没有这么多，后续再讲阿里云。

上面示例中是提取文本内容，要知道提取文件后的内容可能非常大，比如一本书，都几十万字到几百万字，这样来回跟大模型交互，这个成本估计真的是要命。

为了解决这个问题，Kimi也算是很贴心了，她跟我们提供了context cache，上下文缓存技术服务：

Context Caching （上下文缓存）是一种高效的数据管理技术，它允许系统预先存储那些可能会被频繁请求的大量数据或信息。这样，当您再次请求相同信息时，系统可以直接从缓存中快速提供，而无需重新计算或从原始数据源中检索，从而节省时间和资源。使用 Context Caching 时，首先需要通过 API 创建缓存，指定要存储的数据类型和内容，然后设置一个合适的过期时间以保持数据的有效性。一旦缓存创建完成，任何对该数据的请求都会首先检查缓存，如果缓存有效，则直接使用缓存（此时已缓存的内容将不再收取 Tokens 费用），否则需要重新生成并更新缓存。这种方法特别适用于需要处理大量重复请求的应用程序，可以显著提高响应速度和系统性能。

Context Caching 特别适合于用频繁请求，重复引用大量初始上下文的情况，通过重用已缓存的内容，可以显著提高效率并降低费用。因为这个功能具有强烈的业务属性，我们下面简单列举一些合适的业务场景：

• 在系统提示词 system prompt 中提供大量预设内容的问答机器人，例如 Kimi API 小助手；
• 针对固定的文档集合的频繁查询，例如对合同进行多维度的审查工作；
• 瞬时流量巨大的爆款 AI 应用，例如哄哄模拟器，LLM Riddles；

这个功能好是好，在我窃喜之余，翻看了她的计费方式，看完让我大吃一惊：

文档中举了一个计费的案例：比如10K文档内容，存储了2小时的缓存，总花费6元人民币，这个例子她还没有算上大模型输入输出的token开销。下面是cache计费规则：

这个计价包含了时间维度，这个有点儿让人受不了了，通常一个数字人直播挂上12小时，这期间cache 一直在用，如果某商户上传了几百万的文档，估计一晚上的开销足以让人家破产了，这谁还敢用啊？

除了这个计费问题，她还有很多限制，比如：

1. 单个用户最多只能上传 1000 个文件，单文件不超过 100MB，同时所有已上传的文件总和不超过 10G 容量。超过了，你得自己删除。

2 每个cache 大小限制128k。

3 并发访问限制，包含了访问限速，token限速等，跟累积充值金额有关，虽然充值额度不大，但是限制很恶心。

4 其他等等。。

阿里云也有一个类似的cache context功能，思路差不多，只是计费不同，它没有包括时间维度：

好了，这篇文章主要关心本地知识库的计费问题，看了几家服务商，我们大概心里有数了，知识库创建起来容易，使用起像割肉?。尤其是大量文档交互的场景，所以对价格敏感的人们，可以不用考虑大厂API了，至少长期来看，不应该这样依赖。

还有一种折衷的方案，本地知识库要建立本地索引，否则真的会让你破产。这种方案，我们后续再讲，敬请关注。