Prompt Engineering实测：四版指令调优百度ERNIE 4.0抽取F1值提升22%
同一份千行合同文本，用默认Prompt跑百度ERNIE 4.0（2024年3月版），实体抽取F1值只有0.63，token消耗却高达4821。经过四轮指令重构——加入角色约束、输出Schema、否定指令和示例驱动后，F1飙到0.85，token直降37%。本文用真实业务场景（企业采购合同关键条款抽取）记录完整的Prompt实验日志，包含每版Prompt的完整代码、API参数配置、失败案例分析，以及
Git分支策略与Code Review流水线：日均200次合并的团队协作方案
当团队从15人扩张到40人，主干分支从每周3次冲突演变为每天20+次合并阻塞。本文记录我们基于Git 2.39重构的分支策略与Code Review流水线：采用Trunk-based + 短生命周期特性分支，配合GitLab 15.11的Merge Request审批规则与Jenkins 2.414自动构建，将合并等待时间从平均47分钟压缩到8分钟，线上事故率下降62%。文中给出完整的.gitla
RAG召回率从61%到89%：chunk重构与embedding重选全记录
线上客服知识库RAG系统一度召回升至瓶颈，Top-5命中率仅61%。通过将固定256字符chunk改为语义段落+重叠窗口、将bge-large-zh替换为bge-m3、并引入bge-reranker-base重排，最终Top-5命中率提升至89%，单次检索耗时从380ms增至520ms但可接受。本文记录完整调优路径，含全部核心代码与参数配置。
LoRA微调Llama-3-7B中文医疗问答：显存8G跑通全流程与效果实测
微调7B大模型一定需要A100？本文记录使用单张RTX 3090（24G显存）通过QLoRA（4bit NF4量化）微调Llama-3-8B-Instruct，在自建的中文医疗指令集（2.1万条）上训练3个epoch，显存峰值仅14.7G，训练时长6小时40分。对比Base模型与LoRA（16G显存）和QLoRA的推理效果，发现QLoRA在医学领域F1-score提升12.3%，且模型幻觉率下降明
LangChain 0.3手写Agent：记忆与循环控制从零实现
当AutoGPT的自动化任务在复杂场景中频繁失控时，自己手写Agent成为可控性的关键。本文基于LangChain 0.3.7，从零构建一个具备工具调用、滑动窗口记忆、try-except错误恢复及最大迭代限制的Agent。实测在18个工具调用场景下，循环控制将死循环率从AutoGPT的23%降至0%，单次任务内存占用控制在45MB以内。代码全公开，含三个可运行示例，重点拆解工具描述如何影响LLM
FastAPI接口300ms压到38ms：profile、SQL三板斧与Redis缓存实战
一个真实的后台查询接口，P95延迟从312ms降到38ms，吞吐量提升4.6倍。文章记录了完整的调优链路：先用cProfile和py-spy定位CPU热点，发现SQLAlchemy ORM隐式N+1查询和JSON序列化是两大元凶；随后用`explain ANALYZE`重写SQL，引入联合索引与`selectinload`；最后在Redis层做二级缓存，配合`lru_cache`做热点参数缓存。文
asyncio重构Flask API：QPS从37到312的完整改造记录
在一次外部接口压测中，我发现一个基于Flask 2.1 + Requests库的聚合API在50并发下QPS仅37，P99延迟高达4.8秒。通过将阻塞IO替换为asyncio + aiohttp，并在Flask中嵌入asyncio.run，仅改动80行代码，QPS提升至312（8.4倍），P99降至410ms。本博客完整记录这次改造的全部细节：包括事件循环冲突的坑、Semaphore信号量控制并发
RAG召回率从61%到89%：chunk重构与embedding重排的工程实践
在基于LangChain构建的金融文档问答系统中，通过三个阶段的优化——滑动窗口chunk策略替代固定长度切分、bge-large-zh-v1.5替换text2vec-large-chinese、以及引入bge-reranker-base重排序模型，将Top-5召回准确率从61.3%提升至89.7%。本文记录了完整的调优过程，包括向量维度对检索延迟的影响、chunk重叠率与上下文丢失的权衡、以及重
向量数据库选型：Milvus与Qdrant在百万级影视素材检索中的实测对比
在影视素材库的以图搜图业务中，我们对比了Milvus 2.4.1与Qdrant 1.9.2在百万级768维向量下的表现。Qdrant在单机部署上节省了约40%内存，查询P95延迟低至12ms，而Milvus在批量写入吞吐上领先35%。本文记录了两者的Docker部署、Python客户端代码、HNSW参数调优过程，以及一次关于内存溢出的惨痛踩坑经历，希望能为同样在做向量检索选型的朋友提供一份量化参考
Prompt工程化实验：实体抽取任务中5种模板的token与F1权衡
在实体抽取任务中，我对比了5种Prompt模板（零样本、少样本、思维链、结构化输出、角色扮演）在GPT-4-turbo（1106版本）下的表现。实验基于自建的中文金融公告数据集（200条），发现结构化输出模板在F1分数（0.82）与token消耗（平均412 tokens/条）之间取得了最佳平衡。而角色扮演模板虽然F1达到了0.85，但token开销暴涨至687 tokens/条，性价比骤降。文中
asyncio重构Flask接口，QPS从120飙到850的详细记录
一个内部报表API，单次查询需聚合3个微服务数据，平均耗时1.2秒，压测QPS仅120。我用asyncio+httpx将其重构为并发IO后，P95延迟从2.1s降到380ms，QPS稳定在850。本文记录从同步阻塞到异步非阻塞的完整改造过程，包含asyncio.Semaphore限流、超时控制、Python 3.11的asyncio.TaskGroup用法，以及一个差点导致连接池耗尽的坑。
Python asyncio重构Flask接口：耗时从2.3秒降至0.4秒
一个内部报表API，单次请求需聚合三个外部服务数据，平均耗时2.3秒。用asyncio + httpx重写后，耗时降至0.4秒，QPS从45提升到220。本文记录了完整的改造过程，包括event loop线程冲突的坑、信号量限流配置、以及Python 3.11 vs 3.10的性能差异。代码可直接复用到任何IO密集型的Web接口。
FastAPI+SQLAlchemy 2.0 性能调优：从1200ms到80ms的profiling与缓存实践
一个真实的生产环境接口，单次请求耗时1200ms，QPS仅能支撑50。通过py-spy定位到N+1查询与JSON序列化两大瓶颈，配合SQLAlchemy 2.0的selectinload优化和Redis二级缓存，最终将P95延迟压至80ms，QPS提升至800+。本文记录了完整的profiling工具链（py-spy、cProfile、Prometheus）、缓存策略设计（Cache-Aside
Python异步编程：asyncio重构Flask接口吞吐量提升3.2倍
在一次电商大促压测中，我发现某个订单查询接口在QPS达到200时RT飙升至2.8s，而数据库负载却不足30%。通过引入asyncio+httpx将串行RPC调用改为并发协程，接口吞吐量从320 QPS提升至1024 QPS，P99延迟从1.2s降至380ms。本文记录了完整的重构过程，包括asyncio.Semaphore限流、aiohttp连接池调优、以及uvloop替换事件循环的实测数据。踩坑
React 19与Vue 3.5下从Props钻取到Zustand与Pinia的状态重构实录
在维护一个拥有87个路由页面、42个共享业务模块的中后台系统时，props钻取导致的无效渲染让我在Chrome Performance面板里看到了单次交互触发31次组件重渲染的窘境。本文记录了从React 19的Context/Props方案迁移至Zustand v5，以及Vue 3.5项目迁移至Pinia v3的完整过程。包括迁移前后的bundle体积对比（React项目减少18KB，Vue项目
FastAPI接口耗时400ms优化到45ms：Profiling与缓存策略全记录
一个内部报表API在QPS 200时P95延迟飙至380ms，数据库CPU被打满。本文记录了从Profiling定位（cProfile+py-spy）、SQLAlchemy N+1查询治理、多级缓存（Redis+本地Cache）到最终P95降至48ms、CPU占用降72%的完整过程。包含FastAPI 0.115与SQLAlchemy 2.0的实操代码与压测数据对比，踩坑细节同步给出。
Git分支策略与Code Review流水线：支撑百人研发团队的协作体系
当团队从20人扩张到120人，主干开发模式引发的代码冲突、发布事故呈指数级增长。本文基于Git 2.39.1与GitLab 15.11，落地了一套融合Trunk-Based与GitFlow优点的混合分支策略，配合基于Merge Request的强制Code Review流水线（含Prettier、ESLint、Jest自动化门禁），将平均代码评审等待时间从4.2小时降至1.1小时，线上事故率降低7
asyncio重构Flask接口：并发等待减300%，QPS翻4倍全程记录
一个内部报表API，单次请求需聚合4个外部服务数据，平均耗时820ms，高峰期Tomcat线程池被打满。用asyncio + aiohttp重写后，P95延迟从1.2s降到280ms，QPS从120升到480。本文记录完整重构过程：从同步阻塞到事件循环，包含asyncio.Semaphore限流、连接池复用、超时控制三个关键优化点，并给出具体压测数据与Python 3.10下的踩坑解决方案。
FastAPI×Flask双框架API性能调优：cProfile定位与Redis缓存实战
一个生产环境接口从平均响应1800ms压到220ms，P99从4.2s降到380ms，数据库QPS从1200降至150，CPU占用降低40%。本文基于FastAPI(0.104.1)与Flask(3.0.0)双框架对比实验，完整记录了性能瓶颈的定位过程：先用cProfile和py-spy揪出隐藏的N+1查询与序列化开销，再通过SQLAlchemy(2.0.25)的`selectinload`策略和
React 19与Vue 3.5下从Context到Zustand/Pinia的状态重构实录
我的后台管理系统在列表页频繁操作时，Context导致的全局重渲染让性能面板飙红到120ms。本文记录从React 19的Context+useReducer迁移至Zustand 5，以及Vue 3.5的provide/inject迁移至Pinia 3的完整过程。包含两种框架的迁移对照、代码差异、以及迁移后FCP提升42%、交互响应时间从87ms降至23ms的具体优化数据。
