大型语言模型（LLMs）中存在的数据污染是一个重要问题，可能会影响它们在各种任务中的表现。这指的是LLMs的训练数据中包含了来自下游任务的测试数据。解决数据污染问题至关重要，因为它可能导致结果偏倚，并影响LLMs在其他任务上的实际效果。通过识别和减轻数据污染，我们可以确保LLMs具有最佳性能并产生准确的结果。数据污染的后果可能非常严重，包括不准确的预测、不可靠的结果和数据偏倚。
本文译自 The Hidden Influence of Data Contamination on Large Language Models
写这篇文章的原因是我构建的 RAG 框架已经基本成型，现在只剩下最后一块拼图，即评估模块，这也是真正投入生产后，RAG 系统迭代的关键，本篇文章我将分享 3 种方案，第一种我自己跑出来的实践经验，第二种是比较成熟的框架 RAGAs，通过定量指标来评估，最后一种是则是通过噪声、拒答、反事实、信息整合等四大指标来定性分析，来自论文《在 RAG 中对大语言模型进行基准测试》，大家可以结合起来设计自己的方案。
本文首发自博客文章 如何评估一个RAG（检索增强生成）系统
由于要为公司产品接入 AI 能力，且政策原因只能使用国内大模型，所以过去一个月我仔细阅读了一遍国内 6 家（阿里、百度、MiniMax、智谱 AI、MoonShot、百川智能，没试用字节和腾讯家的原因末尾总结有吐槽）大模型厂商文档，逐个测试了不同的 API，发现相同的功能各家的叫法又不一样，使用起来很混乱，所以才有了这篇文章，本文我将以 OpenAI 提供的 API 能力（因为个人项目一直在使用 OpenAI）为基准，从 GPTs 能力、插件能力、Assistants API、基础 API 能力（基础大模型、微调支持等）四个方面展开，对国内各模型厂商的能力进行比较和统一定义，希望能给现阶段准备在产品中接入国内大模型的独立开发者和中小企业提供一点参考。
大家好啊，好久不见，我们都知道当前基于大模型构建的 Agent 能力极不稳定，而今年我司产品又在规划接入 Agent 能力，所以在引入之前，需要先设计一套测试框架，来看看各种场景下容错率是否能达到目标阈值，所以我调研了几种测试方案，本篇来总结下。
基于大模型的 Agent 基本组成应该包含规划（planning)，工具（Tools)，执行(Action)，和记忆(Memory)四个方面，上一篇中重点讲了进行长记忆管理的 8 种方案，本节将从 Agent 的概念、ReAct 框架、示例、以及一些论文思路来具体聊下任务规划的话题，同时会辅以代码帮助理解，欢迎大家一起探讨。
如果说去年一年是自媒体的狂欢，还可以利用信息差赚知识付费和咨询费，那今年在技术普及已经差不多了，就要面对落地的挑战了，否则大多数人该怀疑这又是一场泡沫了，最近一个月，我自己的身份也从纯研发角色侧重为产品，虽然代码还在写，但关注重点不一样了，这篇文章我将从这一个月来的实践和调研的情况出发，尝试从个人角度阐述对 AI 产品经理的能力理解，以及对当下 toC 和 toB AI 产品落地现状的一些思考，欢迎大家一起探讨。
大模型时代，程序员如何实现自我成长？——一名普通开发者的 ChatGPT 一周年记
ChatGPT 发布一周年了，切实改变了我的工作方式和职业路径，趁着周末写下这篇文章，我希望以一名普通程序员的视角，带大家回顾一下过去一年大模型领域的发展情况，以及个人的所思所想。文章会分为四个部分，从初次接触 ChatGPT 沉迷追 AI 新闻，到开始亲身实践，利用 LLM 进行一些有价值的工作，然后以开发者视角总结一年来大模型各个层面的发展，标志性的开源项目、基础模型服务商、中间层、以及体验不错的 LLM 产品，最后还想再浅谈一下对 AI 未来的一些展望！
LLMs 应用开发框架 Semantic Kernel 和 LangChain 比较
Semantic Kernel 和 LangChain 是当前比较受欢迎的两款 LLMs 应用开发框架，笔者通过实现一个支持联网功能的智能 AI 助手来比较分析下两个框架的差异（适合自己场景的工具才是最好滴 🧑🏻💻）
RAG（检索增强生成）是一种结合了检索（通常是知识库或数据库）和生成模型（大语言模型）的技术，目的是在生成文本的时候能够参考相关的外部知识。这样，即使生成模型在训练时没有看到某些信息，它也能在生成时通过检索到的知识来生成更加准确和丰富的回答，这篇文章实现一种基于动态上下文窗口的方案，能够处理大规模文档，保留重要的上下文信息，提升检索效率，同时保持灵活性和可配置性。