RAG 系统架构设计
上周面试被问到："你们的 RAG 系统是怎么设计的？" 我发现自己只会说"用向量数据库存文档，然后检索"——这显然不够。面试官追问架构演进路线时，我答不上来了。回来之后我系统梳理了 RAG 的三代架构，发现这里面的门道比想象中深得多。
向量数据库选型实战
上个项目选型时，我在 Chroma、FAISS、Milvus 之间纠结了三天。Chroma 说轻量好用，FAISS 说性能无敌，Milvus 说生产级部署。最后选了 Chroma，结果数据量上来后查询变慢，又花了一周迁移到 Milvus。这次踩坑让我明白：向量数据库选型不是选"最好的"，而是选"最适合当前阶段的"。
Embedding 模型选型与微调
上周我负责的 RAG 系统上线了一个新的法律文档问答功能。用户问"合同违约金上限是多少"，系统检索回来的文档却是关于"劳动法试用期规定"的——语义完全不相关。排查下来发现，不是检索逻辑有问题，而是我们用的 Embedding 模型对中文法律术语的语义理解不够好。这次事故让我意识到：Embedding 模型选型是 RAG 系统中最容易被忽视、但影响最大的环节。
Chunking 策略深度解析
切片看起来是最简单的一步——不就是按字数切吗？但当我用 500 字符的固定切片处理一份 50 页的技术文档时，检索结果惨不忍睹：一句话被切成两半，上下文完全断裂，LLM 拿到残缺的片段根本没法回答。后来我才意识到：切片策略直接决定了 RAG 系统的上限。
RAG 评估与优化
"你的 RAG 系统效果怎么样？" "嗯……感觉还行？" 这是我第一次被面试官问到 RAG 评估时的回答。感觉还行——这三个字暴露了我根本不懂怎么量化评估 RAG 系统。回来之后我系统学习了 RAGAS 框架，才发现评估 RAG 有一整套科学的方法论。