13. 你在项目中遇到过最难的技术挑战是什么？怎么解决的？
整理你在项目中遇到过最难的技术挑战是什么？怎么解决的？的面试回答思路与拆解方式。
简单回答
这道题没有标准答案，考的是你面对复杂问题时的分析能力和解决能力。好的回答结构是"遇到了什么问题 → 为什么难 → 尝试了什么方案 → 哪些有效哪些无效 → 最终怎么解决的 → 学到了什么"。挑一个真实的、有深度的挑战来讲，不要编造也不要选太简单的问题。
详细解释
怎么选择要讲的挑战
挑一个满足以下条件的：真实遇到过（能经受细节追问）、有技术深度（不是"数据库连不上"这种运维问题）、你深度参与了解决过程（不是别人解决你只是知道）、最终有一个明确的结果（不管是解决了还是做了 trade-off）。
大模型项目中常见的有技术深度的挑战：
长上下文导致的效果下降——Prompt 超长后模型忽略了中间的关键信息。怎么验证是 Lost in the Middle 的问题、怎么调文档排序策略、怎么在信息完整性和上下文长度之间取舍。
表格类文档的检索和理解——表格切 Chunk 后丢失结构信息，向量检索匹配不到正确的表格行。怎么做表格的特殊处理、怎么结合 Text-to-SQL 做精确查询。
多轮对话中的指代消解和上下文管理——用户说"上次那个"，怎么知道指的是什么。Query Rewrite 的准确率不够高怎么办。对话历史太长超出上下文窗口怎么裁剪。
Agent 的稳定性——Agent 在生产环境中陷入循环、延迟不可控、错误恢复困难。怎么设计 guardrails、超时机制和 fallback。
怎么讲
描述问题和影响。 "上线两周后我们收到大量用户反馈说'问了一个表格里能查到的数据，系统说找不到'。统计了一下，表格类问题的准确率只有 35%，远低于文本类问题的 80%。"——让面试官感受到这是一个真实的、有影响的问题。
分析为什么难。 "表格类问题难在两个层面。检索端，表格按段落切 Chunk 后行列关系丢了，一行数据被拆到了两个 Chunk 里谁都不完整。Embedding 模型对表格的编码质量也差——一个 Markdown 格式的表格 Chunk，向量表示和用户的自然语言提问差距很大。生成端，即使检索到了正确的表格 Chunk，模型对大表格的理解也不够精确——经常看错行或看错列。"
尝试了什么。 "我们试了几个方案。第一个是把表格转成自然语言描述——每行生成一段描述文字，然后当文本 Chunk 处理。效果有提升但大表格的描述太长太冗余。第二个是把表格入结构化数据库用 Text-to-SQL 查询——效果很好但开发成本高，而且 LLM 生成的 SQL 有时候会有语法错误。最终我们用了混合方案——小表格（10 行以内）转 Markdown 做文本检索，大表格入 SQLite 用 Text-to-SQL 做精确查询，用一个简单的分类器判断走哪条路。"
结果和反思。 "最终表格类问题的准确率从 35% 提到了 72%。虽然还没到文本类的 80%，但已经是可接受的水平了。这个过程最大的教训是不要试图用一套方案解决所有问题——不同类型的内容需要不同的处理策略。"
面试官的追问方向
面试官会从你的回答中挑细节追问——"Text-to-SQL 的准确率有多高""分类器怎么训练的""Markdown 表格的 Embedding 质量你是怎么评估的"。所以一定要讲自己真正深入做过的事情，经不起追问的内容不要提。
面试时可以这样答
（直接讲一个具体的技术挑战，用上面的结构——问题描述、分析原因、尝试方案、最终结果。这里不给模板，因为每个人的经历不同。关键是真实、有深度、经得起追问。）
常见追问
- 你提到的方案 A 不 work，具体差在哪里？
- 最终方案有什么局限？如果还要优化你会怎么做？
- 这个过程中你学到了什么？