7天造出信贷风控AI：这个工程师把散落3个仓库的文档塞进了聊天框

信贷风控工程师的日常，是翻遍GitHub仓库、研究论文、内部Wiki，只为找一个公式怎么算。某ML工程师用7天做了个AI Agent，把3个代码仓库的文档塞进搜索引擎，现在问它"WOE分箱怎么搞"，它能直接甩出GitHub链接。

这不是Demo。作者本职就是干这个的——建评分卡、监控模型漂移、验证PD/LGD/EAD模型，每天跟WOE分箱管道打交道。他发现Alexey Grigorev的AI Agents速成课后，没跟默认数据集，而是做了自己上班真能用的东西。

为什么信贷风控特别需要这玩意儿

WOE（证据权重）、IV（信息价值）、分箱、漂移检测——这些术语圈外人听着像黑话，圈内人知道是基础设施。问题是文档太碎：一个公式可能在某个仓库的issue里，实现细节藏在Jupyter notebook第47个cell，最佳实践只存在于老员工的脑子和离职交接邮件里。

作者的原话：「The documentation is scattered across GitHub repos, research papers, and internal wikis. Finding a specific formula or implementation detail means digging through notebooks manually.」翻译成人话：找东西靠手刨。

他做的Agent干了几件事：从3个信贷风控GitHub仓库拉文档，索引进搜索引擎，用GPT-4o-mini（通过Pydantic AI框架）回答自然语言提问。每个答案带引用链接，点一下直达GitHub源文件。

你可以问它："PD模型校准怎么验证？"或者"这个WOE分箱代码为什么报NaN？"——它会像那个你一直想请教、但已经离职的老同事一样回答你，只是不会不耐烦。

技术选型：为什么用Pydantic AI而不是LangChain

作者没选最热门的工具。Pydantic AI的核心卖点是类型安全——用Python的类型系统约束AI输出，避免LLM胡编字段名。对于风控这种"错一个小数点可能被罚穿"的领域，结构化的可靠性比花里胡哨的链式调用更重要。

GPT-4o-mini负责理解问题和生成回答，成本够低、速度够快。搜索层用了向量索引+关键词混合检索，毕竟技术文档里代码片段和术语的精确匹配不能全靠语义相似度。

整个流程跑通：用户提问→检索相关文档片段→LLM结合上下文生成回答→附加源链接。7天里作者还踩了坑——GitHub API rate limit、不同仓库的文档格式不统一、代码块和Markdown混在一起的解析噩梦。

实际用起来什么感觉

作者举了几个能问的问题：WOE binning pipelines怎么实现、PD/LGD/EAD模型验证要点、模型漂移监控的常用指标。这些原本需要打开5个标签页、翻3个仓库才能拼出的答案，现在变成了一段带出处的对话。

有个细节很真实：每个回答都带GitHub链接。不是"根据某篇论文"，而是"这个函数在repo-A的utils.py第142行"。对于需要审计溯源的风控场景，这比答案本身更重要——监管问你这个结论哪来的，你能点过去给他看。

作者没说的是，这玩意儿能不能直接扔给业务同事用。技术文档的AI问答有个永恒难题：问得太专业，LLM复述文档；问得太模糊，它开始自信地胡说。他的解法是把检索范围锁死在3个可信仓库，用Pydantic的结构化输出卡住幻觉的脖子。

7天之后的思考

这个项目的价值不在技术复杂度，在场景切得准。AI Agent现在是个热到发烫的词，但大多数教程停留在"用工具调用订个披萨"。作者把它扎进了一个足够深、足够痛的垂直场景——信贷风控的文档碎片化问题。

他开源了代码（虽然原文没给链接，但提到了GitHub repos作为数据源）。对于同行来说，这比又一个通用RAG框架有用得多：你能看到怎么处理代码+文档混合的内容，怎么给技术问答加引用，怎么在领域术语和日常语言之间做翻译。

最后留个开放的问题：如果你的工作也有这种"知识散落在10个地方，老员工脑子占一半"的痛点，你会选择把文档灌进AI，还是继续手刨——以及，你的老板愿意为"少刨3小时文档"付多少预算？