FastAPI压测从1200到9800 QPS：profiling与缓存三层优化实录
一个用户画像服务上线后单实例QPS仅1200，P99延迟高达860ms，数据库连接池被打满。本文记录完整调优过程：用py-spy定位GIL争抢、cProfile揪出N+1查询、SQLAlchemy 2.0的`selectinload`替代`lazy='joined'`、Redis缓存热点数据与Caffeine本地缓存两级降级。调优后单实例QPS稳定在9800，P99降至41ms，数据库负载下降87
LangChain 0.3手写Agent：AutoGPT循环控制与记忆管理实践
本文记录一次从零实现轻量级AI Agent的完整过程，基于LangChain 0.3.7与GPT-4o-mini，核心代码仅180行。重点解决三个问题：如何设计可插拔的工具注册机制、如何用有限内存窗口实现长期记忆压缩、如何在循环中捕获工具异常并自动降级。最终Agent在5个连续工具调用场景下，任务完成率从初版61%提升至89%，平均单轮响应耗时稳定在2.3秒左右（含LLM推理与工具执行）。文中附全
asyncio重构Flask接口：QPS从120到850的并发优化实录
某次压测发现订单查询接口在200并发下超时率高达23%，平均响应时间1.8秒。通过asyncio+httpx异步化改造外部依赖调用，将同步阻塞的5次HTTP请求改为并发协程，接口吞吐量提升7倍，P99延迟从3200ms降至480ms。本文记录完整改造过程，包含asyncio.Semaphore限流、超时控制、连接池复用的坑与解，以及uvloop对性能的额外增益。
Prompt Engineering调优实录：从38%到91%准确率的RAG问答系统优化
在一次金融研报RAG问答系统开发中，我通过系统化Prompt Engineering，将GPT-4o-mini的答案准确率从38%提升至91%。本文记录了5轮Prompt迭代的完整实验数据：包括Few-shot示例数量对输出质量的影响（3-shot比0-shot准确率提升47%）、结构化指令与JSON输出约束的token消耗对比（平均每请求节省312 tokens）、以及系统Prompt中角色设定
用asyncio重构Flask API，并发性能提升300%的完整记录
上周接到一个紧急任务，线上某Flask服务在高峰期出现大量请求超时，单实例QPS只有80，P99延迟飙到1.8s。排查发现，瓶颈竟然是我们最引以为傲的“同步调用第三方REST API”逻辑——每个请求平均阻塞600ms。本文记录了我用Python 3.10 + asyncio + aiohttp对该服务进行异步化改造的全过程，包含before/after代码对比、协程并发模型设计、以及压测工具wr
7B模型LoRA微调实录：从loss震荡到指令遵循的调参全记录
本文记录一次完整的7B模型（Qwen2.5-7B-Instruct）LoRA微调实践。基于单张24G显存的RTX 3090，使用QLoRA（4-bit NF4量化）将显存峰值控制在17.8G。针对中文法律问答场景，构建8K条指令数据，通过对比r=8/16/32的收敛曲线，最终选定r=16+alpha=32组合。经过3个epoch训练（耗时4.2h），在100条人工评测集上，指令遵循准确率从基座的4
FastAPI与Flask双框架API性能调优：从900ms到40ms的Profiling与缓存实战
在接手一个日活10万+的库存查询服务时，该API在高峰期的P99延迟高达900ms，导致上游服务频繁超时重试。本文记录了针对FastAPI与Flask两个版本接口的完整调优过程：通过cProfile与py-spy定位CPU瓶颈，利用EXPLAIN ANALYZE发现索引失效与N+1查询，引入Redis三级缓存策略，最终将P99延迟降至40ms，QPS从380提升至5200。文中包含可复用的Prof
RAG召回率从61%到89%：chunk重构与rerank双阶段调优实录
线上问答系统命中率连续三周卡在61%，用户反馈“答非所问”占比高达34%。本文记录一次完整的RAG系统优化：通过动态chunk大小替换固定512字符切片，将召回准确率提升至73%；切换bge-large-zh-v1.5 embedding模型后提升至81%；最终引入bge-reranker-base重排，使Top-5命中率达到89%，首答准确率提升42%。全程附可运行代码、版本号及显存占用实测数据
7B模型LoRA微调实录：显存8G跑通中文指令微调与效果评测
在单卡RTX 3090上，用QLoRA对Llama-2-7B进行中文指令微调，显存峰值仅6.2GB。通过3000条高质量指令数据，3个epoch训练后，模型在C-Eval验证集上从34.2分提升至41.8分，推理速度保持12 tokens/s。本文完整记录数据清洗、bitsandbytes 4bit量化配置、PEFT LoRA参数选择、loss收敛曲线分析及微调前后输出对比，并附上训练脚本和踩坑记
Milvus与Qdrant在千万级向量检索下的选型实测对比
在处理2500万条768维向量、QPS峰值要求800+的RAG生产环境中，我先后用Milvus 2.4.1和Qdrant 1.9.2搭建了检索服务。实测结果：Milvus在16C32G配置下P99延迟9.2ms，Qdrant同样配置P99延迟14.7ms；但Qdrant的磁盘占用仅为Milvus的41%。本文用真实部署步骤、参数调优和压测数据，讲清楚两者在资源瓶颈和查询模式上的本质差异，帮你避开选
LoRA微调7B模型全记录：从数据处理到loss曲线与推理对比
上周用一张24G的RTX 3090，对Llama-2-7B做了LoRA微调，目标任务是“代码注释生成”。从数据清洗到训练完成花了约9小时，其中训练仅占4.2小时（batch size=4，seq_len=512，lora_rank=8）。最终在100条测试集上，微调后模型生成注释的BLEU从2.3涨到11.8，ROUGE-L从18.6%提升到34.2%。本文记录了完整流程，包括数据格式设计、tra
Git分支策略与Code Review流水线：日均50次合并的协作体系搭建
当团队从5人膨胀到20人，主干开发模式带来的冲突率飙升300%，紧急修复时常误伤未发布功能。本文基于Git 2.39.1与GitLab 15.7，记录了一套融合Trunk-based与Git Flow优点的混合分支策略。通过严格的保护规则、基于Merge Request的强制Code Review（至少2人批准）以及Jenkins Pipeline自动构建，将代码冲突率从每周17次降至3次，发布周
Git分支策略与Code Review流水线：团队协作中的版本控制实践
在30人规模的研发团队中，我们曾因混乱的Git分支策略导致每周平均3次合并冲突、2次误推送主干事件。引入Git Flow + PR Review + Jenkins CI/CD后，冲突率下降90%，发布周期从周级缩短至小时级。本文分享我们在Git 2.39.1环境下的分支模型设计、基于Gerrit的Code Review流程，以及Jenkins Pipeline与GitHub Webhook的自动
Milvus与Qdrant在商品向量检索中的选型对比与实测
在电商以图搜图场景中，我们对比了Milvus 2.4.5与Qdrant 1.9.7在100万条128维向量下的部署、查询与资源占用。实测发现：Qdrant在单机SSD下P95查询延迟为12ms，低于Milvus的18ms；而Milvus在批量写入吞吐上领先Qdrant约40%。资源占用方面，Qdrant内存峰值低35%，但Milvus的WAL机制在崩溃恢复时更稳。本文给出两套可运行部署代码、核心参
asyncio重构Flask接口：并发查询从2.1s降至0.3s的完整记录
在内部报表系统中，一个聚合多个数据源的API接口因串行阻塞导致P99延迟高达2.1秒。通过引入asyncio+httpx协程并发，将7个独立HTTP调用并行化，接口耗时降低至0.31秒，QPS提升6.8倍。本文记录从识别瓶颈、asyncio改造、信号量限流到uvicorn部署的完整过程，包含可复用的模板代码和踩坑日志。
asyncio重构Flask接口，QPS从120飙到1800的完整记录
一个内部报表系统的聚合接口，因为顺序调用3个外部HTTP服务，高峰期单机QPS只有120，CPU却跑满。我用asyncio+httpx把串行IO改成并发协程，配合信号量限流和超时重试，QPS稳定到1800，P99从2.8s降到420ms。文章记录了完整的before/after代码、asyncio.Semaphore踩坑过程、以及uvloop和pymysql对异步性能的影响。不吹不黑，全是生产环境
7B模型LoRA微调实录：显存8G跑通医疗问答的工程化方案
上周接到一个医疗领域问答任务，要在单卡8G显存下微调7B模型。用QLoRA+bitsandbytes把显存压到6.2G，训练3个epoch loss从1.8降到0.7，推理效果对比基座模型在专业术语准确率上提升31%。本文记录完整实践过程，包含数据清洗细节、PEFT配置参数、loss曲线分析以及三次踩坑修复记录。
LangChain与AutoGPT思想融合：手写Agent循环控制与记忆管理
当AutoGPT的自主循环遇上LangChain的工具抽象，我尝试用不到300行代码实现一个具备记忆、错误恢复和工具调用的Agent。在构建过程中，模型幻觉导致的JSON解析失败占到了总错误的62%，而通过引入重试机制和记忆裁剪，任务成功率从61%提升至89%。本文将拆解工具定义、记忆存储、循环控制等核心模块，并给出可直接运行的代码示例。
LangChain与AutoGPT思想融合：手写一个带记忆与异常自愈的AI Agent核心循环
两周前，我基于LangChain 0.1.0重写了一个内部知识库问答Agent，发现直接用`AgentExecutor`虽然快，但遇到工具调用失败或上下文超长时，系统直接崩溃。本文不讨论玩具Demo，而是手写一个仅依赖LangChain的`BaseTool`与`ChatOpenAI`的Agent核心循环，实现工具定义、滑动窗口记忆管理、三次重试错误处理以及最大迭代步数控制。代码实测在单轮多工具调用
Docker Compose编排多服务容器化部署：网络、健康检查与启动顺序实践
生产环境部署Spring Boot + Redis + MySQL + Nginx四服务时，因启动顺序不当导致应用频繁报连接拒绝，接口成功率仅82%。本文基于Docker Compose 2.24.2，通过depends_on条件判断、自定义网络隔离、卷挂载持久化及healthcheck探针，将服务启动成功率提升至99.5%，容器重启时间缩短40%。文中提供可直接运行的docker-compose
