可以想象是个技能商店，智能音箱那种能够动态添加天气、音乐技能的机制） . 保持统一的质量 团队在首月内实现了我们目标体验的%，随后又额外花费了四个月时间，致力于将我们的全面体验完成度提升至%以上——我们勤勉地工作，对各个方面进行精细化调整、优化和改进。
然而
我们低估了检测和减轻幻觉现象的挑战，以及质量 Paytm 数据库 评分提升的难度（注：原文是速度应该是笔误）——起初迅速攀升，随后便迅速达到瓶颈期。 对于那些容忍一定错误率的产品而言，采用生成式进行构建无疑是一种令人耳目一新的直接方法。但这也带来了不切实际的期望，初期的快速进展营造了一种“即将达成”的错觉，而随着后续每%提升的改进速度显著放缓，这种快速改进的错觉变得令人沮丧。 构建该助手感觉像是偏离了“原则性”的机器学习，而更像是在专家系统中调整规则。
因此，尽管我们的评估变得越来越复杂，但我们的“训练”却主要是提示词工程，这更像是一门艺术而非科学。 还在死磕的事：对大语言模型（）进行微调，以使我们的流程更加数据驱动。
其实是肯定会出问题
所以修的要快） . 容量与延迟 容量和成员感知到的延迟始终是我们最关心的问题。以下是一些维度： 质量 延迟：像“思维链”（ , ）这样的技术 为什么你需要让整个采购委员会参与进来（而不仅仅是少数决策者） 非常有效地提高了质量并减少了幻觉现象。但它们需要成员从未预想过的，因此增加了成员感知到的延迟。 吞吐量 延迟：在运行大模型时，通常情况是“首个响应时间”（, ）和“间响应时间”（, ）会随着使用率的增加而增加。在的情况下，有时延迟甚至会呈现线性增长。如果你愿意牺牲这两个方面的度量，获得每秒数（, ）的两倍或三倍增加是很容易的，但我们最初必须将它们限制得很紧。
（注：否则用户会觉得慢） 成本
集群并不容易获得且成本高昂。在初期，我们甚至 1000个手机号码 不得不为产品测试设定时间表，因为测试会消耗太多并阻止开发人员工作。 端到端流式传输：一个完整的答案可能需要几分钟才能完成，因此我们让所有请求进行流式传输以减少感知到的延迟。更重要的是，我们实际上在流程内部实现了端到端的流式传输。
