RAG命中率从61%到89%：chunk重构与rerank双阶段调优实录
两个月前，我们基于LlamaIndex搭建的RAG问答系统在内部知识库上命中率仅有61%，Top-5召回准确率惨不忍睹。经过对chunk策略的反复试验（从固定256字到语义段落切分）、Embedding模型从`text2vec-large-chinese`切换到`bge-large-zh-v1.5`，以及引入`bge-reranker-base`进行精排，最终将Hit Rate提升至89%，MRR
Git工作流重构记：分支策略与CI/CD集成调优全程
从SVN迁移到Git后，我们团队曾因混乱的分支模型导致每周平均2.3次误合并，发布前Code Review形同虚设。本文记录了我们基于Git 2.39.1重构工作流的全过程：采用Trunk-based Development + 短生命周期特性分支，引入GitHub Flow的PR机制，结合Jenkins Pipeline 2.44实现自动化门禁。最终将代码集成周期从2天缩短至4小时，线上事故率下
Milvus 2.4与Qdrant 1.9向量检索对决：千万级数据实测
在电商以图搜图业务中，我们对比了Milvus 2.4.1与Qdrant 1.9.2的部署复杂度、查询性能与资源占用。使用7台物理机（6核32G）部署集群，测试1000万条768维向量。实测结果：Qdrant单机QPS达3200（P99=38ms），Milvus集群QPS为2800（P99=45ms），但Milvus在过滤查询（标量+向量混合）场景下延迟更低。内存占用方面Qdrant比Milvus少
FastAPI接口从800ms到60ms：Profile、SQL优化与Redis三级缓存实践
一个电商订单聚合接口，QPS 200时P99延迟飙到800ms，CPU空转但DB负载打满。本文记录完整调优过程：先用cProfile和py-spy定位到N+1查询和JSON序列化热点，再通过SQLAlchemy 2.0的selectinload批量加载、索引覆盖以及Redis三级缓存策略，最终将P99降至62ms，QPS稳定在1200+。文中包含可复用的profiling脚本和缓存失效方案，以及压
向量数据库选型实录：Milvus与Qdrant在图像检索场景下的性能对决
本文基于一个真实的服装图像检索业务，在8核16G内存的物理机上对Milvus 2.3.3和Qdrant 1.7.3进行了全流程对比。从Docker部署、Python客户端写入500万条128维向量，到混合查询（向量+标量过滤）的P99延迟和召回率，再到内存/磁盘占用实测数据，完整呈现两个系统的优劣。结论：Qdrant在资源占用上仅为Milvus的40%，但Milvus的标量过滤能力和集群扩展性更胜
asyncio重构Flask接口，QPS从120到850的完整改造记录
一个内部报表API，平均响应时间380ms，QPS卡在120上不去。数据库查询没问题，纯CPU计算密集，GIL锁成了瓶颈。用asyncio + uvloop替换了原来的多线程方案，配合aiohttp纯异步客户端，最终QPS稳定在850左右，P99延迟从520ms降到180ms。这篇文章记录了整个改造过程，包括asyncio.Semaphore控制并发、loop.run_in_executor规避阻
Prompt工程化调优实录：实体抽取任务的Token成本与输出质量权衡
在Llama-3-8B-Instruct-4bit上对司法文书实体抽取任务做了12组Prompt对比实验。零样本模板F1仅62.3%，通过角色约束+输出JSON Schema+少样本示例，F1提升至84.7%，但Token消耗从每案412增至1893。最终用动态示例选择策略，将F1稳定在83.1%，Token压缩至772。本文记录了完整的调优路径、踩坑点（如JSON解析失败率从31%降至2.7%）
Docker Compose编排生产级多服务：网络隔离、健康检查与启动顺序实践
本文基于Docker Compose v2.24.2，完整拆解一个包含Nginx网关、Spring Boot 3.2应用、PostgreSQL 15与Redis 7的四服务编排方案。通过自定义bridge网络实现前后端隔离，利用volume持久化数据库与缓存数据，配置TCP/HTTP双重健康检查，并借助depends_on条件与init容器解决服务启动竞态问题。部署后实测冷启动时间从手动部署的4分
LangChain与AutoGPT双引擎：手写AI Agent循环控制与记忆管理
本文不讨论LangChain框架的表面封装，而是深入其AgentExecutor源码与AutoGPT的Plan-and-Execute模式，手写一个具备工具调用、短期/长期记忆、异常恢复机制的最小Agent。我们将用LangChain 0.1.0 + Python 3.11实现一个能自主完成“查询数据库→调用API→生成报告”的Agent，并对比AutoGPT的循环控制差异。实测在单轮任务中，自定
告别Prop Drilling：React 18与Vue 3项目迁移Zustand/Pinia的工程化记录
本文记录了在三个中型项目（React 18 + TS、Vue 3 + `<script setup>`）中，将全局状态从Context/Props逐层透传迁移至Zustand v4.4与Pinia v2.1的完整过程。对比了两种方案的性能差异：迁移后React项目首屏渲染时间从2.1s降至1.2s，组件重渲染次数减少67%；Vue项目Devtools中状态追踪时间减少40%。详细说明了迁移的6个步
FastAPI与Flask性能对决：Profiling到缓存的全链路调优实录
在一次高并发订单查询接口压测中，FastAPI版本QPS仅1800，Flask版本更是只有650。通过cProfile与Py-Spy定位到N+1查询和JSON序列化两大瓶颈，配合SQLAlchemy懒加载优化、Redis缓存热点数据以及异步改造，最终FastAPI接口QPS提升至9200，Flask提升至4100。本文完整记录调优思路、工具使用细节与踩坑过程，包含可复现的代码片段和压测数据对比。
asyncio重构Flask接口：Web API并发性能提升5.7倍的完整记录
上周优化一个内部数据看板服务，发现其聚合接口在300并发下P95延迟高达2.3秒，数据库连接池被占满。我用asyncio+httpx重写了核心调用链，将串行IO等待改为协程并发，并针对Python 3.11的asyncio机制做了三个关键调优。最终P95降至0.4秒，吞吐量从180 RPS提升到1030 RPS。本文记录完整的重构思路、踩坑过程和性能对比数据，包括event loop策略选择、超时
Prompt Engineering调优实录：从45%到92%的抽取准确率跃升
在实体抽取任务中，我对比了零样本、少样本、思维链及结构化输出四类Prompt策略。通过200条真实法律文书测试，发现加入XML标签约束和两步推理后，F1值从0.45提升至0.92，单条token消耗从3200降至1800。本文完整记录实验设计、失败案例与优化路径，附可复用代码模板，帮你绕过那些我踩过的坑。
FastAPI接口从2300ms到180ms：Profiling与缓存优化全记录
一个简单的列表接口，压测P95延迟2300ms，QPS仅380。通过cProfile定位到N+1查询和JSON序列化两大瓶颈，配合SQLAlchemy 2.0的selectinload优化数据库访问，再用Redis Cluster缓存热点数据，最终P95降至180ms，QPS提升到4200。本文记录完整的调优过程，包含flask-profiler与FastAPI中间件的具体配置，以及一次诡异的连接
Git分支策略与Code Review流水线：从混乱到有序的版本控制实践
在15人研发团队中，我们曾因分支混乱导致每周平均3次合并冲突、2次误推master事故。通过引入Git Flow + GitHub PR模板 + Jenkins多分支流水线，将发布周期从2天缩短至4小时，冲突率下降80%。本文分享这套工作流的完整设计、配置代码与踩坑记录，包含`.gitignore`策略、`git bisect`定位回归、以及Jenkinsfile声明式流水线的具体参数，适合中型团
Prompt工程化调优实录：从42%到89%的指令压缩与Token成本实验
同一文本分类任务，我用了7种Prompt模板迭代，准确率从42%飙到89%，Token消耗却从单次1872降到642。本文记录了在llama.cpp + Qwen2.5-7B-Instruct环境下，不同指令结构、角色设定、Few-shot示例对输出的影响。包含完整代码、温度参数调节、以及一次因Prompt过长触发上下文截断导致雪崩的翻车现场。全文3000字，全是实测数据。
Git分支策略与Code Review流水线：团队协作从混乱到有序的蜕变
当团队从5人扩张到25人时，master分支上的merge冲突和误推送让发布延迟了40%。本文记录了我们如何通过Git Flow改良版+GitLab Code Review+Jenkins CI/CD的组合拳，将分支管理规范化。你会看到具体的分支保护规则、.gitlab-ci.yml配置、以及我们如何用pre-commit钩子把代码风格问题拦截在提交前。最终，我们的发布周期从2天缩短到4小时，线上
React 19与Vue 3.5状态管理迁移实录：从Props钻透到Pinia/Zustand的架构蜕变
在维护一个迭代两年的后台管理系统时，我面对的是超过30层嵌套的Props传递和Context导致的频繁重渲染。本文记录了将项目从Context/Props模式迁移至Zustand v5与Pinia v3的完整过程。通过对比两种方案在React 19与Vue 3.5下的性能表现，迁移后组件渲染耗时平均降低42%，代码量减少35%，且解决了因Context value变化引发的全子树更新问题。文中包含
7B模型LoRA/QLoRA微调全记录：从数据准备到loss曲线与推理对比
上周刚用LoRA和QLoRA把Llama-3-8B（实际权重7B）微调成法律问答模型，踩了一堆坑，也拿到了实打实的数据。在单张A100（80G）上，QLoRA的显存峰值只有14.3G，训练速度是LoRA的1.7倍，最终loss从1.82降到0.47。推理阶段，微调后的模型在20个法律案例问答上，答案相关性和格式规范度远超base模型，但偶尔会出现幻觉。本文记录完整流程，包括数据清洗、bitsand
FastAPI慢查询优化实录：从1500ms到80ms的profiling与缓存改造
一次真实的API性能调优过程。一个基于FastAPI的订单查询接口，单次请求耗时1500ms，QPS仅120。通过cProfile定位到90%时间消耗在N+1数据库查询和重复计算上。使用SQLAlchemy 2.0的selectinload替代lazy load，配合Redis缓存热点数据和Cython加速序列化，最终将P95延迟降到80ms，QPS提升至1800。本文记录完整的profiling
