LLM 基础与调用机制

LLM API 本质上是一次请求一次响应,服务端不会自动记住你上一轮说了什么。所谓"有记忆",通常是应用层把历史对话、用户画像或检索到的资料重新拼进下一次 prompt 里,让模型看起来像连续记住了上下文。

• +短期记忆多用对话历史窗口,长期记忆多用数据库或向量检索保存可复用信息
• +无状态设计让 API 更容易扩容、重试和计费,但记忆管理要由业务系统负责
• +真正上线时要区分会话记忆、用户偏好和知识库,三者生命周期不同

Temperature 控制采样随机性,越低越稳定、越高越发散。结构化抽取、代码生成、分类这类任务通常调低;创意写作、头脑风暴、营销文案可以适当调高,让答案更有变化。

• +低 temperature 也不等于绝对确定,底层仍可能受并发、模型版本和浮点实现影响
• +Top-p 与 temperature 都影响采样分布,一般不要同时大幅调整,否则难以定位效果变化
• +生产任务更重要的是固定模型版本、提示词和评估集,而不是只调一个参数

核心思路是"该丢的丢、该压的压、该外挂的外挂"。常见三招:用滑动窗口只保留最近若干轮对话;把远期历史让模型总结成摘要再带上;真正海量的知识放进外部检索(RAG),用时再取。

• +滑动窗口实现简单但会"失忆",适合闲聊;摘要保留信息但有压缩损失,适合长任务
• +关键信息放上下文开头或结尾,规避 "Lost in the Middle" 效应
• +换大窗口模型能延后问题,但每次请求成本更高,需权衡

减少幻觉不是靠一句"不要胡说",而是让模型有依据、有约束、能拒答。常见做法是接 RAG 或工具拿事实,要求引用来源,限制输出格式,并在不确定时明确回答不知道。

• +把事实性问题交给检索、数据库或 API,模型负责组织语言和推理
• +对高风险场景加校验器、规则或人工审核,不要只信模型自检
• +评估幻觉要有黄金集和线上抽样,不能只靠肉眼看几条样例

Token 是模型实际处理文本的最小计量单位,不等同于中文字符或英文单词。模型按输入 token 和输出 token 计费,上下文越长、生成越多,推理计算越多,成本和延迟都会上升。

• +中文、英文、代码的 token 密度不同,同样字数的成本可能差很多
• +长 prompt 会增加首 token 延迟,长输出会拉长完整响应时间
• +优化成本时先砍重复上下文、日志噪声和无用字段,通常比换模型更直接

System 通常放全局规则和身份边界,User 放用户当前请求,Assistant 放历史回答或示例对话。角色的价值是帮助模型区分指令来源和优先级,让多轮对话更清晰。

• +安全边界和输出规范更适合放 System,临时任务参数更适合放 User
• +历史 Assistant 消息会影响模型风格和结论,不能无脑塞所有旧回复
• +用户输入永远不应被当成系统规则执行,这是防 prompt injection 的基础

Streaming 让模型边生成边返回,用户更早看到首 token,体验上不会一直等白屏。代价是前端要处理增量渲染、中断、重试和半截内容,后端也要处理连接保持和错误恢复。

• +Streaming 改善感知延迟,不一定降低完整生成时间
• +结构化 JSON 流式输出更难处理,需要缓冲、增量解析或最后校验
• +遇到工具调用时要区分文本流、工具调用事件和工具结果事件