做应用最纠结的就是选型,我把三种路线的取舍理一下。
闭源 API:能力最强、上手最快、最贵、数据要出域。开源 API(第三方托管):能力次之、便宜、灵活。完全自部署:最便宜(量大时)、数据完全自控、运维和硬件成本高、能力打折。
我的经验是:早期用闭源快速验证,规模上来后核心链路切自部署降本,长尾用开源 API 兜底。大家怎么选的?
做应用最纠结的就是选型,我把三种路线的取舍理一下。
闭源 API:能力最强、上手最快、最贵、数据要出域。开源 API(第三方托管):能力次之、便宜、灵活。完全自部署:最便宜(量大时)、数据完全自控、运维和硬件成本高、能力打折。
我的经验是:早期用闭源快速验证,规模上来后核心链路切自部署降本,长尾用开源 API 兜底。大家怎么选的?
暂时没有回复。
Related
讨论
这里说的"家教"是给 Agent 选底层模型。我用过几家之后的感觉:推理能力强的模型适合做规划和复杂判断,但贵且慢;小模型适合做工具调用和简单路由,便宜快但容易出错。 我现在用混合:主推理用强模型,工具调用和短对话用小模型,按任务难度路由。 选型这事没有标准答案,得拿你自己的任务
讨论
我做应用基本离不开 API 调用了,以前是某一家死忠,最近半年纷纷转向多供应商。原因一是价格战打起来,二是各家各有擅长,三是怕单一供应商出故障全盘崩。 我现在主力推理用一家,工具调用用另一家,便宜路由用开源小模型,靠一个统一网关切换。 缺点是不同模型行为差异大,prompt 经常
讨论
每次看到"上下文又翻倍"的新闻,都有人喊"RAG 要死了"。但我学了一阵子 RAG 之后觉得,这说法太夸张。 长上下文确实能塞下更多原文,但贵、慢、而且模型对超长上下文的"中间遗忘"问题还在。RAG 的优势是精准召回 + 成本可控 + 可追溯来源,这些是长上下文替代不了的。 我的
讨论
搭了个 RAG,文档塞了几百篇,但检索效果很差,top 5 里经常只有一两条相关,甚至完全不沾边。embedding 用的也是主流模型,不知道哪出了问题。 怀疑过几个点:chunk 切太大(一段塞了多个主题)、问题太短召回不上、或者文档本身噪音多。 排查了一周没头绪。大家有没有