7B模型LoRA微调实录：显存8G→6.2G的QLoRA榨干每一兆显存
本文记录基于ChatGLM3-6B的LoRA/QLoRA微调全过程。通过bitsandbytes的4bit NF4量化+LoRA（秩=8，alpha=16），将单卡显存需求从全参微调的84G压至6.2G，在单张RTX 3090上完成医疗问答任务微调。训练3个epoch后，BLEU从13.8提升至22.4，但发现灾难性遗忘问题——通用能力下降11.7%。文中给出完整的量化配置、训练脚本、loss曲线
Python异步重构：用asyncio把Web API响应时间从900ms压到150ms
负责的订单查询接口在压测时P99延迟飙到900ms，数据库连接池被打满，CPU却只用了12%。在Python 3.10环境下用asyncio+httpx重构了第三方API调用链，把串行阻塞I/O改成并发协程，配合信号量限流和连接复用，最终P99降到147ms，QPS从320提升到2100。文章记录了完整的before/after代码、压测数据以及四个真实的踩坑点（包括asyncio.run的隐藏坑
Prompt工程化调优实录：从7.2分到9.1分的RAG问答系统
在构建基于GPT-4o-mini的RAG知识库问答系统时，我发现同样的检索结果，仅因Prompt设计不同，最终答案的准确率从62%飙升到89%。本文记录了针对“多文档冲突信息处理”这一具体任务的12组Prompt对比实验，包含token消耗从平均814到1560的变化曲线，以及最终采用的“三层结构+角色约束+格式锚定”方案。文中所有代码和版本均来自实际生产环境（Python 3.11.4，Lang
RAG系统优化实录：chunk策略、Embedding切换与Rerank引入的收益分析
在搭建企业知识库问答系统时，我们遇到了一个典型问题：当文档量突破5000份、切片超过4.2万个时，Top-5召回准确率从88%骤降至67%，用户明显感觉到答案“答非所问”。本文记录了从chunk_size=512到多策略混合切片的调整过程，以及从bge-large-zh-v1.5切换至Qwen3-Embedding-0.6B、再引入bge-reranker-v2-m3后的完整对比实验。最终，Rec
RAG系统三阶优化实录：chunk重构与embedding切换及rerank融合
检索增强生成（RAG）系统在私有知识库问答中常面临“召回不准、生成幻觉”的双重困境。本文记录一次针对客服工单知识库的完整优化过程，涉及文本分块（chunk）策略从固定256字符到语义段落的转变、Embedding模型从`text2vec-large-chinese`到`bge-large-zh-v1.5`的升级，以及引入`bge-reranker-v2-m3`进行重排。最终，在内部评测集（500道
FastAPI服务压测502ms到89ms：SQLAlchemy查询与Redis缓存调优全记录
接手一个FastAPI + PostgreSQL的订单查询服务，压测发现P95延迟高达502ms，QPS只有382。通过py-spy定位到90%时间耗在SQLAlchemy ORM懒加载和N+1查询上；改用`selectinload`预取关联表后，P95降到217ms；再引入Redis缓存热点订单数据，配合`cachetools`做进程内二级缓存，最终P95稳定在89ms，QPS提升到2100+。
FastAPI接口耗时3370ms降至89ms：Profile与缓存调优全记录
生产环境某订单聚合接口在QPS 80时P99延迟飙至3370ms，经py-spy与SQLAlchemy慢日志定位，发现N+1查询占60%开销、Redis未利用且存在重复计算。通过联合加载、LruCache与Redis二级缓存三层优化，配合Gunicorn+Uvicorn多Worker部署，最终将P99降至89ms，吞吐量提升4.2倍。本文记录完整排查链路，附可复现代码与压测数据。
RAG准确率从62%到89%：chunk重切与embedding选型及rerank实践
线上一个基于LangChain的客服问答RAG系统，初期使用固定512字符切分、OpenAI text-embedding-ada-002，在1278条内部评测集上HitRate仅62%，且答案幻觉频发。本文记录了为期三周的优化全过程：通过中文语义感知的递归切分策略、切换至BAAI/bge-large-zh-v1.5并进行有监督领域微调，以及引入bge-reranker-v2-m3进行二次排序，最
Prompt工程化调优实录：从47%到89%的抽取准确率跃迁
在医疗文本结构化任务中，我通过系统性迭代12版Prompt，将实体抽取F1值从0.47提升至0.89，单次调用token消耗从1847降至623。本文记录了完整的实验矩阵——从零样本指令到Few-shot思维链，包含温度系数、分隔符、输出JSON约束等7个变量的控制变量测试。特别对比了ChatGPT-4-turbo与Claude-3.5-sonnet在同一套Prompt下的性能差异，最终沉淀出一套
Prompt编排四轮迭代：信息抽取任务从52%到91%准确率
文本结构化抽取是RAG落地的第一道坎。本文以“招标公告关键字段抽取”为实验场，对比零样本、角色约束、思维链与自一致性校验四类Prompt在gpt-3.5-turbo-1106上的表现。实验显示，仅靠“你是专家”式约束只能提升4个百分点；引入“先找边界再填字段”的分步指令后，F1从0.61跃升至0.78；最终通过Few-shot示例对齐输出格式并加入结果自检，准确率稳定在91.2%，单条Token消
Milvus与Qdrant选型实测：千万级向量检索下的部署与资源博弈
在电商以图搜图业务中，面对1000万条768维向量，Milvus 2.4与Qdrant 1.9在同等硬件下表现迥异。Milvus靠Knowhere索引库在查询延迟上胜出（P99 12ms vs 18ms），但Qdrant的Rust底层将内存占用压低了近40%。本文给出双系统的Docker Compose部署、压测脚本及调参全过程，并曝光一个Milvus的段文件合并坑——不处理的话，写入吞吐会直接腰
FastAPI接口300ms到38ms调优全记录：cProfile定位与Redis缓存实践
一个内部报表接口从日均调用12万次、P95延迟312ms优化到38ms，吞吐量提升3.2倍。本文记录了完整的调优链路：先用cProfile和py-spy定位到SQLAlchemy ORM的N+1查询和重复序列化两大瓶颈，再通过联合索引、selectinload预加载、以及Redis二级缓存三层优化，最终将单次请求的数据库查询次数从47次降到3次。文中包含完整的profiling命令、缓存策略代码和
React 19与Vue 3.5跨框架迁移：从Props钻透到Zustand/Pinia的状态重构实录
接手一个维护两年的后台项目，270+组件、props drilling导致42%的无效重渲染，首屏交互延迟平均380ms。本文记录从React 19 + Vue 3.5双技术栈混合架构中，将Context/Props迁移至Zustand 5.0.3与Pinia 3.0.2的完整决策路径。包含性能火焰图对比、迁移顺序策略、以及一个隐藏的getter闭包陷阱。实测迁移后组件重渲染次数下降67%，状态更
Milvus与Qdrant双雄对决：电商语义检索场景实测选型
在商品标题向量检索场景下，我用真实数据对比Milvus 2.4.1与Qdrant 1.9.0。部署上Milvus用Helm三节点集群，Qdrant用Docker单节点+WAL。实测300万条768维向量，Qdrant纯查询P99 8ms优于Milvus的15ms，但Milvus在混合过滤（标签+向量）场景下召回率稳定在0.93，Qdrant降至0.81。资源占用上Qdrant内存峰值低37%，但M
React 19与Vue 3项目从Props钻透到Zustand/Pinia的迁移实录与性能对比
在维护一个超300个路由级组件的后台系统时，Context透传导致的重渲染风暴让我被迫按下了重构键。本文记录了从React 18 + Vue 3.4的混合架构中，将高频交互模块（如全局筛选器）从Context/Props逐层转发迁移至Zustand 5.0与Pinia 2.2的完整过程。文中对比了三种方案的内存快照与渲染耗时（FPS从41提升至59，组件更新延迟降低72%），并提供了可运行的代码示
LangChain与AutoGPT双驱动：手写Agent循环控制与记忆管理
本文不讨论Agent概念，只讲代码实现。我将带你从零手写一个具备工具调用、短期记忆和异常恢复能力的AI Agent，核心依赖LangChain 0.1.0和自研的AutoGPT风格循环控制器。文中包含两个可运行代码块：一个是基于ReAct模式的工具定义与解析，另一个是带错误重试和记忆裁剪的Agent主循环。实测在复杂工具链场景下，任务完成率从裸调LLM的62%提升至91%，平均响应时间1.8s。你
Python异步编程：asyncio优化Web API响应时间提升5倍
在压测一个基于Django+requests的订单查询API时，我发现接口在20并发下P95响应时间高达1.8秒，而数据库查询本身只需120ms。通过引入asyncio+httpx重写业务调用链，将三次串行外部HTTP请求改为异步并发，P95响应时间从1.8s降至350ms，吞吐量提升4.7倍。本文记录了完整的优化过程——从问题定位、asyncio改造方案、代码迁移细节到生产环境踩到的坑（如事件循
asyncio重构Flask接口，QPS从187到1520的并发改造实录
在一次电商订单导出服务中，我遇到CPU空闲但接口超时的诡异场景。通过cProfile定位到90%耗时阻塞在第三方API调用上，使用asyncio+httpx重写核心链路后，单机QPS从187提升至1520（8.1倍），P99延迟从2.3s降至340ms。本文将完整记录这次改造过程，包括asyncio.Semaphore限流的正确姿势、与Flask同步生态的集成方案，以及协程池+线程池混合调度的性能
asyncio重构Flask接口，QPS从120飙到850
一个内部报表接口因串行调用三次外部HTTP服务，单机QPS只有120，P99延迟2.3秒。我用asyncio配合httpx重写核心逻辑，连接池复用+并发请求，QPS提升至850，P99降至380ms。文章记录了完整的重构过程：从协程设计、信号量限流到UVloop切换，包含before/after代码和压测数据，以及一个让人抓狂的event loop坑。
LoRA微调7B模型全记录：从显存优化到指令遵循能力跃升
本文记录使用LoRA（Low-Rank Adaptation）微调Qwen2-7B-Instruct模型的具体实践过程。在单张A100-80G显卡上，通过QLoRA（4bit量化+LoRA）将显存占用从70GB压缩至18GB，微调成本降低60%。基于alpaca-cleaned中文指令数据集训练3个epoch后，模型在CEval验证集上的得分从47.2提升至58.6（+24.1%），在人工构造的5
