LLM 集成方案

解决的问题

直接集成大模型 API 的工程师常陷入三类困境：调用层脆弱（单次重试都缺失、延迟与预算失控）、交互方式单一（非流式响应等待时间长、无法执行工具调用）、知识利用低效（RAG 管道设计随意、输出未经验证直接进入下游代码）。这些反模式往往导致线上成本超支或用户体验下降。

核心能力

API Client Pattern：提供标准化的调用封装，内置重试逻辑与指数退避机制，所有 API 请求必须经过 retry_with_backoff 包装并处理超时、限流等错误。

流式响应与交互优化：面向用户的场景必须启用 streaming=True，通过分块传输降低首字延迟；函数调用需在 schema 中包含清晰的工具描述，避免模型因参数模糊调用失败。

RAG 管道设计：文档分块采用 500-1000 tokens 尺寸并保留 10-20% 重叠，优先评估检索质量（如用 nDCG 指标）再优化生成层，避免“先搭管道后补评估”的常见误区。

成本与可靠性控制：强制跟踪 token 使用（建议用 token_counter 工具记录每轮交互），按任务复杂度选模型（简单分类任务禁用旗舰模型）；所有 LLM 输出需经过格式校验（如 JSON Schema）或敏感信息过滤后再用于代码逻辑。

适用边界

本技能聚焦“工程化集成最佳实践”，不包含模型微调或私有化部署指南。其 RAG 分块策略适用于通用文本（如技术文档、客服知识库），对代码库或结构化数据需结合领域特征调整参数。使用前需确认 API 客户端支持异步重试与流式传输，否则需先适配底层网络库。