从61%到89%：一次RAG检索增强生成系统调优全记录
本文记录了一个企业知识库问答系统的RAG优化过程。初始方案采用固定512字符切分与text-embedding-ada-002，Top-5召回准确率仅61%，答案幻觉频发。通过改用语义分块、切换bge-m3嵌入模型并引入bge-reranker-v2-m3重排，最终Top-5召回率达到89%，端到端回答准确率从54%提升至82%，平均响应延迟控制在1.2秒内。文中包含完整参数配置与可运行代码。
LoRA微调Qwen2.5-7B实践：从数据构造到loss曲线与推理对比
本文记录我用LoRA在单卡RTX 4090（24GB）上微调Qwen2.5-7B-Instruct的完整过程。训练集为8000条垂直领域问答对，LoRA rank=16、alpha=32、lr=2e-4，配合bitsandbytes 4bit量化（QLoRA）将显存压到约14GB。训练3个epoch约2.5小时，loss从1.82降到0.63，验证集loss稳定在0.71。微调后领域问答准确率从基
RAG检索增强生成优化实录：chunk策略、embedding切换与rerank效果对比
本文记录了一个企业知识库RAG系统从上线到优化的完整过程。初始版本召回率仅62%，答案准确率不足55%。通过调整chunk策略（512→256带重叠）、将embedding模型从text-embedding-ada-002切换到bge-large-zh-v1.5、引入bge-reranker-large重排序，最终召回率提升至91%，答案准确率达到84%。文中包含完整代码、参数配置和前后对比数据，
我用GPT-4o做合同信息抽取：6版Prompt对比，Token消耗降了58%
同一个合同字段抽取任务，我写了6版Prompt，从“裸问”到Few-shot+JSON Schema约束，准确率从61%提升到94%，单次Token消耗从1830降到768。本文完整记录了每版Prompt的设计思路、实测数据（含GPT-4o-2024-08-06与Claude 3.5 Sonnet对比）和踩坑过程，附可直接运行的Python代码。
从62%到89%：一次RAG检索增强生成系统的三轮迭代优化记录
本文记录了一个企业知识库问答系统（约12万篇文档、平均每篇1800字）的RAG优化过程。初始方案chunk固定512 token、embedding用text-embedding-ada-002，Top-5召回下人工评估准确率仅62%。通过三步改造：chunk改为语义分段+重叠窗口、embedding切换为bge-large-zh-v1.5、引入bge-reranker-large重排，最终Top
Milvus 2.5 与 Qdrant 1.12 实测对比：千万级向量检索选型与资源占用分析
本文基于图文推荐召回场景，在同一台 16C64G 服务器上实测 Milvus 2.5.4 与 Qdrant 1.12.4。数据集为 1000 万条 768 维向量，分别在 HNSW 与 IVF_FLAT 索引下测试 QPS、P99 延迟、内存与磁盘占用。结果显示：Qdrant 单机部署更轻量，P99 延迟约 18ms；Milvus 在分布式扩展和标量过滤上更成熟，但常驻内存高出约 2.3 倍。文章
用asyncio重构Flask同步API，QPS从120提升到2300的完整记录
一个日请求量800万的查询接口，原本用Flask+Gunicorn同步模型，P99延迟高达1.8秒，QPS只有120。改用FastAPI+asyncio异步方案后，单机QPS提升到2300，P99降到86毫秒，服务器从12台缩减到3台。这篇文章完整记录了改造过程：问题定位、方案设计、核心代码、踩过的坑，以及真实的压测数据对比。
RAG检索增强生成系统优化：从Chunk策略到Rerank的召回率提升记录
线上RAG问答系统上线两周后，用户反馈“答非所问”比例高达23%。我们基于LangChain 0.1.0 + Milvus 2.3.4 + BGE-M3，对chunk策略、embedding模型和rerank环节做了三轮迭代。将固定512字符切分改为语义分段+滑动窗口后，召回率从61%提升至74%；把text-embedding-ada-002切换为bge-large-zh-v1.5，MRR提升8
asyncio重构Flask接口：QPS从120提升到1800的异步改造记录
一个查询用户订单详情的接口，原本用Flask同步串行调用3个下游HTTP服务，单次响应约750ms，压测QPS只有120。改用FastAPI + asyncio并发编排、httpx异步客户端、asyncio.gather聚合后，P95从820ms降到95ms，QPS提升到1800，单机4核8G即可扛住。本文给出before/after完整代码、连接池参数、超时与降级细节，以及我踩过的3个坑。
基于Git Flow与Trunk-Based的分支策略及CI/CD集成配置实践
团队从5人扩展到20人后，直接推master导致每周至少3次冲突回滚，平均修复耗时45分钟。本文记录我们如何用Git Flow + Trunk-Based混合分支策略、Gerrit风格的Code Review门禁、以及GitLab CI 16.8 + Jenkins 2.426双流水线，把主干构建失败率从18%降到2.3%，MR平均合并周期从26小时压缩到4.7小时。附完整.gitlab-ci.y
FastAPI接口从2.3s降到180ms：一次Profiling驱动的数据库与缓存优化记录
线上一个FastAPI商品详情接口P99飙到2.3s，QPS一过50就开始超时。本文用py-spy+SQLAlchemy事件钩子定位到N+1查询和缺失索引，再引入Redis缓存与连接池调优，最终P99降到180ms，QPS从50提升到820，错误率归零。附完整压测数据与可运行代码。
用asyncio重构Flask接口，QPS从320提升到2100的优化记录
一个查询用户订单详情的接口，原本用Flask同步实现，压测QPS只有320，P99延迟高达1.2s。排查发现瓶颈在于接口内部串行调用了3个下游HTTP服务。改用FastAPI + asyncio并发编排后，QPS提升到2100，P99降到180ms。本文完整记录改造前后的代码、压测数据、以及踩过的坑，包括aiohttp连接池配置、asyncio.gather异常处理、以及event loop被阻塞
用asyncio重构Flask接口，QPS从83提升到1100的并发优化记录
一个查询3个外部HTTP接口再聚合返回的Flask同步接口，在200并发下QPS只有83，P99延迟高达2.4s。用asyncio+aiohttp重写后，单进程QPS提升到1100，P99降到210ms，机器数从8台减到2台。本文给出完整的before/after代码、uvloop配置、连接池参数和压测数据，也记录了几个把我坑了半天的细节。
我用Claude 3.5 Sonnet做结构化抽取：6版Prompt对比，Token从1200降到380，准确率反升12%
最近在做一个合同关键信息抽取服务，需要从非结构化文本里稳定拿到甲乙方、金额、签署日期等8个字段。最初一版Prompt单次消耗约1200 tokens，字段准确率只有78%，且金额经常带出多余单位。我围绕同一批200条测试样本，迭代了6版Prompt，把输入从1200 tokens压到380 tokens，准确率提到90.3%，单条成本下降约68%。这篇文章完整记录了每版Prompt的设计思路、Cl
Git分支策略与CI/CD集成：基于GitLab 16.8的团队协作工作流配置实践
团队从SVN迁移到Git后，因缺乏统一分支规范，一度出现发布分支被误合并、热修复代码丢失等问题，平均每次发布回滚耗时超过40分钟。本文基于GitLab 16.8、Git 2.43和Jenkins 2.440，分享一套落地半年的工作流：main/develop/release/feature/hotfix五类分支策略、Merge Request驱动的Code Review流程、以及触发式CI/CD流
asyncio重构同步Web API，QPS从120飙到2100
一个日请求量800万的内部API，原本用Flask+Gunicorn同步模型，单节点QPS只有120，P99延迟高达1.8s。我把它改成FastAPI+asyncio异步架构，配合httpx异步客户端和连接池调优，单节点QPS直接拉到2100，P99降到230ms，服务器成本降了60%。这篇文章记录了完整的改造过程、踩过的坑，以及所有可复现的压测数据。
用asyncio重构Flask API：QPS从120提升到2300的改造过程
一个日请求量800万的用户画像查询接口，原本用Flask+Gunicorn同步模型部署，单机QPS只有120，P99延迟高达1.8秒。我用asyncio+FastAPI+httpx.AsyncClient重写后，在同样的4核8G机器上，QPS跑到2300，P99降到95毫秒。这篇文章完整记录改造思路、核心代码、踩过的坑，以及压测数据对比。
从零用LoRA微调Qwen2.5-7B：数据构造、训练参数与loss曲线全记录
本文记录了我在单张RTX 4090（24GB）上，用LoRA微调Qwen2.5-7B-Instruct的完整过程。训练数据是12000条垂直领域问答对，采用bfloat16 + gradient checkpointing，rank=16、alpha=32，训练3个epoch约4.5小时。最终验证集loss从1.42降到0.87，领域测试集准确率从基线的54%提升到83%，显存峰值占用约19.3G
FastAPI + SQLAlchemy 接口从 800ms 优化到 45ms：一次真实的性能调优过程
线上一个基于 FastAPI 0.110 + SQLAlchemy 2.0 + PostgreSQL 14 的订单查询接口，P95 延迟高达 820ms，QPS 一过 200 就开始大量超时。通过 cProfile + py-spy 定位到 N+1 查询和缺失索引，配合 Redis 缓存与 ORM 加载策略调整，最终 P95 降到 45ms，单机 QPS 从 210 提升到 1400+。本文完整记
从0.71到0.89：一次RAG检索增强生成系统的分层优化记录
本文记录了一个企业知识库RAG系统从上线到可用的一次完整优化过程。初始版本采用固定512字符切分、text-embedding-ada-002、无重排，在200条人工标注问答集上Recall@5仅0.71，答案准确率约62%。通过改用语义+递归混合chunk策略、切换bge-large-zh-v1.5、引入bge-reranker-large重排三阶段改造，最终Recall@5提升至0.89，端到
