1 个三级分类
三级分类
技术体系化整理、工程实践与开发笔记。
专题分组
1 个三级分类
三级分类
2 个三级分类
3 个三级分类
2 个三级分类
2 个三级分类
3 个三级分类
1 个三级分类
三级分类
AI 大模型开发这份笔记围绕 Python 异步项目中封装类 OpenAI Chat 接口的基础用法展开,场景是通过 one-api 统一管理不同模型服务后,在业务代码里只需关注 model 参数切换具体模型。代码使用 AsyncOpenAI 初始化客户端,并提供两个常用方法:gpt_stream 以异步生成器方式开启 stream=True,逐块 yield 模型返回内容;gpt_chat_no_stream 则一次性获取回复,适合普通问答或需要结构化结果的调用。非流式函数还演示了 JSON 输出的处理方式,包括在 system 提示中强调只返回 JSON、设置 response_format,以及对返回内容执行 json.loads。文章同时说明 Chat 接口的 messages 结构由 system、user、assistant 三类角色组成,推荐将 system 放在最前,历史对话按时间顺序追加,再放入当前用户输入。需要注意的是,历史记录可以帮助模型延续上下文,但不应重复塞入 system 指令,过长历史也会增加 token 成本,因此应根据业务做裁剪或摘要。整体适合正在把大模型能力接入后端服务、需要同时支持流式输出和结构化返回的开发者参考。
AI 大模型开发这份草稿围绕 AI 对话系统中的长期记忆与上下文压缩展开,目标是在多轮聊天中兼顾相关历史召回、上下文长度限制、响应延迟和存储成本。方案把一次请求链路拆成 MemoryRetriever、ContextManager、PromptBuilder、GPTClient、MemoryUpdater 等模块:先按用户输入检索多段记忆,再用滑动窗口裁剪近期对话,必要时调用 Summarizer 压缩溢出内容,最后拼接 system、memory、window、user 形成模型 messages,并把回复或摘要写回 MemoryStore。实现细节强调在消息记录中预存字符数或 token 数,从最近 5 轮对话取 5 条用户消息和 5 条 AI 回复,按时间排序后累加长度,以较低遍历成本避免单条长消息撑爆上下文。摘要策略部分比较了按回合生成 memory_segment、让主模型同次输出 answer 与 summary、以及后台 Worker 异步调用廉价模型摘要三种做法。草稿也指出工程上的取舍:同步摘要更简单但可能增加延迟,异步摘要能保留流式体验并通过固定条数淘汰控制规模,格式异常时还需要客户端校验和降级。它适合作为聊天产品、AI 应用后端或 Agent 记忆系统的初步设计参考,帮助评估上下文完整性、检索粒度、调用成本和实现复杂度之间的平衡。
这篇笔记聚焦 Python 中 OpenAI Chat Completions 的异步流式调用,适用于希望把模型响应按片段实时输出到终端或业务层的开发场景。内容先从环境变量读取入手,强调用 os.getenv 获取 OPENAI_API_KEY、OPENAI_BASE_URL 和 OPENAI_MODEL,并说明 python-dotenv 的安装包名与导入模块名不同:通过 pip install python-dotenv 安装,但代码中从 dotenv 导入 load_dotenv。核心示例封装了一个 AsyncOpenAIOut 类,在初始化阶段创建 AsyncOpenAI 客户端,在 gpt_stream 方法中组合 history、system_prompt 和用户消息,并以 stream=True 发起请求。代码通过 async for 遍历 OpenAI 返回的流式 response,检查 chunk.choices[0].delta.content 后用 yield 逐块产出内容,因此调用方也需要用 async for 消费这个异步生成器。文章还补充了 print(chunk) 在事件循环中的行为:它是同步执行,但在简单逐步输出场景通常可接受;若希望更严格地避免占用事件循环,可以用 asyncio.to_thread(print, chunk) 放到后台线程执行。整体价值在于把 .env 配置、AsyncOpenAI 初始化、消息组装、流式响应解析和 async for/yield 的语义串成一个可运行样例,适合正在接入 OpenAI 兼容接口或学习 Python 异步流处理的开发者。
“AI 大模型开发”类别用于为与大模型应用、工程实现和开发实践相关的内容建立清晰归档入口,重点服务于需要快速判断文章是否属于该主题的分类选择场景。该类别说明强调先给出简短定位,再通过更完整的准则解释设立理由、使用目的、与既有类别的边界以及可收录的话题范围。它关注的不只是命名本身,还包括分类是否会与其他类别重叠、是否应作为独立类别保留,以及在维护成本和检索便利之间如何取舍。适合纳入的内容应围绕 AI 大模型开发这一主题展开,而不应仅因泛泛提到 AI 或工具名称就归入其中。对站点维护者来说,这类说明的价值在于统一收录标准,减少后续文章分类时的随意性和重复归档。对于读者而言,清晰的类别定位也有助于在浏览知识库时判断这里是否集中呈现大模型开发相关的实践、规则和经验。
“常规”类别用于收纳暂时无法归入站点其他既有分类的内容,承担的是通用入口和兜底归档的作用。它适合放置主题边界尚不清晰、跨越多个方向,或当前分类体系尚未覆盖的话题,避免这些内容因为缺少精确归属而难以发布或检索。使用这一类别时,应优先判断是否已有更具体的分类可用;只有在确实不适合放入其他栏目时,才将其归入这里。对读者而言,这一分类提示内容可能具有较宽泛的主题范围,需要结合标题和正文进一步判断阅读价值。对维护者而言,它有助于在分类体系尚未完善时保持内容组织的连续性,同时也提醒后续可根据积累情况拆分或迁移到更精确的专题。