LLM

RAG（Retrival Augumented Generation）技术对于扩充模型的知识，减少幻觉，提高实用性上非常重要。这篇文章主要是介绍一个RAG系统的各个工作环节，对应的可调节参数以及应用场景。 RAG系统的工作流程 Ingestion parsing（pdf html） chunking metadata 来源、标题、章节、日期、权限 contextual retrieval Vector db indexing dense model choice 模型维度、语言支持、是否非对称 sparse / bm25 indexing embedding/index 的更新机制 Retrieve Query processing rewrite expand HyDE query routing metadata filtering Hybrid search 融合 RRF 或加权 rerank 上下文压缩 / 去重(把检索到的内容裁剪、去冗余,省 context window) chunk 扩展(检索命中小 chunk,但喂给 LLM 时取回它的相邻上下文或父文档,即 “small-to-big” / parent-document retrieval) Generation no-answer / 兜底 prompt 拼装(把 query + 检索结果组织成 prompt) 生成 citation / attribution(标注答案出自哪个 chunk,可溯源) ...

MiroThinker 1.7 在长问题推理领域取得了SOTA的成绩，优秀的成绩是由强Model与扎实的Harness共同组成的，本文是对其Harness实现中的关键工程优化的记录。 前置背景 MiroThinker 是一个深度研究型 Agent —— 给一个复杂问题（“今天 arxiv 上 cs 的论文标题是什么”），它会自己拆任务、搜索、抓网页、跑 Python 验证，最后输出 \boxed{答案}。底子是经典 ReAct：每回合 LLM 思考 + 工具调用，结果回写历史，循环 200~300 次直到收敛。 256K 上下文 + 单任务最多 300 次工具调用，对工程是不小挑战。运行时整体长这样： flowchart TD Task["task_description (用户问题)"] --> Loop subgraph Loop ["Orchestrator 主循环 (≤200/300 turns)"] direction TB For["for turn in 1..max_turns:"] S1["① LLM 思考 → tool_call"] S2["② ToolManager → MCP Server (search / python / scrape / ...)"] S3["③ keep_tool_result：裁剪远端工具结果"] S4["④ ensure_summary_context：token 预估刹车"] S5["⑤ rollback / 中间答案池"] For --> S1 --> S2 --> S3 --> S4 --> S5 end Loop --> Condition{"结束条件"} Condition -- "成功 \boxed{}" --> Success["输出最终答案"] Condition -- "跑满 / 上下文满" --> Failure["generate_failure_summary"] Failure --> Restart["重启 attempt（≤3 次）"] 下文按"护栏机制 → 工具层 → 上下文处理"三块展开。 ...

来源： Anthropic Engineering — Demystifying evals for AI agents 好的评估能帮助团队更自信地交付 AI Agent。缺少评估，团队很容易陷入被动循环——只有在生产环境中才能发现问题，而修复一个故障往往又引发新的故障。评估能让问题和行为变化在影响用户之前暴露出来，其价值会在 Agent 的整个生命周期中持续累积。 ...