@akshay_pachaar：一个好的技术LLM面试问题：你的RAG聊天机器人在本地运行正常。你将其部署在负载均衡器后面，有3个副本……

X AI KOLs Following 新闻
rag llm deployment kubernetes langchain vector-store

摘要

这条推文提出了一个关于大规模部署RAG聊天机器人的技术面试问题，解释了常见的陷阱如状态持久性，并指向Akamai的GitHub仓库和开发者中心以获取参考实现。

一个很好的技术LLM面试问题： 你的RAG聊天机器人在本地运行正常。 你将其部署在负载均衡器后面，有3个副本。 用户报告说它忘记了他们刚问的问题，并且每次重启后答案都变差了。 为什么会这样？ （答案在下方） 本地环境有一个进程拥有所有内容。 - 向量索引是内存中的一个变量。 - 对话历史是一个Python列表。 - 文档存储在本地磁盘上。 你从未将它们视为基础设施，因为重启时会在几秒钟内重建所有三个，并且始终只有一个副本。 这种设置不能直接应用到生产环境。 向量索引可能在重启时消失，因此应用在启动时重新嵌入所有内容，并在完成之前提供空结果。 对话历史可能属于一个副本，因此路由到其他地方的后续请求没有前一轮记忆。 文档可能位于摄取它们的容器上，因此三个副本持有三个不同的语料库。 在使用一个用户和一个进程时，这些都不明显。 因此，实际部署RAG的工作不仅是检索逻辑，还包括存储向量索引、对话历史和文档在应用外部，所有副本读写同一份副本。 这归结为三个要求： > 向量存储需要持久性，并且必须从每个副本可达。Postgres中的pgvector将嵌入存储在数据旁边，而不是添加另一个系统来操作。 > 对话状态必须在应用外部检查点。LangGraph将其状态写入Postgres，因此任何副本都可以在对话中途捡起线程。 > 文档需要共享对象存储，因此摄取发生一次而不是每个副本一次。 如果你正确处理这三个方面，你在笔记本中编写的检索逻辑将无需更改即可工作。 要了解所有内容如何连接在一起，Akamai的GitHub有一个工作参考实现。 - rag-langgraph-k8s-quickstart是一个使用FastAPI、LangChain和LangGraph构建的航空公司政策问答助手。Terraform在一次应用中配置LKE集群、一个带有pgvector用于嵌入的Postgres实例、第二个Postgres用于LangGraph检查点，以及一个用于政策文档的对象存储桶。 - akamai-workshop-ai-inference涵盖了下一步，自己运行模型而不是调用API，包括预填充和解码、KV缓存权衡以及真实并发下的连续批处理。 两者都可在Akamai的新Developer Hub上找到，以及他们的教程和代码示例。 它还链接到Edge Case，他们的Discord，四位开发者倡导者每隔周三现场架构和部署生产应用。 如果你创建一个新的Akamai Cloud账户，你也可以获得$300的积分作为加入奖励。 加入链接：https://fandf.co/4hPMwFx 话虽如此，这篇帖子假设检索逻辑从一开始就是正确的，这承担了大量工作。大多数RAG系统更早失败，在将文本块视为自包含意义单元的那一点上。 我写了关于弥合这一差距的两项技能，以及为什么文本块通常不是嵌入的正确对象。 在下方阅读。 感谢Akamai Cloud今天的合作！
查看原文
查看缓存全文

缓存时间: 2026/09/02 14:01

一个出色的大语言模型技术面试问题：

你的RAG聊天机器人在本地运行良好。

部署到具有3个副本的负载均衡器后，用户反馈机器人忘记了刚才的对话内容，且每次重启后回答质量持续下降。

这是什么原因？

（答案如下）

本地环境是单进程架构，所有资源都由该进程独立管理：

  • 向量索引是内存中的变量
  • 对话历史存储于Python列表
  • 文档保存在本地磁盘

你从未将这些视为需要持久化的基础设施，因为重启后所有资源都能在数秒内重建，且始终只存在单份拷贝。

但这种架构无法直接迁移到生产环境：

  1. 向量索引可能随重启丢失，导致应用启动时重新计算所有嵌入，完成前只能返回空结果
  2. 对话历史可能仅存在于某个副本，当后续对话路由到其他副本时将丢失历史上下文
  3. 文档可能仅存储在首次接收的容器中，三个副本可能持有完全不同的语料库

这些隐患在单用户单进程场景下难以察觉。

因此，真正实现RAG产品化的关键不仅是检索逻辑，更需要将向量索引、对话历史和文档存储部署在应用层之外，确保所有副本都能读写同一份数据。

这引出三个核心要求：

向量存储需要持久化且能被所有副本访问。PostgreSQL中的pgvector将嵌入数据与业务数据存储在一起，避免增加额外的运维系统。 对话状态需在应用外进行检查点保存。LangGraph会将状态写入PostgreSQL，使得任何副本都能在对话中途接续处理。 文档需要共享对象存储，确保数据只需摄入一次而非每个副本重复处理。

只要正确实现这三层架构，你在实验环境中编写的检索逻辑就能直接用于生产环境。

若想了解完整架构实现，Akamai在GitHub上提供了可运行的参考方案：

  • rag-langgraph-k8s-quickstart：基于FastAPI、LangChain和LangGraph构建的航空政策问答助手。通过Terraform一键部署LKE集群，包含集成pgvector的PostgreSQL实例、用于LangGraph检查点的第二个PostgreSQL实例，以及存储政策文档的对象存储桶。

  • akamai-workshop-ai-inference：进阶方案，涵盖自行部署模型（替代API调用）的完整流程，包括预填充与解码机制、KV缓存优化策略，以及真实并发场景下的持续批处理技术。

这两个方案均已上线Akamai新开设的开发者中心，配套提供教程和代码示例。

该中心还链接着他们的Discord社区「Edge Case」，四位开发者布道师每隔一周会直播演示生产级应用的架构设计与部署流程。

现在注册Akamai云账户，还可获得300美元的新人优惠。

立即加入：https://fandf.co/4hPMwFx

需要说明的是，本文默认检索逻辑已正确实现——这其实是个重要前提。大多数RAG系统更早出现的问题，在于将文本分块视为独立的语义单元。

关于解决这一问题的两项关键技能，以及为什么分块本身通常是最不适合进行嵌入的对象，我将在下文详细阐述。

感谢Akamai云的合作伙伴支持！

相似文章